Remove boilerplate.
Also added deregister for bcm_wifi for consistency. Not needed as it's
builtin but still good to have.
There's a slight change from subsys_initcall to module_init. Not really
an issue for mtd drivers. No driver in linux upstream's drivers/mtd uses
subsys_initcall.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23893
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
strlcat takes the total buffer size, not the remaining space.
Passing strlen(cmdline) + l caused it to truncate by one byte
when the appended string fit within the buffer.
This is also more consistent with the rest of the file.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23892
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
BUG() and BUG_ON() are deprecated - they destabilize the system
and make debugging impossible. Replace with:
- WARN_ON() + return error for assertion failures
- WARN_ON_ONCE() for bounds checks
- WARN_ON() + return -EPERM for in_interrupt() guards
Assisted-by: Opencode:Big-Pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23892
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Use _scoped loop to about fwnode_handle_put everywhere.
Remove usage of of_node.
Use devm_led_classdev_register_ext to avoid fwnode handle leaks.
Remove custom struct_size function.
Fix other various issues found with AI.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21027
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The Apple g++ check is really clang in disguise. Furthermore, testing on
Linux hosts reveals that clang can sufficiently replace gcc.
Minimum version of clang is 12 because of ccache.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17259
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Backport two upstream commits that replace memset() on coherent DMA
descriptor rings with explicit WRITE_ONCE() status word stores.
On 32-bit PowerPC platforms like apm821xx, coherent DMA memory may be
mapped uncached. The optimized memset() path can use dcbz there, which
triggers alignment warnings and spams the kernel log.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23776
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move apm821xx to the 6.18 kernel after testing it as the testing kernel.
There are ethernet performance improvements in the 6.18 kernel for
whatever reason. There's also work on getting rid of dmesg slop at
runtime.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23777
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Not needed when using nvmem. All others left alone.
Move some swport nvmem definitions to the root gmac to avoid a
randomized MAC address for the GMAC. The former inherits from the latter anyway.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22550
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Original ar71xx has this setup:
define WNDAP360_WMAC0_MAC_OFFSET 0x120c
define WNDAP360_WMAC1_MAC_OFFSET 0x520c
/* Reusing wifi MAC with offset of 1 as eth0 MAC */
ath79_init_mac(ath79_eth0_data.mac_addr,
art + WNDAP360_WMAC0_MAC_OFFSET, 1);
ap94_pci_init(art + WNDAP360_CALDATA0_OFFSET,
art + WNDAP360_WMAC0_MAC_OFFSET,
art + WNDAP360_CALDATA1_OFFSET,
art + WNDAP360_WMAC1_MAC_OFFSET);
The ath79 port made a questionable change for eth0 being just art with
no offset. That MAC ends up being the OUI for Atheros.
WNDAP360_WMAC1_MAC_OFFSET is the same as WNDAP360_WMAC0_MAC_OFFSET
except with the first hex value being subtracted by 2, which is not a
valid OUI.
And newer Netgear firmware seems to assign differently as well,
art_120C as a base and the others incremented by 0x8.
Switch the assignment to the latest firmware and add label-mac-device to
document that the first Wi-FI MAC address is printed on the device.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22895
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Convert the last remaining userspace eeprom for ath9k to nvmem. Well,
easily converted at least.
wifi MAC has to be handled in userspace as the kernel nvram driver works
on memory mapped addresses, not mtd ones.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14666
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
It appears 683-of_net-add-mac-address-to-of-tree.patch relies on the
mac-address nvmem property being present. These nodes don't need it as
they take it from the eeprom but label-mac-device needs it.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14666
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
I mistakenly assumed napi_gro_receive could not be used here. But it
turns out I needed to take the address of mal's napi_device.
Important to get everything possible out of this old underpowered
platform.
Upstream for whatever reason wants to do away with
netif_receive_skb_list.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23382
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Fix by replacing memset with manual 0 assignments. The first patch was
rightly rejected by upstream as it affects everything so keep it in 9xx.
Upstream message for it is:
dcbz instruction shouldn't be used on non-cached memory. Using
it on non-cached memory can result in alignment exception and
implies a heavy handling.
Instead of silentely emulating the instruction and resulting in high
performance degradation, warn whenever an alignment exception is
taken in kernel mode due to dcbz, so that the user is made aware that
dcbz instruction has been used unexpectedly by the kernel.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23382
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
gpio-button-hotplug skips buttons with button->irq set because it cannot
handle true interrupt-only gpio-keys descriptions. That check also skips
valid GPIO-backed buttons that provide a separate interrupt specifier, such
as the Meraki MX60 reset button.
Try to acquire the GPIO descriptor before deciding that an explicit-IRQ
button is unsupported. Continue to skip true interrupt-only buttons, and
make the IRQ setup and teardown paths ignore skipped entries.
Tested on: Cisco Meraki MX60. Reset button now works.
Fixes: 23845fa10b ("gpio-button-hotplug: do not error on interrupt attached keys")
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23382
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This was needed before the env-size binding was available to restrict it
to a specific size. No longer a need for this.
This should be no-op since status = "disabled";
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22367
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It appears 683-of_net-add-mac-address-to-of-tree.patch relies on the
mac-address nvmem property being present. wmac itself doesn't need it as
it takes it from the eeprom but label-mac-device needs it.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21035
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
mediatek,mtd-eeprom predates nvmem and is being phased out.
At first glance, it looks like it's doing something useful with its
big-endian binding. However on further inspection, big-endian is handled
in the same function that mediatek,mtd-eeprom is handled. In addition,
the older mtd_read way of extracting the firmware byteswaps the data
on big endian hosts which big-endian byteswaps back. nvmem does not do
such byteswapping.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23115
Signed-off-by: Robert Marko <robimarko@gmail.com>
A script was ran that checks the label-mac-device node to see if it has
nvmem definitions as label-mac-device requires nvmem.
This is mostly a change to make the script happy. No indended functional
difference.
Add a change to qca9533_yuncore_cpe830.dts adding an nvmem definition to
wmac. Seems to have been some kind of oversight where it's specified in
nvmem but not used. label-mac-device needs an NVMEM definition.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22907
Signed-off-by: Robert Marko <robimarko@gmail.com>
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23191
Signed-off-by: Robert Marko <robimarko@gmail.com>
Normally WMAC handles 2.4ghz on ath79 devices. Some older units though
handle 5ghz on WMAC and 2.4ghz on pcie. This can be seen by the
frequemcy limits placed on each interface.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23191
Signed-off-by: Robert Marko <robimarko@gmail.com>
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23191
Signed-off-by: Robert Marko <robimarko@gmail.com>
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23191
Signed-off-by: Robert Marko <robimarko@gmail.com>
