* [PATCH v9 10/38] phy: rockchip: usbdp: Fix LFPS detect threshold control
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, William Wu
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
From: William Wu <william.wu@rock-chips.com>
According to the LFPS Tx Low Power/LFPS Rx Detect Threshold [1],
the device under test(DUT) must not respond if LFPS below the
minimum LFPS Rx Detect Threshold 100mV. Test fail on Rockchip
platforms, because the default LFPS detect threshold is set to
65mV.
The USBDP PHY LFPS detect threshold voltage could be set to
30mV ~ 140mV, and since there could be 10-20% PVT variation,
we set LFPS detect threshold voltage to 110mV.
[1] https://compliance.usb.org/resources/LFPS_Rx_Tx_Low_Power_Compliance_Update_Rev5.pdf
Signed-off-by: William Wu <william.wu@rock-chips.com>
[Taken over from rockchip's kernel tree; the registers are not described
in the TRM]
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 923279ed7d77..8202abab4274 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -413,7 +413,8 @@ static const struct reg_sequence rk_udphy_init_sequence[] = {
{0x0070, 0x7d}, {0x0074, 0x68},
{0x0af4, 0x1a}, {0x1af4, 0x1a},
{0x0440, 0x3f}, {0x10d4, 0x08},
- {0x20d4, 0x08}, {0x0024, 0x6e}
+ {0x20d4, 0x08}, {0x0024, 0x6e},
+ {0x09c0, 0x0a}, {0x19c0, 0x0a}
};
static inline int rk_udphy_grfreg_write(struct regmap *base,
--
2.53.0
^ permalink raw reply related
* [PATCH v9 13/38] phy: rockchip: usbdp: Limit DP lane count to muxed lanes
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, Sashiko
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
In theory the DP controller could request 4 lanes when the PHY is
restricted to 2 lanes as the other half is used by USB3.
With the current user (DW-DP) this cannot happen, but as the check is
cheap and users might change in the future protect things accordingly.
Not doing so would corrupt USB3 usage by the following code configuring
the voltages.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612165546.98E1F1F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index da15178d7f16..0cfd23a405cb 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1134,6 +1134,9 @@ static int rk_udphy_dp_phy_verify_link_rate(struct rk_udphy *udphy,
static int rk_udphy_dp_phy_verify_lanes(struct rk_udphy *udphy,
struct phy_configure_opts_dp *dp)
{
+ if (dp->lanes > udphy->dp_lanes)
+ return -EINVAL;
+
switch (dp->lanes) {
case 1:
case 2:
--
2.53.0
^ permalink raw reply related
* [PATCH v9 14/38] phy: rockchip: usbdp: Rename DP lane functions
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
The common prefix for DisplayPort related functions is rk_udphy_dp_
(with a final _), so update the two DP lane functions to follow that
scheme.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 0cfd23a405cb..ee7ec86bda9e 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -550,7 +550,7 @@ static void rk_udphy_usb_bvalid_enable(struct rk_udphy *udphy, u8 enable)
* ---------------------------------------------------------------------------
*/
-static void rk_udphy_dplane_select(struct rk_udphy *udphy)
+static void rk_udphy_dp_lane_select(struct rk_udphy *udphy)
{
const struct rk_udphy_cfg *cfg = udphy->cfgs;
u32 value = 0;
@@ -579,7 +579,7 @@ static void rk_udphy_dplane_select(struct rk_udphy *udphy)
FIELD_PREP(DP_AUX_DOUT_SEL, udphy->dp_aux_dout_sel) | value);
}
-static void rk_udphy_dplane_enable(struct rk_udphy *udphy, int dp_lanes)
+static void rk_udphy_dp_lane_enable(struct rk_udphy *udphy, int dp_lanes)
{
u32 val = 0;
int i;
@@ -1084,9 +1084,9 @@ static int rk_udphy_dp_phy_power_on(struct phy *phy)
if (ret)
goto unlock;
- rk_udphy_dplane_enable(udphy, udphy->dp_lanes);
+ rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);
- rk_udphy_dplane_select(udphy);
+ rk_udphy_dp_lane_select(udphy);
unlock:
mutex_unlock(&udphy->mutex);
@@ -1104,7 +1104,7 @@ static int rk_udphy_dp_phy_power_off(struct phy *phy)
struct rk_udphy *udphy = phy_get_drvdata(phy);
mutex_lock(&udphy->mutex);
- rk_udphy_dplane_enable(udphy, 0);
+ rk_udphy_dp_lane_enable(udphy, 0);
rk_udphy_power_off(udphy, UDPHY_MODE_DP);
mutex_unlock(&udphy->mutex);
--
2.53.0
^ permalink raw reply related
* [PATCH v9 07/38] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, Sashiko
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
Fix theoretical issue, that failure to deassert the reset lines would
result in an SError in follow-up register access. Note, that this cannot
happen with current code, since the Rockchip reset driver never returns
any errors for (de)asserting reset lines.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/message/20260619154903.2225A1F000E9%40smtp.kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index d73455370113..5d0e4f82de2f 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -936,7 +936,9 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
return ret;
}
- rk_udphy_reset_deassert_all(udphy);
+ ret = rk_udphy_reset_deassert_all(udphy);
+ if (ret)
+ goto exit;
regmap_read(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET, &value);
if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value)) {
@@ -946,9 +948,10 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
msleep(100);
}
+exit:
rk_udphy_disable(udphy);
- return 0;
+ return ret;
}
static int rk_udphy_parse_dt(struct rk_udphy *udphy)
--
2.53.0
^ permalink raw reply related
* [PATCH v9 06/38] phy: rockchip: usbdp: Drop seamless DP takeover
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, Sashiko
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
Right now the DRM drivers do not support seamless DP takeover and I'm
I'm not aware of any bootloader implementing this feature either.
In any case this feature would be limited to boards using the USBDP PHY
for a DP or eDP connection instead of the more commonly USB-C connector.
With USB-C's DP AltMode a seamless DP takeover requires handing over the
state of the TCPM state machine from the bootloader to the kernel. This
in turn requires a huge amount of work to keep the state machine
implementations synchronized. It's very unlikely we will see somebody
implementing that in the foreseeable future.
As the current code is obviously buggy and untested, let's simply drop
support for seamless DP takeover. It can be re-implemented cleanly once
somebody adds all missing bits.
Technically the VOP side should be disabled first to avoid data being
send to an unpowered PHY from the running pipeline. As a workaround this
force disables HPD. I'm not sure if this would be good enough, but cannot
test as there is no support in the bootloaders known to me and my test
boards route USBDP to USB-C connectors.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 3fc8222fcaec..d73455370113 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -926,6 +926,7 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
{
+ const struct rk_udphy_cfg *cfg = udphy->cfgs;
int ret;
u32 value;
@@ -938,10 +939,14 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
rk_udphy_reset_deassert_all(udphy);
regmap_read(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET, &value);
- if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value))
- udphy->status = UDPHY_MODE_DP;
- else
- rk_udphy_disable(udphy);
+ if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value)) {
+ dev_info(udphy->dev, "Started with DP PHY pre-enabled; seamless takeover unsupported\n");
+ rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, false);
+ /* Wait for VOP side to shut up */
+ msleep(100);
+ }
+
+ rk_udphy_disable(udphy);
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v9 00/38] phy: rockchip: usbdp: Clean up the mess
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, Sashiko, William Wu
This series does a major overhaul of the Rockchip USBDP driver. The
initial main goal was to add USB-C DP AltMode support to the RK3576
and RK3588 and this series still prepares the PHY driver for exactly
that. But in addition to that I uncovered a huge amount of issues,
that are fixed along the way. Some of the more interesting ones are:
* Currently the driver might trigger a fatal SError on USB-C hotplug,
since re-initializing the PHY stops the clocks going to DWC3. If
the DWC3 driver tries to access its registers at the same time the
system will crash.
* The DWC3 hardware can get into a buggy state when the PHY is
disabled, which results in the PHY not coming up properly again.
* Swithcing the USB-C connector orientation during hotplug breaks
USB3 speed, as the PHY is not being re-initialized.
* Once DP is support the PHY initializes DP mode, even when the DRM
side did not request DP support.
* The driver has some locking issues uncovered by Sashiko.
In addition to these bigger ones, Sashiko also found a bunch of
minor problems, which are mostly harmless, but were fixed while
going at it.
I've tested the v9 code changes with dozens of replugs of different
devices (2 different USB-C hubs with USB3 + HDMI via DP AltMode,
1 USB-C to HDMI adapter [4 lanes DP AltMode], 1 USB-C to DP adapter
[4 lanes DP AltMode], 1 USB-C to NVMe adapter [no DP AltMode] as
well as a direct USB-C connection to a Dell display) on a Sige 5
board and haven't run into any issues. In all cases USB3 was working
in both directions and DP mode was properly initialized, so that
the DRM driver could query the available modes.
Technically some of the later patches are fixes, that one would
expect at the beginning of the series, but they are only possible
after the big cleanups.
Changes in v9:
- Link to v8: https://lore.kernel.org/r/20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com
- Update DT binding to explicitly mention that port@3 is for the
DP aux channel and not DP in general (Sashiko got this wrong)
- Add a 100ms cooldown sleep in "Drop seamless DP takeover" after HPD
is force disabled (Sashiko)
- Update comment in "Register DP aux bridge" to explain why port@3 is
checked, but port@0 is used (Sashiko)
- Check for high-speed only mode in "Support going from DP-only mode to
USB mode" (Sashiko)
- Add new patch for rk_udphy_reset_deassert error handling (Sashiko)
- Add new patch to avoid enabling USB3 in high-speed only mode during
PHY reinit (Sashiko)
- Add 3 more patches to handle the LCPLL lock issue mentioned in the v8
cover letter after feedback from Rockchip. Apparently the DWC3 does
not cope very well with the PHY disappearing resulting in the PIPE
interface misbehaving, which in turn results in the LCPLL not locking.
The new patches avoid this by asserting DWC3_GUSB3PIPECTL_PHYSOFTRST.
As this assert needs to be done when the PHY wants to reset, a new
notifier system has been implemented to support triggering this from
the PHY driver. This also means, that this version now also involves
the USB subsystem.
- Drop old patch trying to solve the DP-only -> USB mode switch in
favour of 5 new patches completely rewriting and simplifying the
power status handling. The new code ensures that the PHY always
has the right modes enabled and also makes sure a re-init happens
on an orientation change.
- rebased on v7.2-rc1
Changes in v8:
- Link to v7: https://lore.kernel.org/r/20260625-rockchip-usbdp-cleanup-v7-0-38eb3cf654fd@collabora.com
- Move patch "Limit DP lane count to muxed lanes" after single lane
support, which introduces dp_lanes variable to make sure series
is bi-sectable (Sashiko)
- Force disable HPD in "Drop seamless DP takeover" patch and update
patch description to mention potential issues with SErrors for
bootloaders really keeping the DW-DP on. As mentioned in the new
commit message this is untested as I'm not aware of such a
bootloader anyways; this also means we need to keep the HPD GRF
register defines in the 'Drop DP HPD handling' patch (Sashiko)
- Fix mode logic in "Properly handle TYPEC_STATE_SAFE and
TYPEC_STATE_USB" patch; I blame the heat (Sashiko)
- Improve "Support going from DP-only mode to USB mode" patch to
better handle starting in DP only mode; due to TypeC logic
starting delayed this does not really happen, though (Sashiko)
- Improve "Support going from DP-only mode to USB mode" to avoid
checking previous state and instead power on USB state based
on previous requested state to avoid effects from the flip
callback (Sashiko)
- Update the debug message patch to include some more info
- Ad one more patch, which disables USB3 at startup and drops
the -EPROBE_DEFER logic
Changes in v7:
- Link to v6: https://lore.kernel.org/r/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com
- Add new patch handling missing clock-names in DT gracefully (Sashiko)
- Add new patch handling rk_udphy_reset_deassert_all errors in init check (Sashiko)
- Add new patch to handle Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB (Sashiko)
- Add new patch to avoid xHCI SErrors
Changes in v6:
- Link to v5: https://lore.kernel.org/r/20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com
- Add explicit <linux/string_choices.h> include in last patch (Sashiko)
- Add new patch moving mode_change update after error handling (Sashiko)
- Add new patch fixing error masking of devm_clk_bulk_get_all() (Sashiko)
- Add new patch dropping seamless DP takeover as it is non-functional and buggy (Sashiko)
- Add new patch limiting DP lane count to muxed lanes (Sashiko)
- Add error handling in the patch that keeps clocks running on PHY re-init (Sashiko)
- Also look for DP being configured to second lane for the flip config
in DP single-lane mode, which should at least keep USB working for
this super unusual config (Sashiko)
- Drop useless ret variable in patch introducing guard() for the mutex
- Add error handling for PHY re-enablement in the patch fixing support for
DP-only -> USB mode (Sashiko)
Changes in v5:
- Link to v4: https://lore.kernel.org/r/20260428-rockchip-usbdp-cleanup-v4-0-7775671ece22@collabora.com
- Picked up Acked-by from Rob Herring for DT binding
- Fix typos in commit messages/comments
- Add Fixes tag to "Do not looe USB3 PHY status" patch
- Collect Reviewed-by: Neil Armstrong for multiple patches
- Drop now unused code from "Drop DP HPD handling" patch (Sashiko)
- Ignore mux events not involving DP AltMode (Sashiko)
- Add new patch to support going back from DP only mode to USB combo
mode; technically this is a fix, but DP mode does not yet work
upstream, so it does not matter (Sashiko)
- Add new patch adding a few debug messages, which are useful
to investigate potential hotplug issues in the future
- Sashiko comments about the DT binding and property usage
are wrong as the first port is for the superspeed lanes
used for DP and USB, while the last port is just about
DP aux. I ignored them.
- There is a pre-existing bug, that can already be hit with the
upstream kernel and that the series doesn't fix properly:
Accessing the USB3 controller registers requires the USB PHY
running, since it provides a clock. Re-initializing the PHY
means there is a race-condition - if the system tries to access
the USB3 controller in parallel to the re-init, the system will
hang and/or fail with an SError. By keeping the clocks running
and only asserting the resets this time is minimized by this
series. A proper fix for this will be looked into independently
from this series.
- I used v7.1-rc6 as base, but the driver has no changes since
6.18 even in linux-next and there are no pending patches for
it on the mailinglist either, so it applies to *any* recent
kernel branch.
Changes in v4:
- Link to v3: https://lore.kernel.org/r/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com
- rebased to v7.1-rc1 (no changes)
- Update DRM bridge registration patch to avoid registration when DP aux
port is not connected to anything, since this results in errors and some
boards use USBDP instances for USB3 only.
- Add patch renaming mode_change into phy_needs_reinit
- Add patch to re-init PHY on orientation change
- Add patch to factor out lane_mux_sel setup
- Add patch to handle mutex via guard functions
Changes in v3:
- Link to v2: https://lore.kernel.org/r/20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com
- Add patch to register the USBDP PHY as DRM bridge
- Add patch to describe ports in DT binding (used by the DRM bridge)
- Add patch to drop HPD handling from the PHY
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20260203-rockchip-usbdp-cleanup-v1-0-16a6f92ed176@collabora.com
- Added new patches to fix USB3 SError
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Frank Wang (1):
phy: rockchip: usbdp: Amend SSC modulation deviation
Sebastian Reichel (35):
dt-bindings: phy: rockchip-usbdp: add improved ports scheme
phy: rockchip: usbdp: Update mode_change after error handling
phy: rockchip: usbdp: Do not lose USB3 PHY status
phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
phy: rockchip: usbdp: Handle missing clock-names DT property gracefully
phy: rockchip: usbdp: Drop seamless DP takeover
phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check
phy: rockchip: usbdp: Keep clocks running on PHY re-init
phy: rockchip: usbdp: Add missing mode_change update
phy: rockchip: usbdp: Limit DP lane count to muxed lanes
phy: rockchip: usbdp: Rename DP lane functions
phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
phy: rockchip: usbdp: Cleanup DP lane selection function
phy: rockchip: usbdp: Register DP aux bridge
phy: rockchip: usbdp: Drop DP HPD handling
phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit
phy: rockchip: usbdp: Re-init the PHY on orientation change
phy: rockchip: usbdp: Factor out lane_mux_sel setup
phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB
phy: rockchip: usbdp: Use guard functions for mutex
phy: rockchip: usbdp: Clear USB status on PHY exit
phy: rockchip: usbdp: Hold mutex in DP PHY configure
phy: rockchip: usbdp: Add some extra debug messages
phy: rockchip: usbdp: Avoid xHCI SErrors
phy: rockchip: usbdp: Disable USB3 on probe
phy: rockchip: usbdp: Handle rk_udphy_reset_deassert errors
phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode
phy: core: add notifier infrastructure
usb: dwc3: core: support PHY reset notifications
phy: rockchip: usbdp: Add phy reset notification support
phy: rockchip: usbdp: Rename mode to hw_mode
phy: rockchip: usbdp: Simplify power state handling
phy: rockchip: usbdp: Rename phy_needs_reinit to orientation_changed
phy: rockchip: usbdp: Re-init PHY on mux change
phy: rockchip: usbdp: Power optimizations
William Wu (1):
phy: rockchip: usbdp: Fix LFPS detect threshold control
Zhang Yubing (1):
phy: rockchip: usbdp: Support single-lane DP
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 +
drivers/phy/phy-core.c | 57 +++
drivers/phy/rockchip/Kconfig | 2 +
drivers/phy/rockchip/phy-rockchip-usbdp.c | 522 ++++++++++-----------
drivers/usb/dwc3/core.c | 82 ++++
drivers/usb/dwc3/core.h | 16 +
include/linux/phy/phy.h | 40 ++
7 files changed, 470 insertions(+), 272 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260203-rockchip-usbdp-cleanup-5b59dfb561a3
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* [PATCH v9 01/38] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
Currently the Rockchip USBDP PHY is missing a documented port scheme.
Meanwhile upstream RK3588 DTS files are a bit messy and use different
port schemes. The upstream USBDP PHY Linux kernel driver does not yet
parse the ports at all and thus does not create any implicit ABI either.
But with the current mess it is not possible to properly support USB-C
DP AltMode. Thus this introduces a proper port scheme following roughly
the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
with a slight difference that there is an additional port for the
USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
index 8b7059d5b182..c1a1384118da 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
@@ -114,6 +114,29 @@ properties:
A port node to link the PHY to a TypeC controller for the purpose of
handling orientation switching.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for USB (or DP when configured into 4 lane
+ mode), which should point to the superspeed port of a USB connector.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the DisplayPort controller
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for DP Auxiliary, which should either point to
+ the SBU port of a USB-C connector or a DisplayPort connector input port.
+
required:
- compatible
- reg
--
2.53.0
^ permalink raw reply related
* [PATCH v9 02/38] phy: rockchip: usbdp: Update mode_change after error handling
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, Sashiko
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.
Note, that no errors have been seen on real hardware and failures would
most likely be fatal and require at least a full reboot as the function
already asserts the PHY reset lines. So this is more of a theoretical
issue.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index fba35510d88c..a5ffdf7a6e76 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
}
if (udphy->status == UDPHY_MODE_NONE) {
- udphy->mode_change = false;
ret = rk_udphy_setup(udphy);
if (ret)
return ret;
if (udphy->mode & UDPHY_MODE_USB)
rk_udphy_u3_port_disable(udphy, false);
- } else if (udphy->mode_change) {
udphy->mode_change = false;
+ } else if (udphy->mode_change) {
udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
@@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
ret = rk_udphy_setup(udphy);
if (ret)
return ret;
+ udphy->mode_change = false;
}
udphy->status |= mode;
--
2.53.0
^ permalink raw reply related
* [PATCH v9 04/38] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
From: Sebastian Reichel @ 2026-07-01 23:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thinh Nguyen,
Greg Kroah-Hartman
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, linux-usb, Sebastian Reichel, Sashiko
In-Reply-To: <20260702-rockchip-usbdp-cleanup-v9-0-e31efbb62d2e@collabora.com>
If devm_clk_bulk_get_all() returns -EPROBE_DEFER, it is replaced with
-ENODEV, permanently failing the driver probe instead of allowing it to
defer. Avoid masking the error code to fix the issue.
This effectively drops returning -ENODEV in case no clocks are being
described in DT. This special case will now be handled by the follow-up
check searching for "refclk" and exit with -EINVAL.
None of this will be hit in practice, since the driver is only used by
RK3588 and RK3576 - on these platforms the DT is validated to contain
the clocks and the clock driver is force probed early. Thus there is
no need to backport this.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 12dfdd470a78..2845a012eafc 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -427,8 +427,8 @@ static int rk_udphy_clk_init(struct rk_udphy *udphy, struct device *dev)
int i;
udphy->num_clks = devm_clk_bulk_get_all(dev, &udphy->clks);
- if (udphy->num_clks < 1)
- return -ENODEV;
+ if (udphy->num_clks < 0)
+ return udphy->num_clks;
/* used for configure phy reference clock frequency */
for (i = 0; i < udphy->num_clks; i++) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/5] arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative
From: Oliver Upton @ 2026-07-01 23:30 UTC (permalink / raw)
To: Colton Lewis
Cc: stable, Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Zenghui Yu, Mingwei Zhang,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260701204342.2654385-3-coltonlewis@google.com>
On Wed, Jul 01, 2026 at 08:43:39PM +0000, Colton Lewis wrote:
> From: Marc Zyngier <maz@kernel.org>
>
> [ Upstream commit 3944382fa6f22b54bc3624c9657b98ec34b5ba59 ]
What is this? I have the commit in question as
3944382fa6f22b54fd399632b1af92c28123979b
> For CPUs that have ID_AA64MMFR4_EL1.E2H0 as negative, it is important
> to avoid the boot path that sets HCR_EL2.E2H=0. Fortunately, we
> already have this path to cope with fruity CPUs.
>
> Tweak init_el2 to look at ID_AA64MMFR4_EL1.E2H0 first.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> Link: https://lore.kernel.org/r/20240122181344.258974-8-maz@kernel.org
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> arch/arm64/kernel/head.S | 23 +++++++++++++++--------
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 6517bf2644a08..e32c8dd0b17a7 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -589,25 +589,32 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
> mov_q x1, INIT_SCTLR_EL1_MMU_OFF
>
> /*
> - * Fruity CPUs seem to have HCR_EL2.E2H set to RES1,
> - * making it impossible to start in nVHE mode. Is that
> - * compliant with the architecture? Absolutely not!
> + * Compliant CPUs advertise their VHE-onlyness with
> + * ID_AA64MMFR4_EL1.E2H0 < 0. HCR_EL2.E2H can be
> + * RES1 in that case.
> + *
> + * Fruity CPUs seem to have HCR_EL2.E2H set to RES1, but
> + * don't advertise it (they predate this relaxation).
> */
> + mrs_s x0, SYS_ID_AA64MMFR4_EL1
> + ubfx x0, x0, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
> + tbnz x0, #(ID_AA64MMFR4_EL1_E2H0_SHIFT + ID_AA64MMFR4_EL1_E2H0_WIDTH - 1), 1f
> +
> mrs x0, hcr_el2
> and x0, x0, #HCR_E2H
> - cbz x0, 1f
> -
> + cbz x0, 2f
> +1:
> /* Set a sane SCTLR_EL1, the VHE way */
> pre_disable_mmu_workaround
> msr_s SYS_SCTLR_EL12, x1
> mov x2, #BOOT_CPU_FLAG_E2H
> - b 2f
> + b 3f
>
> -1:
> +2:
> pre_disable_mmu_workaround
> msr sctlr_el1, x1
> mov x2, xzr
> -2:
> +3:
> __init_el2_nvhe_prepare_eret
>
> mov w0, #BOOT_CPU_MODE_EL2
> --
> 2.55.0.rc2.803.g1fd1e6609c-goog
>
>
^ permalink raw reply
* Re: [PATCH 0/5] Backport ARM64 VHE boot fixes to 6.6.y
From: Oliver Upton @ 2026-07-01 23:23 UTC (permalink / raw)
To: Colton Lewis
Cc: stable, Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Zenghui Yu, Mingwei Zhang,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260701204342.2654385-1-coltonlewis@google.com>
The subject prefix should be "[PATCH 6.6 0/5]" so people know right up
front where this is going.
On Wed, Jul 01, 2026 at 08:43:37PM +0000, Colton Lewis wrote:
> This series backports VHE CPU boot fixes to the 6.6.y stable branch.
>
> These fixes are already present in the 6.12.y stable branch (and
> newer), but are missing in 6.6.y. They are required to enable booting
> L1 guests with nested virtualization enabled (kvm-arm.mode=nested).
It's a bit worse than this. The architecture retroactively made
FEAT_E2H0 an optional feature, there are now implementations in the wild
that do not support the feature.
> Without these patches, a 6.6.y guest boots with HCR_EL2.E2H
> incorrectly configured (because it misses VHE-only detection or early
> initialization), causing early boot hangs/trap loops.
>
> Conflict resolutions:
> - Patch 4 (KVM: arm64: Initialize HCR_EL2.E2H early) had conflicts in
> arch/arm64/kvm/hyp/nvhe/hyp-init.S due to differences in state
> initialization. Resolved by extracting EL2 state initialization into
> __kvm_init_el2_state.
> - Patch 5 (arm64: Revamp HCR_EL2.E2H RES1 detection) had conflicts in
> arch/arm64/include/asm/el2_setup.h. Resolved by using raw msr hcr_el2
> instead of the missing msr_hcr_el2 macro.
>
>
> Marc Zyngier (4):
> arm64: sysreg: Add layout for ID_AA64MMFR4_EL1
> arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is
> negative
> arm64: Fix early handling of FEAT_E2H0 not being implemented
> arm64: Revamp HCR_EL2.E2H RES1 detection
>
> Mark Rutland (1):
> KVM: arm64: Initialize HCR_EL2.E2H early
>
> arch/arm64/include/asm/el2_setup.h | 52 ++++++++++++++++++++++++++++++
> arch/arm64/kernel/head.S | 17 +++-------
> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 16 +++++++--
> arch/arm64/tools/sysreg | 37 +++++++++++++++++++++
> 4 files changed, 107 insertions(+), 15 deletions(-)
>
>
> base-commit: d1cfde2d5d15be14123bdd1689162bd27f995a90
> --
> 2.55.0.rc2.803.g1fd1e6609c-goog
>
^ permalink raw reply
* Re: [PATCH v2 11/19] ARM: mark ARCH_DOVE as deprecated
From: Ethan Nelson-Moore @ 2026-07-01 22:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Arnd Bergmann, Aaro Koskinen,
Alexander Sverdlin, Alexandre Belloni, Alexandre Torgue,
Andrew Lunn, Ard Biesheuvel, Claudiu Beznea, Daniel Mack,
Frank Li, Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-12-arnd@kernel.org>
On Wed, Jul 1, 2026 at 2:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The Marvell Armada 510 (Dove) platform is supported both as devicetree
> and atags/boardfile variants, with varying degrees of hardware support.
>
> Russell was the last known user of the board file version, and there
> are very few users overall. Unless Russell still needs this variant,
> let's remove after the next LTS kernel, leaving the CONFIG_MACH_DOVE
> variant with devicetree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-dove/Kconfig | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
> index 996888ffcfe7..f547120e223e 100644
> --- a/arch/arm/mach-dove/Kconfig
> +++ b/arch/arm/mach-dove/Kconfig
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> menuconfig ARCH_DOVE
> - bool "Marvell Dove" if ARCH_MULTI_V7
> + bool "Marvell Dove (DEPRECATED)" if ARCH_MULTI_V7
> depends on ATAGS
> select CPU_PJ4
> select GPIOLIB
> @@ -11,7 +11,11 @@ menuconfig ARCH_DOVE
> select PM_GENERIC_DOMAINS if PM
> select PCI_QUIRKS if PCI
> help
> - Support for the Marvell Dove SoC 88AP510
> + Support for the Marvell Dove SoC 88AP510 using board files.
> +
> + Support for this machine will be removed in early 2027, unless
> + there is a strong reason to keep it. Users should migrate to
> + the devicetree-enabled version (CONFIG_MACH_DOVE) instead.
>
> if ARCH_DOVE
>
> --
> 2.39.5
>
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: fix MIB stats collection to be lossless
From: Lorenzo Bianconi @ 2026-07-01 22:43 UTC (permalink / raw)
To: Aniket Negi
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <20260701173941.314795-1-aniket.negi03@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14296 bytes --]
> The current driver resets hardware MIB counters after every read via
> REG_FE_GDM_MIB_CLEAR. This creates a race window: packets arriving
> between the read and the clear are silently lost from statistics.
>
> Fix this by removing the MIB clear and switching to a delta-based
> software tracking approach:
>
> - 64-bit H+L registers (tx/rx ok pkts, ok bytes, E64..L1023):
> read the absolute hardware total directly each poll.
>
> - 32-bit registers (drops, bc, mc, errors, runt, long, ...):
> store the previous raw register value in mib_prev and accumulate
> (u32)(curr - prev) into a 64-bit software counter. Unsigned
> subtraction handles wrap-around transparently.
>
> - tx_len[0]/rx_len[0] ({0,64} RMON bucket) combines RUNT_CNT
> (32-bit, delta-tracked via mib_prev.tx_runt_cnt) and E64_CNT
> (64-bit, absolute). A u64 accumulator tx_runt_accum64 holds the
> running RUNT delta sum so that each poll sets:
> tx_len[0] = tx_runt_accum64 + E64_abs
> without double-counting the E64 value.
>
> Merge airoha_dev_get_hw_stats() into airoha_update_hw_stats(),
> moving the port spin_lock inside so callers do not need a separate
> wrapper.
>
> Signed-off-by: Aniket Negi <aniket.negi03@gmail.com>
Hi Aniket,
just few nits inline. Fixing them:
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
>
> Changes in v2:
> - Store _CNT_L register reads in val before adding to stats, improving
> readability (suggested by Lorenzo Bianconi)
> - Fix double-counting bug in the RUNT+E64 combined bucket: previously
> "+=" for E64 re-added the full absolute counter each poll; now a
> dedicated tx_runt_accum64/rx_runt_accum64 accumulator holds the
> running RUNT delta, and tx_len[0] is assigned (not accumulated) each
> poll as runt_accum64 + E64_abs
> - Replace 7-element tx_len[]/rx_len[] shadow arrays in mib_prev with
> focused tx_runt_cnt/tx_long_cnt and rx_runt_cnt/rx_long_cnt fields;
> only RUNT and LONG are 32-bit and need wrap-around tracking
> - Rename inner struct hw_prev_stats to mib_prev; rename accumulator
> fields to tx_runt_accum64/rx_runt_accum64 for clarity
> - Fix comment alignment in mib_prev struct block
> - Rename airoha_dev_get_hw_stats() to airoha_update_hw_stats() and
> move the port spin_lock inside, removing the separate wrapper
>
> drivers/net/ethernet/airoha/airoha_eth.c | 115 +++++++++++++----------
> drivers/net/ethernet/airoha/airoha_eth.h | 27 ++++++
> 2 files changed, 92 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 59001fd4b6f7..4b7c547de165 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1686,12 +1686,14 @@ static void airoha_qdma_stop_napi(struct airoha_qdma *qdma)
> }
> }
>
> -static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
> +static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> {
> struct airoha_gdm_port *port = dev->port;
> struct airoha_eth *eth = dev->eth;
> u32 val, i = 0;
>
> + spin_lock(&port->stats_lock);
> +
> /* Read relevant MIB for GDM with multiple port attached */
> if (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)
> airoha_fe_rmw(eth, REG_FE_GDM_MIB_CFG(port->id),
> @@ -1701,152 +1703,165 @@ static void airoha_dev_get_hw_stats(struct airoha_gdm_dev *dev)
>
> u64_stats_update_begin(&dev->stats.syncp);
>
> - /* TX */
> + /* TX - 64-bit H+L registers: hw accumulates the total, read directly. */
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
> - dev->stats.tx_ok_pkts += ((u64)val << 32);
> + dev->stats.tx_ok_pkts = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
> dev->stats.tx_ok_pkts += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
> - dev->stats.tx_ok_bytes += ((u64)val << 32);
> + dev->stats.tx_ok_bytes = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
> dev->stats.tx_ok_bytes += val;
>
> + /* TX - 32-bit registers: accumulate delta to handle wrap-around. */
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
> - dev->stats.tx_drops += val;
> + dev->stats.tx_drops += (u32)(val - dev->stats.mib_prev.tx_drops);
> + dev->stats.mib_prev.tx_drops = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
> - dev->stats.tx_broadcast += val;
> + dev->stats.tx_broadcast += (u32)(val - dev->stats.mib_prev.tx_broadcast);
> + dev->stats.mib_prev.tx_broadcast = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
> - dev->stats.tx_multicast += val;
> + dev->stats.tx_multicast += (u32)(val - dev->stats.mib_prev.tx_multicast);
> + dev->stats.mib_prev.tx_multicast = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
> - dev->stats.tx_len[i] += val;
> + dev->stats.mib_prev.tx_runt_accum64 +=
I guess dev->stats.mib_prev.tx_runt64
> + (u32)(val - dev->stats.mib_prev.tx_runt_cnt);
dev->stats.mib_prev.tx_runt64 += (u32)(val -
dev->stats.mib_prev.tx_runt);
> + dev->stats.mib_prev.tx_runt_cnt = val;
> +
> + /* tx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute) → {0, 64} bucket.
> + * Accumulate RUNT delta in tx_runt_accum64, then assign tx_len[0] as
> + * accum + E64_abs so each call gives the correct combined total.
> + */
no new-line here.
> +
> + dev->stats.tx_len[i] = dev->stats.mib_prev.tx_runt_accum64;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
> - dev->stats.tx_len[i] += ((u64)val << 32);
> + dev->stats.tx_len[i] += (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
> dev->stats.tx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_H(port->id));
> - dev->stats.tx_len[i] += ((u64)val << 32);
> + dev->stats.tx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L64_CNT_L(port->id));
> dev->stats.tx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_H(port->id));
> - dev->stats.tx_len[i] += ((u64)val << 32);
> + dev->stats.tx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L127_CNT_L(port->id));
> dev->stats.tx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_H(port->id));
> - dev->stats.tx_len[i] += ((u64)val << 32);
> + dev->stats.tx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L255_CNT_L(port->id));
> dev->stats.tx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_H(port->id));
> - dev->stats.tx_len[i] += ((u64)val << 32);
> + dev->stats.tx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L511_CNT_L(port->id));
> dev->stats.tx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_H(port->id));
> - dev->stats.tx_len[i] += ((u64)val << 32);
> + dev->stats.tx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_L1023_CNT_L(port->id));
> dev->stats.tx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_LONG_CNT(port->id));
> - dev->stats.tx_len[i++] += val;
> + dev->stats.tx_len[i++] += (u32)(val - dev->stats.mib_prev.tx_long_cnt);
> + dev->stats.mib_prev.tx_long_cnt = val;
>
> /* RX */
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_H(port->id));
> - dev->stats.rx_ok_pkts += ((u64)val << 32);
> + dev->stats.rx_ok_pkts = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_PKT_CNT_L(port->id));
> dev->stats.rx_ok_pkts += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_H(port->id));
> - dev->stats.rx_ok_bytes += ((u64)val << 32);
> + dev->stats.rx_ok_bytes = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_OK_BYTE_CNT_L(port->id));
> dev->stats.rx_ok_bytes += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_DROP_CNT(port->id));
> - dev->stats.rx_drops += val;
> + dev->stats.rx_drops += (u32)(val - dev->stats.mib_prev.rx_drops);
> + dev->stats.mib_prev.rx_drops = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_BC_CNT(port->id));
> - dev->stats.rx_broadcast += val;
> + dev->stats.rx_broadcast += (u32)(val - dev->stats.mib_prev.rx_broadcast);
> + dev->stats.mib_prev.rx_broadcast = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_MC_CNT(port->id));
> - dev->stats.rx_multicast += val;
> + dev->stats.rx_multicast += (u32)(val - dev->stats.mib_prev.rx_multicast);
> + dev->stats.mib_prev.rx_multicast = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ERROR_DROP_CNT(port->id));
> - dev->stats.rx_errors += val;
> + dev->stats.rx_errors += (u32)(val - dev->stats.mib_prev.rx_errors);
> + dev->stats.mib_prev.rx_errors = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_CRC_ERR_CNT(port->id));
> - dev->stats.rx_crc_error += val;
> + dev->stats.rx_crc_error += (u32)(val - dev->stats.mib_prev.rx_crc_error);
> + dev->stats.mib_prev.rx_crc_error = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_OVERFLOW_DROP_CNT(port->id));
> - dev->stats.rx_over_errors += val;
> + dev->stats.rx_over_errors += (u32)(val - dev->stats.mib_prev.rx_over_errors);
> + dev->stats.mib_prev.rx_over_errors = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_FRAG_CNT(port->id));
> - dev->stats.rx_fragment += val;
> + dev->stats.rx_fragment += (u32)(val - dev->stats.mib_prev.rx_fragment);
> + dev->stats.mib_prev.rx_fragment = val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_JABBER_CNT(port->id));
> - dev->stats.rx_jabber += val;
> + dev->stats.rx_jabber += (u32)(val - dev->stats.mib_prev.rx_jabber);
> + dev->stats.mib_prev.rx_jabber = val;
>
> i = 0;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
> - dev->stats.rx_len[i] += val;
> + dev->stats.mib_prev.rx_runt_accum64 +=
> + (u32)(val - dev->stats.mib_prev.rx_runt_cnt);
ditto.
> + dev->stats.mib_prev.rx_runt_cnt = val;
> +
> + /* rx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute) → {0, 64} bucket.
> + * then assign rx_len[0] = rx_runt_accum64 + E64_abs.
> + */
>
ditto.
> + dev->stats.rx_len[i] = dev->stats.mib_prev.rx_runt_accum64;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
> - dev->stats.rx_len[i] += ((u64)val << 32);
> + dev->stats.rx_len[i] += (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
> dev->stats.rx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_H(port->id));
> - dev->stats.rx_len[i] += ((u64)val << 32);
> + dev->stats.rx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L64_CNT_L(port->id));
> dev->stats.rx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_H(port->id));
> - dev->stats.rx_len[i] += ((u64)val << 32);
> + dev->stats.rx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L127_CNT_L(port->id));
> dev->stats.rx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_H(port->id));
> - dev->stats.rx_len[i] += ((u64)val << 32);
> + dev->stats.rx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L255_CNT_L(port->id));
> dev->stats.rx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_H(port->id));
> - dev->stats.rx_len[i] += ((u64)val << 32);
> + dev->stats.rx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L511_CNT_L(port->id));
> dev->stats.rx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_H(port->id));
> - dev->stats.rx_len[i] += ((u64)val << 32);
> + dev->stats.rx_len[i] = (u64)val << 32;
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_L1023_CNT_L(port->id));
> dev->stats.rx_len[i++] += val;
>
> val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_LONG_CNT(port->id));
> - dev->stats.rx_len[i++] += val;
> + dev->stats.rx_len[i] += (u32)(val - dev->stats.mib_prev.rx_long_cnt);
> + dev->stats.mib_prev.rx_long_cnt = val;
>
> u64_stats_update_end(&dev->stats.syncp);
> -}
> -
> -static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> -{
> - struct airoha_gdm_port *port = dev->port;
> - int i;
> -
> - spin_lock(&port->stats_lock);
> -
> - for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
> - if (port->devs[i])
> - airoha_dev_get_hw_stats(port->devs[i]);
> - }
> -
> - /* Reset MIB counters */
> - airoha_fe_set(dev->eth, REG_FE_GDM_MIB_CLEAR(port->id),
> - FE_GDM_MIB_RX_CLEAR_MASK | FE_GDM_MIB_TX_CLEAR_MASK);
>
> spin_unlock(&port->stats_lock);
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index f6d01a8e8da1..3af1c49dd62d 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -245,6 +245,33 @@ struct airoha_hw_stats {
> u64 rx_fragment;
> u64 rx_jabber;
> u64 rx_len[7];
> +
> + struct {
> + /* Previous HW register values for 32-bit counter delta
> + * tracking. Storing the last seen value and accumulating
> + * (u32)(curr - prev) into the 64-bit software counter
> + * handles wrap-around transparently via unsigned arithmetic.
> + * tx_runt_accum64/rx_runt_accum64 hold the running sum of
> + * runt deltas. These fields are never reported to userspace.
> + */
> + u32 tx_drops;
> + u32 tx_broadcast;
> + u32 tx_multicast;
> + u32 tx_runt_cnt;
u32 tx_runt;
> + u32 tx_long_cnt;
u32 tx_long;
> + u64 tx_runt_accum64;
64 tx_runt64;
> + u32 rx_drops;
> + u32 rx_broadcast;
> + u32 rx_multicast;
> + u32 rx_errors;
> + u32 rx_crc_error;
> + u32 rx_over_errors;
> + u32 rx_fragment;
> + u32 rx_jabber;
> + u32 rx_runt_cnt;
u32 rx_runt;
> + u32 rx_long_cnt;
u32 rx_long;
> + u64 rx_runt_accum64;
u64 rx_runt64;
> + } mib_prev;
> };
>
> enum {
>
> base-commit: a225f8c20712713406ae47024b8df42deacddd4a
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 18/19] ARM: mark axxia platform as deprecated
From: Ethan Nelson-Moore @ 2026-07-01 22:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Arnd Bergmann, Aaro Koskinen,
Alexander Sverdlin, Alexandre Belloni, Alexandre Torgue,
Andrew Lunn, Ard Biesheuvel, Claudiu Beznea, Daniel Mack,
Frank Li, Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-19-arnd@kernel.org>
Hi, Arnd,
On Wed, Jul 1, 2026 at 2:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
All of these patches have this line at the beginning but were sent
from your kernel.org email - did something go wrong with git
send-email?
> The Axxia platform was initially upstream by Anders Berg for LSI and
> later Avago, but this included only support for I2C and reset drivers,
> while most of the interesting bits (network, pci, rapidio, usb, ...) or
> the arm64 platform support were never merged.
Given the incomplete state of this platform, removing it makes
complete sense to me.
> config ARCH_AXXIA
> - bool "LSI Axxia platforms"
> + bool "LSI Axxia platforms (DEPRECATED)"
> depends on ARCH_MULTI_V7 && ARM_LPAE
The dependency on LPAE reminded me of two other 32-bit ARM platforms
with lots of memory: Calxeda Midway and Highbank. Is anyone still
using those? Maybe they could be removed, since people seem to want to
remove highmem:
https://lwn.net/Articles/813201/
https://static.linaro.org/connect/lvc20/presentations/LVC20-106-0.pdf
> select ARM_AMBA
> select ARM_GIC
> @@ -13,3 +13,5 @@ config ARCH_AXXIA
>
> The LSI Axxia platforms require a Flattened Device Tree to be passed
> to the kernel.
> +
> + This platform is scheduled for removal in early 2027
microscopic nit: missing period
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Ethan
^ permalink raw reply
* Re: [PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
From: Reinette Chatre @ 2026-07-01 22:38 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, rohit.mathew, scott, sdonthineni, tan.shaopeng, xhao,
zengheng4, x86
In-Reply-To: <20260520212458.1797221-6-ben.horgan@arm.com>
Hi Ben,
On 5/20/26 2:24 PM, Ben Horgan wrote:
> Memory bandwidth monitoring make uses of MBWU monitors and is now exposed
> to the user via resctrl. Add some documentation so the user knows what to
> expect.
>
> Co-developed-by: James Morse <james.morse@arm.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Documentation/arch/arm64/mpam.rst | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst
> index 570f51a8d4eb..208ff17068c4 100644
> --- a/Documentation/arch/arm64/mpam.rst
> +++ b/Documentation/arch/arm64/mpam.rst
> @@ -65,6 +65,23 @@ The supported features are:
> there is at least one CSU monitor on each MSC that makes up the L3 group.
> Exposing CSU counters from other caches or devices is not supported.
>
> +* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
> + L3 cache-id to identify where the memory bandwidth is measured. For this
> + reason the platform must have an L3 cache with cache-id's supplied by
> + firmware. (It doesn't need to support MPAM.)
> +
> + Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
> + makes up the L3 group. If the memory bandwidth monitoring is on the memory
> + rather than the L3 then there must be a single global L3 as otherwise it
> + is unknown which L3 the traffic came from.
> +
> + To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
> + match the topology of the L3 cache so that the cache-id's can be
> + repainted. For example: Platforms with Memory bandwidth monitors on
> + CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
> + have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
> + cannot distinguish local traffic from global traffic.
Hopefully we can get to a point where memory bandwidth monitoring data from
CPU-less NUMA nodes can be exposed via resctrl. When considering such possible
future I think it may make this work easier to build on if the documentation
focuses on what the current implementation supports and leave room for
future enhancements by not constraining user space expectation with an absolute
like "CPU-less NUMA nodes cannot expose 'mbm_total_bytes'".
Reinette
^ permalink raw reply
* Re: [PATCH v2 05/19] ARM: turn CONFIG_ATAGS off by default
From: Ethan Nelson-Moore @ 2026-07-01 22:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Arnd Bergmann, Aaro Koskinen,
Alexander Sverdlin, Alexandre Belloni, Alexandre Torgue,
Andrew Lunn, Ard Biesheuvel, Claudiu Beznea, Daniel Mack,
Frank Li, Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon, Linus Walleij
In-Reply-To: <20260701212353.2196041-6-arnd@kernel.org>
Hi, Arnd,
Looks good to me, though I noticed a few small issues.
On Wed, Jul 1, 2026 at 2:24 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> Only a very small number of machines remain that rely on
> traditional board files with the ATAGS boot data instead
> of devicetree, and we have not accepted new ones for
> a decade.
>
> Most of the remaining ones are on their way out of the
> kernel, but the Kconfig option that controls ATAGS
> is still enabled by default.
>
> To reflect the actual status of ATAGS support and alert
> the remaining users of upstream and out-of-tree platforms
> with this, chanyge it to being default-disabled and
nit: change*
> add a dependency on CONFIG_EXPERT.
>
> The board specific defconfig files that rely on ATAGS
> are changed to turn on both EXPERT and ATAGS if they
> were not doing thath already, and the ones that explicitly
nit: that*
> turned it off before no longer need to.
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -20,7 +20,8 @@ CONFIG_ARCH_STM32=y
> CONFIG_CPU_V7M_NUM_IRQ=240
> CONFIG_SET_MEM_PARAM=y
> CONFIG_DRAM_BASE=0x90000000
> -# CONFIG_ATAGS is not set
> +CONFIG_FLASH_MEM_BASE=0x08000000
> +CONFIG_FLASH_SIZE=0x00200000
^ These shouldn't be here - they depend on CPU_ARM740T || CPU_ARM946E
|| CPU_ARM940T, and they were manually removed previously. If they got
added when you did make savedefconfig, I'm not sure why, given that
dependency.
Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> (assuming
these issues are fixed)
Ethan
^ permalink raw reply
* Re: [PATCH v2 17/19] ARM: mark Cortex-M3/M4/M7 based boards as deprecated
From: Vladimir Zapolskiy @ 2026-07-01 22:12 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Will Deacon
In-Reply-To: <20260701212353.2196041-18-arnd@kernel.org>
On 7/2/26 00:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The Cortex-M3/M4/M7 cores were designed as a replacement for the earlier
> ARM7TDMI and ARM9TDMI microarchitectures used in older microcontrollers.
>
> At the moment, Linux can run these cores either when they are integrated
> into a larger SoC, or as standalone microcontrollers. While there was
> a lot of development work going into Cortex-M support from 2011 to 2016,
> this largely stopped when it became clear that Zephyr and other RTOS
> had taken over that market. To date, the only Cortex-M based based
> microcontroller boards supported upstream are reference implementations.
>
> Schedule these for removal after the next LTS kernel, so if any users
> remain that want to update their kernels, they can stay on that
> version for a few years before having to maintain the platform support
> out of tree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/Kconfig | 8 ++++++--
> arch/arm/mach-at91/Kconfig | 4 +++-
> arch/arm/mach-imx/Kconfig | 4 +++-
> arch/arm/mach-stm32/Kconfig | 14 ++++++++------
> 4 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e2bdf2591c10..5adccaed7d01 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -471,7 +471,7 @@ source "arch/arm/mach-zynq/Kconfig"
>
> # ARMv7-M architecture
> config ARCH_LPC18XX
> - bool "NXP LPC18xx/LPC43xx"
> + bool "NXP LPC18xx/LPC43xx (DEPRECATED)"
> depends on ARM_SINGLE_ARMV7M
> select ARCH_HAS_RESET_CONTROLLER
> select ARM_AMBA
> @@ -481,8 +481,10 @@ config ARCH_LPC18XX
> Support for NXP's LPC18xx Cortex-M3 and LPC43xx Cortex-M4
> high performance microcontrollers.
>
> + This platform is scheduled for removal in early 2027
> +
Acked-by: Vladimir Zapolskiy <vz@mleia.com> # NXP LPC18xx/LPC43xx
> config ARCH_MPS2
> - bool "ARM MPS2 platform"
> + bool "ARM MPS2 platform (DEPRECATED)"
> depends on ARM_SINGLE_ARMV7M
> select ARM_AMBA
> select CLKSRC_MPS2
> @@ -493,6 +495,8 @@ config ARCH_MPS2
> Please, note that depends which Application Note is used memory map
> for the platform may vary, so adjustment of RAM base might be needed.
>
> + This platform is scheduled for removal in early 2027
> +
> # Definitions to make life easier
> config ARCH_ACORN
> bool
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index c5ef27e3cd8f..cb0e3ff8e0ca 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -15,13 +15,15 @@ menuconfig ARCH_AT91
>
> if ARCH_AT91
> config SOC_SAMV7
> - bool "SAM Cortex-M7 family" if ARM_SINGLE_ARMV7M
> + bool "SAM Cortex-M7 family (DEPRECATED)" if ARM_SINGLE_ARMV7M
> select COMMON_CLK_AT91
> select PINCTRL_AT91
> help
> Select this if you are using an SoC from Microchip's SAME7, SAMS7 or SAMV7
> families.
>
> + This platform is scheduled for removal in early 2027
> +
> config SOC_SAMA5D2
> bool "SAMA5D2 family"
> depends on ARCH_MULTI_V7
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index f85a5f8c0a58..3f0521c652cb 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -219,12 +219,14 @@ config SOC_IMX7ULP
> This enables support for Freescale i.MX7 Ultra Low Power processor.
>
> config SOC_IMXRT
> - bool "i.MXRT support"
> + bool "i.MXRT support (DEPRECATED)"
> depends on ARM_SINGLE_ARMV7M
> select ARMV7M_SYSTICK if ARM_SINGLE_ARMV7M
> help
> This enables support for Freescale i.MXRT Crossover processor.
>
> + This platform is scheduled for removal in early 2027
> +
> config SOC_VF610
> bool "Vybrid Family VF610 support"
> select ARM_GIC if ARCH_MULTI_V7
> diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
> index 630b992f32b1..4ac3384e397a 100644
> --- a/arch/arm/mach-stm32/Kconfig
> +++ b/arch/arm/mach-stm32/Kconfig
> @@ -14,30 +14,32 @@ menuconfig ARCH_STM32
> select STM32_EXTI if ARM_SINGLE_ARMV7M
> select STM32_FIREWALL
> help
> - Support for STMicroelectronics STM32 processors.
> + Support for STMicroelectronics STM32MP1 processors using Cortex-A7
> + cores. Note that support for the earlier Cortex-M based variants
> + is deprecated and scheduled for removal in early 2027.
>
> if ARCH_STM32
>
> if ARM_SINGLE_ARMV7M
>
> config MACH_STM32F429
> - bool "STMicroelectronics STM32F429"
> + bool "STMicroelectronics STM32F429 (DEPRECATED)"
> default y
>
> config MACH_STM32F469
> - bool "STMicroelectronics STM32F469"
> + bool "STMicroelectronics STM32F469 (DEPRECATED)"
> default y
>
> config MACH_STM32F746
> - bool "STMicroelectronics STM32F746"
> + bool "STMicroelectronics STM32F746 (DEPRECATED)"
> default y
>
> config MACH_STM32F769
> - bool "STMicroelectronics STM32F769"
> + bool "STMicroelectronics STM32F769 (DEPRECATED)"
> default y
>
> config MACH_STM32H743
> - bool "STMicroelectronics STM32H743"
> + bool "STMicroelectronics STM32H743 (DEPRECATED)"
> default y
>
> endif # ARMv7-M
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 04/19] ARM: deprecate support for ARM1136r0
From: Vladimir Zapolskiy @ 2026-07-01 22:11 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Will Deacon, Linus Walleij
In-Reply-To: <20260701212353.2196041-5-arnd@kernel.org>
On 7/2/26 00:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This CPU revision remains a special case as it is now incompatible
> with CONFIG_SMP. Only the Nokia N8x0 is used in practice, and even
> that one is fairly rare these days, so let's plan to remove all of
> them after the 2026 LTS kernel release.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-imx/Kconfig | 5 ++++-
> arch/arm/mach-omap2/Kconfig | 15 ++++++++++++---
> arch/arm/mach-versatile/Kconfig | 5 ++++-
> arch/arm/mm/Kconfig | 2 ++
> 4 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 041e73ad203a..f85a5f8c0a58 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -40,13 +40,16 @@ if ARCH_MULTI_V6
> comment "ARM1136 platforms"
>
> config SOC_IMX31
> - bool "i.MX31 support"
> + bool "i.MX31 support (DEPRECATED)"
> depends on !SMP
> select CPU_ARM1136R0
> select MXC_AVIC
> help
> This enables support for Freescale i.MX31 processor
>
> + This SoC is scheduled for removal in early 2027,
> + since it uses the ARM1136r0 CPU revision.
> +
Acked-by: Vladimir Zapolskiy <vz@mleia.com> # Freescale i.MX31
It's a nice SoC, long time ago its watchdog driver was broken in upstream
and never got fixed unfortunately...
> config SOC_IMX35
> bool "i.MX35 support"
> select CPU_ARM1136R1
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 13987ffbba00..79f8afe3a6bf 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -207,18 +207,24 @@ comment "OMAP Core Type"
> depends on ARCH_OMAP2
>
> config SOC_OMAP2420
> - bool "OMAP2420 support"
> + bool "OMAP2420 support (DEPRECATED)"
> depends on ARCH_OMAP2
> default y
> select OMAP_DM_SYSTIMER
> select OMAP_DM_TIMER
> select SOC_HAS_OMAP2_SDRC
> + help
> + This SoC is scheduled for removal in early 2027,
> + since it uses the ARM1136r0 CPU revision.
>
> config SOC_OMAP2430
> - bool "OMAP2430 support"
> + bool "OMAP2430 support (DEPRECATED)"
> depends on ARCH_OMAP2
> default y
> select SOC_HAS_OMAP2_SDRC
> + help
> + This SoC is scheduled for removal in early 2027,
> + since it uses the ARM1136r0 CPU revision.
>
> config SOC_OMAP3430
> bool "OMAP3430 support"
> @@ -249,11 +255,14 @@ config MACH_NOKIA_N810_WIMAX
> bool
>
> config MACH_NOKIA_N8X0
> - bool "Nokia N800/N810"
> + bool "Nokia N800/N810 (DEPRECATED)"
> depends on SOC_OMAP2420
> default y
> select MACH_NOKIA_N810
> select MACH_NOKIA_N810_WIMAX
> + help
> + This machine is scheduled for removal in early 2027,
> + since it uses the ARM1136r0 CPU revision.
>
> endmenu
>
> diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
> index de42da7de8c8..1ee9b6608d71 100644
> --- a/arch/arm/mach-versatile/Kconfig
> +++ b/arch/arm/mach-versatile/Kconfig
> @@ -110,11 +110,14 @@ config INTEGRATOR_CM1026EJS
> select CPU_ARM1026
>
> config INTEGRATOR_CM1136JFS
> - bool "Integrator/CM1136JF-S core module"
> + bool "Integrator/CM1136JF-S core module (DEPRECATED)"
> depends on ARCH_INTEGRATOR_AP
> depends on ARCH_MULTI_V6
> depends on !SMP
> select CPU_ARM1136R0
> + help
> + This machine is scheduled for removal in early 2027,
> + since it uses the ARM1136r0 CPU revision.
>
> config ARCH_INTEGRATOR_CP
> bool "Support Integrator/CP platform"
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index f3d71e89a31f..27010b9389ad 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -410,6 +410,8 @@ config CPU_ARM1136R0
> help
> These early revisions of ARM1136 lack support for the
> ARMv6k extensions for multiprocessing.
> + Support for this revision is scheduled for removal
> + from the kernel in early 2027.
>
> config CPU_ARM1136R1
> bool
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 06/19] ARM: mark CPU_ENDIAN_BE8 as deprecated
From: Ethan Nelson-Moore @ 2026-07-01 21:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Arnd Bergmann, Aaro Koskinen,
Alexander Sverdlin, Alexandre Belloni, Alexandre Torgue,
Andrew Lunn, Ard Biesheuvel, Claudiu Beznea, Daniel Mack,
Frank Li, Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-7-arnd@kernel.org>
Hi, Arnd,
On Wed, Jul 1, 2026 at 2:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
> Following the deprecation of big-endian ARMv8 mode in arch/arm64 in commit
> 1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN"),
> this does the same for ARMv7 (and v6), leaving the code around but
> disabled by default: There are no known products that make use of this
> mode any more, and it only hangs around for testing that it still works.
Nice! Getting rid of ARM big-endian support is long overdue in my
opinion. The patch looks good to me, although see below for a couple
minor questions.
> At the moment, there are no known bugs with big-endian ARMv7 mode, but
> it does break occasionally and require someone to fix it. By marking
> the code as 'depends on BROKEN' now, it will no longer be covered by CI
> testing. If any users remain, they can keep patching out the dependency
> but are more likely to run into regressions.
>
> The big-endian ARMv5 support (CONFIG_CPU_ENDIAN_BE32) in contrast is
> still used on Intel IXP4xx platform, and is the only currently supported
> mode there, so this one can still be enabled.
If IXP4xx is the only known remaining user, would it make sense for
CPU_BIG_ENDIAN to instead depend on ARCH_IXP4XX || BROKEN? Is BE32
mode known to work correctly on any other platforms?
Ethan
^ permalink raw reply
* Re: [PATCH] mfd: stm32-timers: depopulate child devices on populate failure
From: Lee Jones @ 2026-07-01 21:42 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Fabrice Gasnier, Maxime Coquelin, Alexandre Torgue, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260615063042.36397-1-pengpeng@iscas.ac.cn>
On Mon, 15 Jun 2026, Pengpeng Hou wrote:
> stm32_timers_probe() releases the timer DMA resources when
> of_platform_populate() fails, but it does not depopulate any child
> devices that were created before the failure.
>
> The remove path explicitly depopulates child devices before releasing
> DMA resources to avoid races with children using DMA. Apply the same
> ordering on the populate failure path.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/mfd/stm32-timers.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
> index b3dbc02aaf79..1f0aecae83a5 100644
> --- a/drivers/mfd/stm32-timers.c
> +++ b/drivers/mfd/stm32-timers.c
> @@ -329,8 +329,10 @@ static int stm32_timers_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, ddata);
>
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> - if (ret)
> + if (ret) {
> + of_platform_depopulate(&pdev->dev);
It's strange to see an un-winder inside the error handling of its
original call. We're used to seeing them called only on success during
a subsequent step.
Wouldn't devm_of_platform_populate() be better here instead?
> stm32_timers_dma_remove(dev, ddata);
> + }
>
> return ret;
> }
> --
> 2.50.1 (Apple Git-155)
>
--
Lee Jones
^ permalink raw reply
* [PATCH v2 19/19] ARM: mark mv78xx0 support as deprecated
From: Arnd Bergmann @ 2026-07-01 21:23 UTC (permalink / raw)
To: linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Only one machine remains supported and was kept in 2022 for the
Debian_on_Buffalo project that was still using this, with plans to
convert it to devicetree.
The conversion never happened, and Debian_on_Buffalo does not provide
kernels later than linux-6.1, so it is unlikely to still be useful
for a DT conversion in the future.
Mark the platform for deprecation after the next LTS kernel, which
should give any remaining users a few more years of bugfixes.
Link: https://lore.kernel.org/all/20221019150410.3851944-6-arnd@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-mv78xx0/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mv78xx0/Kconfig b/arch/arm/mach-mv78xx0/Kconfig
index 670e6587827e..98b35f5d05ba 100644
--- a/arch/arm/mach-mv78xx0/Kconfig
+++ b/arch/arm/mach-mv78xx0/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
menuconfig ARCH_MV78XX0
- bool "Marvell MV78xx0"
+ bool "Marvell MV78xx0 (DEPRECATED)"
depends on ARCH_MULTI_V5
depends on CPU_LITTLE_ENDIAN
depends on ATAGS
@@ -14,6 +14,8 @@ menuconfig ARCH_MV78XX0
Support for the following Marvell MV78xx0 series SoCs:
MV781x0, MV782x0.
+ This platform is scheduled for removal in early 2027.
+
if ARCH_MV78XX0
config MACH_TERASTATION_WXL
--
2.39.5
^ permalink raw reply related
* [PATCH v2 18/19] ARM: mark axxia platform as deprecated
From: Arnd Bergmann @ 2026-07-01 21:23 UTC (permalink / raw)
To: linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The Axxia platform was initially upstream by Anders Berg for LSI and
later Avago, but this included only support for I2C and reset drivers,
while most of the interesting bits (network, pci, rapidio, usb, ...) or
the arm64 platform support were never merged.
The downstream kernel was maintained by Intel up to linux-5.15 when
the product line was discontinued. Known users include Nokia and
Ericsson, but both of them use kernels derived from the out-of-tree
drivers rather than the upstream version, and will be able to continue
doing that even when the rudimentary mainline support is gone.
Mark it as deprecated for removal after the next LTS kernel.
Link: https://github.com/axxia/linux-yocto
Cc: Stefan Wiehler <stefan.wiehler@nokia.com>
Cc: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-axxia/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-axxia/Kconfig b/arch/arm/mach-axxia/Kconfig
index d3eae6037913..f773a66c1402 100644
--- a/arch/arm/mach-axxia/Kconfig
+++ b/arch/arm/mach-axxia/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
config ARCH_AXXIA
- bool "LSI Axxia platforms"
+ bool "LSI Axxia platforms (DEPRECATED)"
depends on ARCH_MULTI_V7 && ARM_LPAE
select ARM_AMBA
select ARM_GIC
@@ -13,3 +13,5 @@ config ARCH_AXXIA
The LSI Axxia platforms require a Flattened Device Tree to be passed
to the kernel.
+
+ This platform is scheduled for removal in early 2027
--
2.39.5
^ permalink raw reply related
* [PATCH v2 17/19] ARM: mark Cortex-M3/M4/M7 based boards as deprecated
From: Arnd Bergmann @ 2026-07-01 21:23 UTC (permalink / raw)
To: linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The Cortex-M3/M4/M7 cores were designed as a replacement for the earlier
ARM7TDMI and ARM9TDMI microarchitectures used in older microcontrollers.
At the moment, Linux can run these cores either when they are integrated
into a larger SoC, or as standalone microcontrollers. While there was
a lot of development work going into Cortex-M support from 2011 to 2016,
this largely stopped when it became clear that Zephyr and other RTOS
had taken over that market. To date, the only Cortex-M based based
microcontroller boards supported upstream are reference implementations.
Schedule these for removal after the next LTS kernel, so if any users
remain that want to update their kernels, they can stay on that
version for a few years before having to maintain the platform support
out of tree.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Kconfig | 8 ++++++--
arch/arm/mach-at91/Kconfig | 4 +++-
arch/arm/mach-imx/Kconfig | 4 +++-
arch/arm/mach-stm32/Kconfig | 14 ++++++++------
4 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e2bdf2591c10..5adccaed7d01 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -471,7 +471,7 @@ source "arch/arm/mach-zynq/Kconfig"
# ARMv7-M architecture
config ARCH_LPC18XX
- bool "NXP LPC18xx/LPC43xx"
+ bool "NXP LPC18xx/LPC43xx (DEPRECATED)"
depends on ARM_SINGLE_ARMV7M
select ARCH_HAS_RESET_CONTROLLER
select ARM_AMBA
@@ -481,8 +481,10 @@ config ARCH_LPC18XX
Support for NXP's LPC18xx Cortex-M3 and LPC43xx Cortex-M4
high performance microcontrollers.
+ This platform is scheduled for removal in early 2027
+
config ARCH_MPS2
- bool "ARM MPS2 platform"
+ bool "ARM MPS2 platform (DEPRECATED)"
depends on ARM_SINGLE_ARMV7M
select ARM_AMBA
select CLKSRC_MPS2
@@ -493,6 +495,8 @@ config ARCH_MPS2
Please, note that depends which Application Note is used memory map
for the platform may vary, so adjustment of RAM base might be needed.
+ This platform is scheduled for removal in early 2027
+
# Definitions to make life easier
config ARCH_ACORN
bool
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index c5ef27e3cd8f..cb0e3ff8e0ca 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -15,13 +15,15 @@ menuconfig ARCH_AT91
if ARCH_AT91
config SOC_SAMV7
- bool "SAM Cortex-M7 family" if ARM_SINGLE_ARMV7M
+ bool "SAM Cortex-M7 family (DEPRECATED)" if ARM_SINGLE_ARMV7M
select COMMON_CLK_AT91
select PINCTRL_AT91
help
Select this if you are using an SoC from Microchip's SAME7, SAMS7 or SAMV7
families.
+ This platform is scheduled for removal in early 2027
+
config SOC_SAMA5D2
bool "SAMA5D2 family"
depends on ARCH_MULTI_V7
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index f85a5f8c0a58..3f0521c652cb 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -219,12 +219,14 @@ config SOC_IMX7ULP
This enables support for Freescale i.MX7 Ultra Low Power processor.
config SOC_IMXRT
- bool "i.MXRT support"
+ bool "i.MXRT support (DEPRECATED)"
depends on ARM_SINGLE_ARMV7M
select ARMV7M_SYSTICK if ARM_SINGLE_ARMV7M
help
This enables support for Freescale i.MXRT Crossover processor.
+ This platform is scheduled for removal in early 2027
+
config SOC_VF610
bool "Vybrid Family VF610 support"
select ARM_GIC if ARCH_MULTI_V7
diff --git a/arch/arm/mach-stm32/Kconfig b/arch/arm/mach-stm32/Kconfig
index 630b992f32b1..4ac3384e397a 100644
--- a/arch/arm/mach-stm32/Kconfig
+++ b/arch/arm/mach-stm32/Kconfig
@@ -14,30 +14,32 @@ menuconfig ARCH_STM32
select STM32_EXTI if ARM_SINGLE_ARMV7M
select STM32_FIREWALL
help
- Support for STMicroelectronics STM32 processors.
+ Support for STMicroelectronics STM32MP1 processors using Cortex-A7
+ cores. Note that support for the earlier Cortex-M based variants
+ is deprecated and scheduled for removal in early 2027.
if ARCH_STM32
if ARM_SINGLE_ARMV7M
config MACH_STM32F429
- bool "STMicroelectronics STM32F429"
+ bool "STMicroelectronics STM32F429 (DEPRECATED)"
default y
config MACH_STM32F469
- bool "STMicroelectronics STM32F469"
+ bool "STMicroelectronics STM32F469 (DEPRECATED)"
default y
config MACH_STM32F746
- bool "STMicroelectronics STM32F746"
+ bool "STMicroelectronics STM32F746 (DEPRECATED)"
default y
config MACH_STM32F769
- bool "STMicroelectronics STM32F769"
+ bool "STMicroelectronics STM32F769 (DEPRECATED)"
default y
config MACH_STM32H743
- bool "STMicroelectronics STM32H743"
+ bool "STMicroelectronics STM32H743 (DEPRECATED)"
default y
endif # ARMv7-M
--
2.39.5
^ permalink raw reply related
* [PATCH v2 16/19] ARM: mark footbridge as deprecated
From: Arnd Bergmann @ 2026-07-01 21:23 UTC (permalink / raw)
To: linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon, Linus Walleij
In-Reply-To: <20260701212353.2196041-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Along with RiscPC and SA1100, these are the last remaining Intel StrongARM
machines. The Corel NetWinder used to be particular popular in the late
1990s, but was discontinued during the bankruptcy of rebel.com in 2001.
The other machine is the DEC (later Intel) EBSA285 evaluation board that
was made in small numbers in 1997 for software developers.
The footbridge/netwinder platform was the main target for the first Debian
2.0 "Hamm" release on the Arm architecture back in 1998, but was dropped
in Debian 6.0 "Squeeze" in 2011, which only supported ARMv4T and higher
with the EABI based ports as ARMv4 hardware had fallen already out of
use by that time.
Link: http://netwinder.org/
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Ralph Siemsen <ralph.siemsen@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
| 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig
index 78189997caa1..96a74d447028 100644
--- a/arch/arm/mach-footbridge/Kconfig
+++ b/arch/arm/mach-footbridge/Kconfig
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
menuconfig ARCH_FOOTBRIDGE
- bool "FootBridge Implementations"
+ bool "FootBridge Implementations (DEPRECATED)"
depends on ARCH_MULTI_V4 && !(ARCH_MULTI_V4T || ARCH_MULTI_V5)
depends on !(ARCH_MOXART || ARCH_GEMINI || ARCH_SA1100)
depends on ATAGS
@@ -12,7 +12,10 @@ menuconfig ARCH_FOOTBRIDGE
select NEED_MACH_MEMORY_H
help
Support for systems based on the DC21285 companion chip
- ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
+ ("FootBridge"), used in the EBSA285 and the Rebel NetWinder.
+
+ Support for these machines will go away in 2027,
+ unless there are any remaining users that speak up.
if ARCH_FOOTBRIDGE
--
2.39.5
^ permalink raw reply related
* [PATCH v2 15/19] ARM: mark RiscPC as deprecated
From: Arnd Bergmann @ 2026-07-01 21:23 UTC (permalink / raw)
To: linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
This platform is the oldest still supported machine, dating back
to the original 1994 ARM610 version. The only currently supported
configuration uses an ARMv4 StrongARM but still requires building
for ARMv3 because of the board design not supporting 16-bit
data access.
ARMv3 support has been removed in gcc-9, and the gcc-8 release
is already old but still supported for building the kernel.
The only set of machines that lacks support for 16-bit load/store
instructions (Alpha EV5 and older) was recently removed from
the kernel.
Since there is little hope of this being maintainable much
longer, plan to remove it in early 2027 while it is still expected
to mostly work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-rpc/Kconfig | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rpc/Kconfig b/arch/arm/mach-rpc/Kconfig
index 55f6d829b677..60b3823b690c 100644
--- a/arch/arm/mach-rpc/Kconfig
+++ b/arch/arm/mach-rpc/Kconfig
@@ -1,5 +1,5 @@
config ARCH_RPC
- bool "RiscPC"
+ bool "RiscPC (DEPRECATED)"
depends on ARCH_MULTI_V4 && !(ARCH_MULTI_V4T || ARCH_MULTI_V5)
depends on !(ARCH_FOOTBRIDGE || ARCH_SA1100 || ARCH_MOXART || ARCH_GEMINI)
depends on !CC_IS_CLANG && GCC_VERSION < 90100 && GCC_VERSION >= 60000
@@ -19,3 +19,6 @@ config ARCH_RPC
help
On the Acorn Risc-PC, Linux can support the internal IDE disk and
CD-ROM interface, serial and parallel port, and the floppy drive.
+
+ Support for these machines will go away in 2027,
+ unless there are any remaining users that speak up.
--
2.39.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox