To further improve cleanup and maintenance usage, move the kernel
version files to target/linux/generic directory. This permits to self
contain any change to the specific generic directory instead of having
to bload the include directory of periodic changes.
In kernel-version.mk we now use GENERIC_PLATFORM_DIR provided by
target.mk. To make this work, we need to move the inclusion of
kernel-version.mk in target.mk right after GENERIC_PLATFORM_DIR is
defined.
This also comes to permit downstream project to provide a custom generic
directory and specify the kernel version complete of the hash and the
minor version without having to affect other feeds.
In such case both generic and the target directory are provided as feeds
and OpenWrt reference these specific one instead of the generic one.
For downstream it's still suggested and preferable to all match the
shipped generic kernel minor version but this change permits to at least
enforce good practice instead of having to bloat OpenWrt include file of
all kind of downstream changes (making porting to OpenWrt mainline even
more difficult)
Link: https://github.com/openwrt/openwrt/pull/18537
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Patch 87cb0446b7 also applies to higher kernel versions.
To apply to them it has been moved to a separate file in pending.
Fixes: 87cb0446b7 ("generic: fix broken TCP fraglist GRO patch")
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/18511
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fix an error while building target/linux x64 on macOS 15.4 host,
due to the PATH_MAX macro being redefined:
mkdir -p /Volumes/test/openwrt/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.86/tools/objtool && make O=/Volumes/test/openwrt/build_dir/target-x86_64_musl/linux-x86_64/linux-6.6.86 subdir=tools/objtool --no-print-directory -C objtool
exec-cmd.c:15:9: error: 'PATH_MAX' macro redefined [-Werror,-Wmacro-redefined]
15 | #define PATH_MAX 4096
| ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/syslimits.h:103:9: note: previous definition is here
103 | #define PATH_MAX 1024 /* max bytes in pathname */
| ^
exec-cmd.c is compiled as part of objtool to run on the host, and
therefore host headers are used, where PATH_MAX is already defined.
Using an old OpenWRT snapshot from 2025-02-16, where linux-6.6.77
used to build correctly, does not help. Reverting from Xcode 16.3 to
16.2 does not help either.
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18530
Signed-off-by: Robert Marko <robimarko@gmail.com>
Upstream version of ARM gc sections skip eeping some section. It was
reported some kernel load hang hence restore what we original did and
introduce a new patch that add the additional entry on top of the
upstream version.
Fixes: #18500
Fixes: 7843f21c51 ("generic: replace ARM gc sections patch with upstream version")
Tested-by: Stefan Kalscheuer <stefan@stklcode.de> (Turris Omnia)
Link: https://github.com/openwrt/openwrt/pull/18503
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Some regression were reported with the backported upstream version. Old
kernel require an additional flush in some case and this was handled in
the old downstream patch.
Reintroduce the flush to fix the regression and refresh affected patch.
Fixes: f63d64ede0 ("generic: move patch from pending to backport")
Link: https://github.com/openwrt/openwrt/pull/18501
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The ATS SFP GT-T quirk patch was backported to stable kernel 6.6 but
was not notice while bumping the kernel version as they listed the quirk
at the bottom of the SFP quirk table while our hack patch put it at the
top.
With migrating to the upstream version, the duplication was made more
apparent.
Drop the double entry for the SFP module as it's already there and not
needed and refresh patches.
Link: https://github.com/openwrt/openwrt/pull/18484
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Replace ARM gc sections patch with upstream version. It seems this
feature is finally supported upstream with some minor difference.
In theory the upstream version should cut even more stuff, this really
needs to be evaluated if it's OK also to handle regression with the
kernel 6.12 update.
Link: https://github.com/openwrt/openwrt/pull/18464
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Replace SFP ignore TX FAULT with upstream version by backporting the 2
related upstream patch. Refresh SFP affected patch.
Link: https://github.com/openwrt/openwrt/pull/18464
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move all patch that got merged upstream from pending to backport and add
related tag. This is to make it easier to update to kernel 6.12.
Patch 680 required some special care as the upstream version had to be
split in a series of 6 patch.
Referesh all affected patch.
Link: https://github.com/openwrt/openwrt/pull/18464
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
It seems new kernel version introduced -Wmissing-prototypes. This new
warning reported drivers that define non static function that are used
statically in the driver.
Fix this by declaring making those function actually static if not
defined in any header and not used outside of the single driver.
Co-authored-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/18455
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
It seems new kernel linux version reorganized the header include and now
of.h needs to be explicitly included. This should have been done from
when the driver was introduced.
Add the missing of.h header to fix compilation error in later kernel
version.
Co-authored-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/18455
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
QCOM SPI NAND driver got merged upstream hence we can drop the special
patch from qualcommax and qualcommbe target and move them to the generic
backports directory to reduce patch maintenance.
While at it refresh any affected patch and target and also backport other
minor fixup for the SPI NAND driver merged upstream later.
Link: https://github.com/openwrt/openwrt/pull/17788
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Sync jitterentropy source code with linux-6.12 to solve the
issue of jitterentropy initialization failed:
[ 9.523489] jitterentropy: Initialization failed with host not compliant with requirements: 9
[ 9.661916] kmodloader: 1 module could not be probed
[ 9.662377] kmodloader: - jitterentropy_rng - 0
In linux upstream commit cf27d9475f37 ("crypto: jitter - use
permanent health test storage"), when FIPS crypto is disabled,
the health test results are always explicitly skipped. That means
it will never return error code 9 (health test failed) again.
Fixes: https://github.com/openwrt/openwrt/issues/16684
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/18399
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is only used by mach files, which are no longer used in OpenWrt.
Allows removing a custon ath9k_platform.h file.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17445
Signed-off-by: Robert Marko <robimarko@gmail.com>
These only work with and are useful with mach files. Now that those are
gone, this can go too.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17445
Signed-off-by: Robert Marko <robimarko@gmail.com>
Bridge port isolation offload support has been added to the bridge core
and many DSA drivers. mt7530 support was backported in OpenWrt commit
c4e6a147a6 ("generic: 6.6: mt7530: add support for bridge port
isolation").
Backport qca8k support as well.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Link: https://github.com/openwrt/openwrt/pull/18375
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
After booting, a "transmit queue 0 timed out" warning followed by a
register dump was observed. The dump indicates that mtk_hw_init() does
not initialize the EEECR during probe. This occurs because the
netdev is allocated in mtk_add_mac(), which is called after
mtk_hw_init(). Consequently, the EEECR register remains uninitialized
until a reset is triggered, causing mtk_hw_init() to run again with a
valid netdev, at which point the register is finally set.
To address this, instead of modifying the probe sequence, latch the Tx
LPI enable state and timer value, and move the EEECR register
initialization to mtk_mac_link_up() to ensure proper setup when the
interface comes up.
Additionally, the splat reveals that LPI functionality is controlled by
the MAC_MCR_EEE bits in the MCR register. Update mtk_set_eee() to
modify these bits accordingly.
Fixes: d8315d5358 ("kernel: backport Mediatek SoC EEE support")
Fixes: edddbaf79c ("kernel: Mediatek: set default EEE Tx LPI timer")
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Patches 751-03 and 751-04 as a result of commit 6407ef8d2b
were incorrectly placed in the backport folder.
So they return to their proper place.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/18253
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In case a broken fit image is present on flash the fitblk driver would
not map any /dev/fit* devices, but also not always close the block device
the image resides on. In case of ubiblock devices this is fatal as one
then cannot remove the ubiblock device (-EBUSY), and hence cannot replace
the broken image.
Always close the block device in case no sub-image was mapped.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Move "# CONFIG_NVMEM_LAYOUT_ASCII_ENV is not set" to the correct location.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/18335
Signed-off-by: Nick Hainke <vincent@systemli.org>
All devices have already been migrated to the upstream PHY LED
API. This prevents users from adding new devices using this hack.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
The ar8216 switch driver supports exposing configuration of AR8327 and
AR8337 switch LEDs to the userspace, however it is only configurable
through platform data, causing the devices ported from ar71xx target to
lack the support.
Since there is still a long way to go until we can migrate the target to
qca8k, an interim solution is needed.
Extend ar8327_hw_config_of function to parse a "leds"
subnode, which will populate the missing platform data based on device
tree contents, and restore the existing support for the LEDs.
Standard bindings apply, mapping "reg" property to LED index, with
addition of "qca,led-mode" property, which selects HW (0) or SW (1)
mode, defaulting to HW mode.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/12487
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Switch LEDs configured as active-low remain low instead of high upon
initialization, because in ar8327_leds_init, no distinction is made with
regards to LED pattern based on active_low property - only whether HW
mode is active. Select the proper initial pattern based also on
active_low to fix that.
While at that, simplify the equation ruling pattern selection for
setting brightness, avoiding unnecessary binary XOR operation, not
really valid for 'bool' type.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/12487
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, if the phy driver does not implement the led_brightness_set
function, setting the LED will result in the following error message:
leds mdio-bus:*:green:lan: Setting an LED's brightness failed (-524)
Backport a patch to silence this error message.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://github.com/openwrt/openwrt/pull/18080
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
RTL8261N is used on some Airoha and Realtek devices. Move the driver
from Mediatek to generic so it can be used everywhere.
Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18163
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The CONFIG_NET_SWITCHDEV option is needed by CONFIG_DSA and some other
options. It is boolean, we have to compile it into the kernel it self.
Activate it for all targets in the generic configuration, it is already
activated for most of them. This allows to install DSA drivers as a
module.
On the ramips/mt7620 target the kernel would grown by 4.5kB.
For some small targets which do not support a DSA switch by default the
option is deactivated.
Link: https://github.com/openwrt/openwrt/pull/17668
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes the handling of some FS copper SFP modules using the RollBall
protocol and needing some extra treatment.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This is only relevant for devices with USB support, and in itself changes
nothing in the kernel build. However, it is useful to further simplify the
dependencies of some USB network devices.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
The kmod-mlxsw-spectrum driver activated CONFIG_DCB indirectly already
on all targets which are building this driver. All other DCB capable
driver did not activate their DCB support.
CONFIG_DCB increases the uncompressed kernel size by about 7.8KB.
CONFIG_DCB is only needed some data center Ethernet cards and not used
on normal routers. Activate it only on the x86_64 and the armsr_arm64
target which are used on normal servers or in VMs.
Link: https://github.com/openwrt/openwrt/pull/17672
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Quoting the kconfig description for CONFIG_PCPU_DEV_REFCNT:
network device refcount are using per cpu variables if this option is
set. This can be forced to N to detect underflows (with a performance
drop).
This was introduced from kernel 5.13 and was wrongly set as disabled.
Some target actually enables it but this should be always enabled unless
refcount needs to be debugged (unlikely for production images)
Enable in generic and drop the entry in every other target.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18174
Signed-off-by: Robert Marko <robimarko@gmail.com>
Due to API changes during the backport, the default value of Tx LPI
timer is accidentally left unset, breaking the network if EEE is on.
Set the default timer to 1ms on init, and fix an incorrect condition.
Fixes: d8315d5358 ("kernel: backport Mediatek SoC EEE support")
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Prior to commit 8a7d12d674,
cdc-ethernet USB LTE modems (e.g. Quectel EC200A) were consistently named
usb0. After 8a7d12d67, devices began renaming to eth1 due to an assumption
that local MAC addresses originate exclusively from the kernel. Some
devices provide driver-assigned local MACs, causing point-to-point
interfaces with driver-set MACs to adopt eth%d names instead of usb%d.
Restore the naming exception for point-to-point devices: interfaces
without driver MACs or with driver-provided local MACs will retain the
usb%d convention. This addresses issues reported in [1] and fixed in [2].
[1] https://lore.kernel.org/all/Z00udyMgW6XnAw6h@atmark-techno.com/
[2] https://lore.kernel.org/all/20241203130457.904325-1-asmadeus@codewreck.org/
Tested-by: Ahmed Naseef <naseefkm@gmail.com>
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17757
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport Mediatek SoC EEE support from net-next upstream.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[refreshed patches]
