ipq40xx: Add support for ZTE MF289F
This is a PR to request add of support for ZTE MF289F on the next OpenWRT relase
Install and recovery istructions was added to the squashed commit
Hello! Thanks a lot for your work !! It would be very nice if you could use your real name in all commits, and add installation instructions, and (if applicable) recovery methods.
Oh - sorry: in addition, you may be asked later to squash your commits.
Hello! Thanks a lot for your work !! It would be very nice if you could use your real name in all commits, and add installation instructions, and (if applicable) recovery methods.
How to add this information? (Signed was auto added)
Regarding how to flash/recovery there's a wiki how to?
Thx
Unfortunately I don't know much about the GitHub web interface (I am commenting via API), so can't help you out much with the Signed Off.
However, installation/recovery instructions may be placed on the OpenWRt wiki, but they are present in commit messages as well. See previous commits adding support for devices to get an idea. I picked at random this commit as an example: 498c15376bae109bfe130cc5581f83e4cc52c0f9
Thanks !!
Ok I'll try to add instructions.
Wait for it before merge anything :)
As pointed out, squash the commits and edit to include proper commit title as well as description that also needs to include install instructions.
SoB is required as well with a real name and email.
You are not going to be able to do this via the Github UI
@stich86 please don't be scared for amount of my comments, they just stemmed from my experience with hacking MF286 series :-) Also, let's get @chunkeey in the loop.
@stich86 please don't be scared for amount of my comments, they just stemmed from my experience with hacking MF286 series :-)
Also, let's get @chunkeey in the loop.
Hi @Leo-PL,
this is my first PR, so I need to learn a lot of thing :)
I'll review all your comments and make necessary fixes in the next few days
Thanks!
Unfortunately I don't know much about the GitHub web interface (I am commenting via API), so can't help you out much with the Signed Off.
However, installation/recovery instructions may be placed on the OpenWRt wiki, but they are present in commit messages as well. See previous commits adding support for devices to get an idea. I picked at random this commit as an example: 498c153
Thanks !!
How I can add the page on the wiki? I've tried but got an error:
Self-Registration is currently disabled or conf/users.auth.php is not writable. Please ask your DokuWiki administrator to create your account manually.
thx
@stich86 see https://forum.openwrt.org/t/wiki-registration-disabled/87800
Now I think you can squash all the changes - you can use git rebase --interactive for that, and I think we could ask @chunkeey and other devs for proper review and merge.
@stich86 see https://forum.openwrt.org/t/wiki-registration-disabled/87800
Now I think you can squash all the changes - you can use
git rebase --interactivefor that, and I think we could ask @chunkeey and other devs for proper review and merge.
Thanks for point it. I've written to one of the forum member for the wiki page :)
I'll do rebase in the afternoon
Thanks for your support!
@robimarko I'm still not sure if led-status is the proper name - this LED is not visible on the case unless you peer into the device through the upper grill. That's one thing. Other is, that upstream (the kernel) actually recommends" indexing the LEDs in the node names, I'll try to dig up source for that soon.
So guys... what's names I've to use!? 😅
@robimarko this is the example: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/leds/common.yaml#n175
@stich86 I'd go with previous version, or with blue:debug, because this is the original purpose of that LED, but maybe @chunkeey can arbitrate ;-}
@Leo-PL You are correct, indexing is per the bindings, sorry on that. I still dont see the logic behind calling the LED used as status debug?
On stock firmware, this LED was unused, and in OpenWrt it is used only because there is no real alternative. We cannot control the LEDs controlled by modem directly - and that set includes a separate power/status LED, so calling this one "status" IMO would be a misnomer.
@robimarko this is the example: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/leds/common.yaml#n175
@stich86 I'd go with previous version, or with
blue:debug, because this is the original purpose of that LED, but maybe @chunkeey can arbitrate ;-}
Ok I'll revert the name of internal LED.
Did you guys have other changes or I can squash commit?
Thx ☺️
Regarding my previous comments, LGTM.
Regarding my previous comments, LGTM.
Reverted, i'll try to squash all commits.. let's see if they approve it :)
Prefix the commit title with ipq40xx:
Prefix the commit title with
ipq40xx:
Do you mean to add ipq40xx at the top of the commit?
No, I mean prefix the commits title/name to make it:
ipq40xx: Add support for ZTE MF289F
No, I mean prefix the commits title/name to make it:
ipq40xx: Add support for ZTE MF289F
Done :)
Not the PR, the commit itself.
Not the PR, the commit itself.
ops.. sorry done :)
ATM the ath10k firmware packate is not updated, can I push a new version that contains override for Wi-Fi stuff?
to make it works as expected these files are needed:
- board-2.bin definition 2.4/5G for AT2/AT1 on IPQ4019, AT1 will use only 2.4 because board-id for 5G is different and not used on this revision
- board-2.bin definition 5G for AT1 on QCA9984
Let me know
Thanks!
You mean ipq-wifi package?
You mean ipq-wifi package?
yes
Please add the required BDF-s, as without them WLAN will work terribly.
Please add the required BDF-s, as without them WLAN will work terribly.
ok added both QCA4019 and QCA9984 I've also changed required packages on the MF289F target (ipq custom and qca9984 firmware)