* [PATCH v3 2/6] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
Any changes to the PHY link rate and/or color depth done via the HDMI
PHY configuration API are not immediately programmed into the hardware,
but are delayed until the PHY usage count gets incremented from 0 to 1,
that is when it is powered on or when the PLL clock exposed through
the CCF API is prepared, whichever comes first.
Since the clock might remain in prepared state after subsequent PHY
config changes, the programming can also be triggered via
clk_ops.set_rate(). However, from the clock consumer perspective (i.e.
VOP2 display controller), the (pixel) clock rate doesn't vary with bpc,
as that is handled internally by the PHY and reflected in the TDMS
character rate only.
As a consequence, changing the bpc while preserving the modeline may
lead to out-of-sync issues between CCF and HDMI PHY config state,
because the .set_rate() callback is not invoked when clock rate remains
constant. This may also happen when the PHY PLL has been pre-programmed
by an external entity, e.g. the bootloader, which is actually a
regression introduced by the recent FRL patches.
Introduce a pll_config_dirty flag to keep track of uncommitted PHY
config changes and use it in clk_ops.determine_rate() to invalidate the
current clock rate (as known by CCF) and, consequently, ensure those
changes are programmed into hardware via clk_ops.set_rate().
Moreover, proceed with a similar fix in phy_ops.power_on() callback, to
handle the scenario where the CCF API is not used due to operating in
FRL mode, while the clock is still in a prepared state and thus
preventing rk_hdptx_phy_consumer_get() to apply the updated PHY
configuration.
Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management")
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 84 +++++++++++++----------
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 710603afff86..5295d5f6f287 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -413,6 +413,7 @@ struct rk_hdptx_phy {
/* clk provider */
struct clk_hw hw;
+ bool pll_config_dirty;
bool restrict_rate_change;
atomic_t usage_count;
@@ -1260,13 +1261,19 @@ static int rk_hdptx_tmds_ropll_cmn_config(struct rk_hdptx_phy *hdptx)
static int rk_hdptx_pll_cmn_config(struct rk_hdptx_phy *hdptx)
{
+ int ret;
+
if (hdptx->hdmi_cfg.rate <= HDMI20_MAX_RATE)
- return rk_hdptx_tmds_ropll_cmn_config(hdptx);
+ ret = rk_hdptx_tmds_ropll_cmn_config(hdptx);
+ else if (hdptx->hdmi_cfg.rate == FRL_8G4L_RATE)
+ ret = rk_hdptx_frl_lcpll_ropll_cmn_config(hdptx);
+ else
+ ret = rk_hdptx_frl_lcpll_cmn_config(hdptx);
- if (hdptx->hdmi_cfg.rate == FRL_8G4L_RATE)
- return rk_hdptx_frl_lcpll_ropll_cmn_config(hdptx);
+ if (!ret)
+ hdptx->pll_config_dirty = false;
- return rk_hdptx_frl_lcpll_cmn_config(hdptx);
+ return ret;
}
static int rk_hdptx_frl_lcpll_mode_config(struct rk_hdptx_phy *hdptx)
@@ -1347,25 +1354,22 @@ static int rk_hdptx_phy_consumer_get(struct rk_hdptx_phy *hdptx)
return 0;
ret = regmap_read(hdptx->grf, GRF_HDPTX_STATUS, &status);
- if (ret)
- goto dec_usage;
-
- if (status & HDPTX_O_PLL_LOCK_DONE)
- dev_warn(hdptx->dev, "PLL locked by unknown consumer!\n");
+ if (ret) {
+ atomic_dec(&hdptx->usage_count);
+ return ret;
+ }
if (mode == PHY_MODE_DP) {
rk_hdptx_dp_reset(hdptx);
} else {
- ret = rk_hdptx_pll_cmn_config(hdptx);
- if (ret)
- goto dec_usage;
+ /*
+ * Ignore PLL config errors at this point as pll_config_dirty
+ * was not reset and, therefore, operation will be retried.
+ */
+ rk_hdptx_pll_cmn_config(hdptx);
}
return 0;
-
-dec_usage:
- atomic_dec(&hdptx->usage_count);
- return ret;
}
static int rk_hdptx_phy_consumer_put(struct rk_hdptx_phy *hdptx, bool force)
@@ -1700,13 +1704,18 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
if (ret)
rk_hdptx_phy_consumer_put(hdptx, true);
} else {
- regmap_write(hdptx->grf, GRF_HDPTX_CON0,
- HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
+ if (hdptx->pll_config_dirty)
+ ret = rk_hdptx_pll_cmn_config(hdptx);
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
- ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
- else
- ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
+ if (!ret) {
+ regmap_write(hdptx->grf, GRF_HDPTX_CON0,
+ HDPTX_MODE_SEL << 16 | FIELD_PREP(HDPTX_MODE_SEL, 0x0));
+
+ if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
+ ret = rk_hdptx_frl_lcpll_mode_config(hdptx);
+ else
+ ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
+ }
if (ret)
rk_hdptx_phy_consumer_put(hdptx, true);
@@ -2081,7 +2090,10 @@ static int rk_hdptx_phy_configure(struct phy *phy, union phy_configure_opts *opt
dev_err(hdptx->dev, "invalid hdmi params for phy configure\n");
} else {
hdptx->restrict_rate_change = true;
- dev_dbg(hdptx->dev, "%s rate=%llu bpc=%u\n", __func__,
+ hdptx->pll_config_dirty = true;
+
+ dev_dbg(hdptx->dev, "%s %s rate=%llu bpc=%u\n", __func__,
+ hdptx->hdmi_cfg.mode ? "FRL" : "TMDS",
hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
}
@@ -2303,8 +2315,19 @@ static int rk_hdptx_phy_clk_determine_rate(struct clk_hw *hw,
{
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
- return hdptx->hdmi_cfg.rate;
+ /*
+ * Invalidate current clock rate to ensure rk_hdptx_phy_clk_set_rate()
+ * will be invoked to commit PLL configuration.
+ */
+ if (hdptx->pll_config_dirty) {
+ req->rate = 0;
+ return 0;
+ }
+
+ if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL) {
+ req->rate = hdptx->hdmi_cfg.rate;
+ return 0;
+ }
/*
* FIXME: Temporarily allow altering TMDS char rate via CCF.
@@ -2336,17 +2359,6 @@ static int rk_hdptx_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
- unsigned long long link_rate = rate;
-
- if (hdptx->hdmi_cfg.mode != PHY_HDMI_MODE_FRL)
- link_rate = DIV_ROUND_CLOSEST_ULL(rate * hdptx->hdmi_cfg.bpc, 8);
-
- /* Revert any unlikely link rate change since determine_rate() */
- if (hdptx->hdmi_cfg.rate != link_rate) {
- dev_warn(hdptx->dev, "Reverting unexpected rate change from %llu to %llu\n",
- link_rate, hdptx->hdmi_cfg.rate);
- hdptx->hdmi_cfg.rate = link_rate;
- }
/*
* The link rate would be normally programmed in HW during
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/6] phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com>
The PHY PLL can be programmed by an external component, e.g. the
bootloader, just before the recalc_rate() callback is invoked during
devm_clk_hw_register() in the probe path.
Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and
attempts to compute the clock rate, while making use of the bpc value
from the HDMI PHY configuration, which always defaults to 8 because
phy_configure() was not run at that point. As a consequence, the
(re)calculated rate is incorrect when the actual bpc was higher than 8.
Do not rely on any of the hdmi_cfg members when computing the clock rate
and, instead, read the required input data (i.e. bpc), directly from the
hardware registers.
Fixes: 3481fc04d969 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
Tested-by: Thomas Niederprüm <dubito@online.de>
Tested-by: Simon Wright <simon@symple.nz>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
index 2d973bc37f07..710603afff86 100644
--- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
+++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
@@ -2168,7 +2168,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
struct lcpll_config lcpll_hw;
struct ropll_config ropll_hw;
u64 fout, sdm;
- u32 mode, val;
+ u32 mode, bpc, val;
int ret, i;
ret = regmap_read(hdptx->regmap, CMN_REG(0008), &mode);
@@ -2266,6 +2266,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
if (ret)
return 0;
ropll_hw.pms_sdiv = ((val & PLL_PCG_POSTDIV_SEL_MASK) >> 4) + 1;
+ bpc = (FIELD_GET(PLL_PCG_CLK_SEL_MASK, val) << 1) + 8;
fout = PLL_REF_CLK * ropll_hw.pms_mdiv;
if (ropll_hw.sdm_en) {
@@ -2280,7 +2281,7 @@ static u64 rk_hdptx_phy_clk_calc_rate_from_pll_cfg(struct rk_hdptx_phy *hdptx)
fout = fout + sdm;
}
- return div_u64(fout * 2, ropll_hw.pms_sdiv * 10);
+ return DIV_ROUND_CLOSEST_ULL(fout * 2 * 8, ropll_hw.pms_sdiv * 10 * bpc);
}
static unsigned long rk_hdptx_phy_clk_recalc_rate(struct clk_hw *hw,
@@ -2288,19 +2289,13 @@ static unsigned long rk_hdptx_phy_clk_recalc_rate(struct clk_hw *hw,
{
struct rk_hdptx_phy *hdptx = to_rk_hdptx_phy(hw);
u32 status;
- u64 rate;
int ret;
ret = regmap_read(hdptx->grf, GRF_HDPTX_CON0, &status);
if (ret || !(status & HDPTX_I_PLL_EN))
return 0;
- rate = rk_hdptx_phy_clk_calc_rate_from_pll_cfg(hdptx);
-
- if (hdptx->hdmi_cfg.mode == PHY_HDMI_MODE_FRL)
- return rate;
-
- return DIV_ROUND_CLOSEST_ULL(rate * 8, hdptx->hdmi_cfg.bpc);
+ return rk_hdptx_phy_clk_calc_rate_from_pll_cfg(hdptx);
}
static int rk_hdptx_phy_clk_determine_rate(struct clk_hw *hw,
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Cristian Ciocaltea @ 2026-06-11 12:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
This series provides a set of bug fixes and cleanups for the Rockchip
Samsung HDPTX PHY driver.
The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
calculation and synchronization issues. Specifically, it fixes edge
cases where the PHY PLL is pre-programmed by an external component (like
a bootloader) or when changing the color depth (bpc) while keeping the
modeline constant. Because the Common Clock Framework .set_rate()
callback might not be invoked if the pixel clock remains unchanged, this
previously led to out-of-sync states between CCF and the actual HDMI PHY
configuration.
The second part focuses on code cleanups and modernizing the register
access. Now that dw_hdmi_qp driver has fully switched to using
phy_configure(), we can drop the deprecated TMDS rate setup workarounds
and the restrict_rate_change flag logic. Finally, it refactors the
driver to consistently use standard bitfield macros.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Changes in v3:
- Replaced div_u64() with DIV_ROUND_CLOSEST_ULL() in Patch 1 (Sashiko)
- Fixed theoretical usage_count unbalanced issue in Patch 2 (Sashiko)
- Rebased series onto latest phy/next
- Link to v2: https://patch.msgid.link/20260511-hdptx-clk-fixes-v2-0-664e41379cab@collabora.com
Changes in v2:
- Collected Tested-by tags from Thomas and Simon
- Fixed a typo in commit description of patch 1
- Added a comment in patch 2 explaining why PLL config errors are
ignored for rk_hdptx_phy_consumer_get()
- Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
- Rebased onto latest phy/fixes
- Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
---
Cristian Ciocaltea (6):
phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling
phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()
phy: rockchip: samsung-hdptx: Consistently use bitfield macros
drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 216 ++++++++++------------
1 file changed, 95 insertions(+), 121 deletions(-)
---
base-commit: 293e19f416fa3f233a2fb013258f7abcb39ad6ed
change-id: 20260227-hdptx-clk-fixes-47426632f862
^ permalink raw reply
* Re: [PATCH v2 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Jian Hu @ 2026-06-11 12:24 UTC (permalink / raw)
To: Jerome Brunet
Cc: Jian Hu via B4 Relay, Neil Armstrong, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl, linux-amlogic,
linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1jpl1yfunu.fsf@starbuckisacylon.baylibre.com>
On 6/10/2026 8:26 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On mer. 10 juin 2026 at 12:18, Jian Hu <jian.hu@amlogic.com> wrote:
>
>> Hi Jerome,
>>
>> Thanks for your review
>>
>> On 6/3/2026 10:29 PM, Jerome Brunet wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Wed 03 Jun 2026 at 20:17, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>>>
>>>> From: Jian Hu <jian.hu@amlogic.com>
>>>>
>>>> Add the Always-on clock controller driver for the Amlogic A9 SoC family.
>>>>
>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>>> ---
>>>> drivers/clk/meson/Kconfig | 13 ++
>>>> drivers/clk/meson/Makefile | 1 +
>>>> drivers/clk/meson/a9-aoclk.c | 419 +++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 433 insertions(+)
>>>>
>>>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>>>> index cf8cf3f9e4ee..625e6788b940 100644
>>>> --- a/drivers/clk/meson/Kconfig
>>>> +++ b/drivers/clk/meson/Kconfig
>>>> @@ -132,6 +132,19 @@ config COMMON_CLK_A1_PERIPHERALS
>>>> device, A1 SoC Family. Say Y if you want A1 Peripherals clock
>>>> controller to work.
>>>>
>>>> +config COMMON_CLK_A9_AO
>>>> + tristate "Amlogic A9 SoC AO clock controller support"
>>>> + depends on ARM64
>>>> + default ARCH_MESON || COMPILE_TEST
>>>> + select COMMON_CLK_MESON_REGMAP
>>>> + select COMMON_CLK_MESON_CLKC_UTILS
>>>> + select COMMON_CLK_MESON_DUALDIV
>>>> + imply COMMON_CLK_SCMI
>>>> + help
>>>> + Support for the AO clock controller on Amlogic A311Y3 based
>>>> + device, AKA A9.
>>>> + Say Y if you want A9 AO clock controller to work.
>>>> +
>>>> config COMMON_CLK_C3_PLL
>>>> tristate "Amlogic C3 PLL clock controller"
>>>> depends on ARM64
>>>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>>>> index c6719694a242..f89d027c282c 100644
>>>> --- a/drivers/clk/meson/Makefile
>>>> +++ b/drivers/clk/meson/Makefile
>>>> @@ -19,6 +19,7 @@ obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
>>>> obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>>>> obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
>>>> obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
>>>> +obj-$(CONFIG_COMMON_CLK_A9_AO) += a9-aoclk.o
>>>> obj-$(CONFIG_COMMON_CLK_C3_PLL) += c3-pll.o
>>>> obj-$(CONFIG_COMMON_CLK_C3_PERIPHERALS) += c3-peripherals.o
>>>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>>>> diff --git a/drivers/clk/meson/a9-aoclk.c b/drivers/clk/meson/a9-aoclk.c
>>>> new file mode 100644
>>>> index 000000000000..b7b3ca231a42
>>>> --- /dev/null
>>>> +++ b/drivers/clk/meson/a9-aoclk.c
>>>> @@ -0,0 +1,419 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
>>>> +/*
>>>> + * Copyright (C) 2026 Amlogic, Inc. All rights reserved
>>>> + */
>>>> +
>>>> +#include <dt-bindings/clock/amlogic,a9-aoclkc.h>
>>>> +#include <linux/clk-provider.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include "clk-regmap.h"
>>>> +#include "clk-dualdiv.h"
>>>> +#include "meson-clkc-utils.h"
>>>> +
>>>> +#define AO_OSCIN_CTRL 0x00
>>>> +#define AO_SYS_CLK0 0x04
>>>> +#define AO_PWM_CLK_A_CTRL 0x1c
>>>> +#define AO_PWM_CLK_B_CTRL 0x20
>>>> +#define AO_PWM_CLK_C_CTRL 0x24
>>>> +#define AO_PWM_CLK_D_CTRL 0x28
>>>> +#define AO_PWM_CLK_E_CTRL 0x2c
>>>> +#define AO_PWM_CLK_F_CTRL 0x30
>>>> +#define AO_PWM_CLK_G_CTRL 0x34
>>>> +#define AO_CEC_CTRL0 0x38
>>>> +#define AO_CEC_CTRL1 0x3c
>>>> +#define AO_RTC_BY_OSCIN_CTRL0 0x50
>>>> +#define AO_RTC_BY_OSCIN_CTRL1 0x54
>>>> +
>>>> +#define A9_COMP_SEL(_name, _reg, _shift, _mask, _pdata) \
>>>> + MESON_COMP_SEL(a9_ao_, _name, _reg, _shift, _mask, _pdata, NULL, 0, 0)
>>>> +
>>>> +#define A9_COMP_DIV(_name, _reg, _shift, _width) \
>>>> + MESON_COMP_DIV(a9_ao_, _name, _reg, _shift, _width, 0, CLK_SET_RATE_PARENT)
>>>> +
>>>> +#define A9_COMP_GATE(_name, _reg, _bit) \
>>>> + MESON_COMP_GATE(a9_ao_, _name, _reg, _bit, CLK_SET_RATE_PARENT)
>>>> +
>>>> +static struct clk_regmap a9_ao_xtal_in = {
>>>> + .data = &(struct clk_regmap_gate_data){
>>>> + .offset = AO_OSCIN_CTRL,
>>>> + .bit_idx = 3,
>>>> + },
>>>> + /*
>>>> + * It may be ao_sys's parent clock, its child clocks mark
>>>> + * CLK_IS_CRITICAL, So mark CLK_IS_CRITICAL for it.
>>>> + */
>>> I don't really get what you mean ... Could you rephrase ?
>>
>> The AO sys gate clock chain may be:
>>
>> ao_xtal_in->ao_xtal->ao_sys-> AO sys gate clocks
>>
>> "ao_xtal_in" is part of the parent chain of the AO sys gate clocks.
>>
>> Some of its downstream clocks are marked with CLK_IS_CRITICAL. To ensure
>> those clocks remain functional, ao_xtal_in must not be disabled and is
>> therefore marked as CLK_IS_CRITICAL as well.
> If any of the downstream clocks are critical and marked as such, there is not
> need to mark this one as well.
>
> You should only mark the clocks that are actually critical with the flag
> and let CCF figure out the dependencies.
Thanks for the clarification.
Understood. CCF already keeps the parent clocks of critical clocks enabled
during __clk_core_init(), so the CLK_IS_CRITICAL flag is not needed here.
I'll drop it in the next revision.
>>
>> I will rephrase it like this in the next version:
>>
>> /*
>> * ao_sys can select different clock sources. One possible clock
>> path is:
>> * ao_xtal_in->ao_xtal->ao_sys-> ao sys gate clocks
>> *
>> * ao_xtal_in is in the parent chain of AO sys gate clocks.
>> * Since some downstream clocks are marked CLK_IS_CRITICAL,
>> * ao_xtal_in must remain enabled and is therefore marked
>> * CLK_IS_CRITICAL as well.
>> */
>>
>>>> + .hw.init = CLK_HW_INIT_FW_NAME("ao_xtal_in", "xtal",
>>>> + &clk_regmap_gate_ops, CLK_IS_CRITICAL),
>>> I'm honestly not sure about this. It is correct, sure and the macro exist to be
>>> used but ... It does not really help readability here, does it ?
>>>
>>> (I know that was a feedback you've got on v1)
>>>
>>> Other than that, this looks good to me.
>>>
>> Ok, I will use the original clk_init_data for this one.
> Well my comment applies to whole thing really.
>
> There are surely ways in which the macro but the way we statically
> declare things, it adds a level of indirection that makes things harder
> to review IMO.
Understood. The same reasoning applies to the PLL and peripheral clock
controllers too.
I'll switch back to the explicit clk_init_data initialization and drop
CLK_HW_INIT_FW_NAME in the next revision.
>>
>> [ ... ]
>>
>>> --
>>> Jerome
> --
> Jerome
--
Jian
^ permalink raw reply
* Re: [PATCH 1/3] xfrm: extend ESP offload infrastructure for packet engines
From: Jihong Min @ 2026-06-11 12:23 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steffen Klassert, linux-kernel,
linux-crypto, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260611115646.GN327369@unreal>
On 6/11/26 20:56, Leon Romanovsky wrote:
> On Sat, May 23, 2026 at 09:15:20PM +0900, Jihong Min wrote:
>> Some ESP offload engines operate on whole ESP packets rather than the
>> generic software trailer layout. They can generate outbound ESP padding,
>> next-header and ICV bytes in hardware, and inbound decapsulation can
>> return an already-trimmed packet with the recovered next-header value.
>
> How does this differ from the existing IPsec packet‑offload support in the
> Linux kernel?
>
> Thanks
Hi Leon,
The short answer is that the series did not explain the relationship
with the existing XFRM packet-offload model clearly enough.
Existing XFRM_DEV_OFFLOAD_PACKET already represents the high-level model
where hardware handles ESP packet processing instead of only crypto
transforms. What I was trying to handle in this series was a narrower
case: EIP93 is a look-aside crypto/IPsec engine, not the netdev itself,
so the Airoha netdev had to attach that engine into its TX/RX path and
let it generate or consume the ESP packet framing. The extra hooks in
this series were meant for that look-aside integration, but looking
back, the split between the existing packet-offload model and the new
plumbing was not clean enough.
At this point, though, I think the right thing is to withdraw this
EIP93/Airoha series.
The reason is related to the SOE work I mentioned in the other patch
thread. Many Airoha SoCs also have a higher-performance IP block called
SOE (Secure Offload Engine). I recently wrote and tested a driver for
that block, and I am currently carrying it here: [kernel: add bonding
LAG XFRM offload infrastructure and Airoha
support](https://github.com/hurryman2212/OpenW1700k-test/commit/fbfe8f919f836bb62b3849f803865a4d9b8dc76f).
With the EIP93 path I could get around 1 Gbps, while the SOE path can
reach about 5 Gbps in my current setup. Because of that, integrating
this EIP93 ESP packet path directly into `airoha_eth` is no longer the
most useful direction for Airoha Ethernet.
That said, SOE exists only on some Airoha SoCs. EIP93 can still be
useful on other platforms as a look-aside ESP packet offloader, but I
think that needs a cleaner infrastructure than this series had. The
look-aside offloader should be able to live as a separate module, not be
tied directly to one specific netdev driver, while still allowing
compatible netdevs to attach it into the XFRM path. I think that needs a
more general infrastructure extension, so I would rather revisit the
EIP93 work later on top of that kind of model.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: David Hildenbrand (Arm) @ 2026-06-11 12:21 UTC (permalink / raw)
To: Lance Yang
Cc: akpm, xueyuan.chen21, linux-mm, linux-kernel, linux-arm-kernel,
x86, catalin.marinas, will, tglx, mingo, bp, dave.hansen, luto,
peterz, hpa, ljs, liam, vbabka, rppt, surenb, mhocko, ziy,
baolin.wang, npache, ryan.roberts, dev.jain, baohua, yang, jannh,
dave.hansen
In-Reply-To: <20260611115817.59353-1-lance.yang@linux.dev>
On 6/11/26 13:58, Lance Yang wrote:
>
> On Thu, Jun 11, 2026 at 01:28:58PM +0200, David Hildenbrand (Arm) wrote:
>> On 6/10/26 04:15, Lance Yang wrote:
>>>
>>>
>>> Right, this came from the RFC v1 discussion[1]. David preferred a page-
>>> range helper for possible future non-folio callers, not something folio-
>>> only.
>>>
>>> Of course, we could also add a folio wrapper on top of that if needed :)
>>
>> Best to document that as part of the patch description: we don't really expect
>> to have a lot of read-only folios in the near future (zero page is rather
>> special; maybe it won't even be a folio in the future).
>
> Ah, good to know, thanks. Will spell that out in RFC v3.
>
> Maybe something like this?
>
> The huge zero page is pretty special case, and maybe it won't even be a
> folio in the future. Since read-only folios are unlikely to become a
> common thing, a page-range helper is the cleaner fit.
Right. And if read-only folios in FSes become a real thing, we can always add
infrastructure for that.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 2/3] crypto: inside-secure: add EIP93 ESP packet backend
From: Jihong Min @ 2026-06-11 12:17 UTC (permalink / raw)
To: Simon Horman
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Steffen Klassert, linux-kernel, linux-crypto,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260527100824.GJ2256768@horms.kernel.org>
On 5/27/26 19:08, Simon Horman wrote:
> On Sat, May 23, 2026 at 09:15:21PM +0900, Jihong Min wrote:
>> Expose an EIP93 packet-mode IPsec backend for netdev drivers that need
>> ESP encapsulation and decapsulation offload without advertising EIP93
>> itself as a netdev.
>>
>> Add provider selection, capability reporting, SA lifecycle management,
>> IPsec request completion, and provider fault notification around the
>> existing EIP93 descriptor path.
>>
>> Assisted-by: Codex:gpt-5.5
>> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
>
> ...
>
>> diff --git a/drivers/crypto/inside-secure/eip93/eip93-ipsec.c b/drivers/crypto/inside-secure/eip93/eip93-ipsec.c
>
> ...
>
>> +static void eip93_ipsec_abort_requests(struct eip93_ipsec *ipsec, int err)
>> +{
>> + struct eip93_ipsec_sa *sa;
>> +
>> + while (true) {
>> + bool found = false;
>> +
>> + spin_lock_bh(&ipsec->lock);
>> + list_for_each_entry(sa, &ipsec->sa_list, node) {
>> + spin_lock(&sa->lock);
>> + if (sa->aborting) {
>> + spin_unlock(&sa->lock);
>> + continue;
>> + }
>> +
>> + sa->aborting = true;
>> + found = refcount_inc_not_zero(&sa->refcnt);
>> + spin_unlock(&sa->lock);
>> + if (found)
>> + break;
>> + }
>> + spin_unlock_bh(&ipsec->lock);
>> + if (!found)
>> + return;
>> +
>> + eip93_ipsec_abort_sa(sa, err);
>> + eip93_ipsec_sa_put(sa);
>
> sa is the iterator for the list_for_each_entry loop.
> However, here it is used outside of that context.
>
> "If list_for_each_entry, etc complete a traversal of the list, the
> iterator variable ends up pointing to an address at an offset from
> the list head, and not a meaningful structure. Thus this value
> should not be used after the end of the iterator.
>
> https://www.spinics.net/lists/linux-kernel-janitors/msg11994.html
>
> Flagged by Coccinelle.
>
Hi Simon,
Thanks for the feedback, and sorry for noticing this mail so late.
Your point is correct. The `list_for_each_entry()` iterator should not
be used outside the loop like that. If I continued with this series, I
would fix it by keeping a separate selected SA pointer before dropping
the lock.
At this point, though, I think the right thing is to withdraw this
EIP93/Airoha series.
The reason is that many Airoha SoCs also have a higher-performance IP
block called SOE (Secure Offload Engine). I recently wrote and tested a
driver for that block, and I am currently carrying it here: [kernel: add
bonding LAG XFRM offload infrastructure and Airoha
support](https://github.com/hurryman2212/OpenW1700k-test/commit/fbfe8f919f836bb62b3849f803865a4d9b8dc76f).
With the EIP93 path I could get around 1 Gbps, while the SOE path can
reach about 5 Gbps in my current setup. Because of that, integrating
this EIP93 ESP packet path directly into `airoha_eth` is no longer the
most useful direction for Airoha Ethernet.
That said, SOE exists only on some Airoha SoCs. EIP93 can still be
useful on other platforms as a look-aside ESP packet offloader, but I
think that needs a cleaner infrastructure than this series had. The
look-aside offloader should be able to live as a separate module, not be
tied directly to one specific netdev driver, while still allowing
compatible netdevs to attach it into the XFRM path. I think that needs a
more general infrastructure extension, so I would rather revisit the
EIP93 work later on top of that kind of model.
Sincerely,
Jihong Min
>> + }
>> +}
>
> ...
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Baoquan He @ 2026-06-11 12:03 UTC (permalink / raw)
To: Wandun
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, Rob Herring, saravanak,
bhe, rppt, pjw, palmer, aou, chenhuacai, kernel, catalin.marinas,
will, alex, akpm, pasha.tatashin, pratyush, ruirui.yang,
m.szyprowski, robin.murphy
In-Reply-To: <a3993db0-6975-455d-9674-4fd7cfcf80fc@gmail.com>
On 06/11/26 at 11:09am, Wandun wrote:
>
>
> On 6/11/26 10:09, Wandun wrote:
> >
> >
> > On 5/27/26 11:29, Wandun Chen wrote:
> >> From: Wandun Chen <chenwandun@lixiang.com>
> >>
> >> On SoCs that carve out large firmware-owned reserved memory (GPU
> >> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
> >> those carveouts as part of system RAM even though their contents are
> >> firmware state that is not useful for kernel crash analysis.
> >>
> >> This series introduces an opt-in 'dumpable' flag [1] on struct
> >> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
> >> DT-based architectures (arm64, riscv, loongarch). By default reserved
> >> regions are treated as non-dumpable; CMA regions are explicitly opted
> >> in because their pages are returned to the buddy allocator and may
> >> carry key crash-analysis data.
> >>
> >> The series is organized as follows:
> >> Patches 1-3: Pre-existing fixes and a small prep change.
> >> Patches 4-5: Restructure to allow appending /memreserve/ entries.
> >> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
> >> Patch 8: Add generic kdump helpers.
> >> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
> >> elfcorehdr preparation.
> > Hi,
> >
> > Gentle ping on this series.
> >
> > Status summary:
> > -patch 03: respun separately per Rob's suggestion, picked up for 7.2
> > -patch 06: Acked-by: Marek Szyprowski -patch 09: Acked-by: Will Deacon
> > The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
> > awaiting review. your feedback would be greately appreciated. I know we
> > are at the end of 7.1 -rc cycle, I don't want to rush this series, just
> > collecting more feedback, and will send next version based on 7.2-rc1.
> > If spliting the series into smaller logical group would make review
> > easier, please let me know. Best regards, Wandun
>
> Apologies for the formatting issue in my previous email.
> Here is the properly formatted version.
>
> Gentle ping on this series.
Thanks for the effort, the overral looks good to me at 1st glance. I will
check if there's concern on generic part. And meanwhile, I am wondering
if there's any chance x86 or other ARCH-es w/o OF/FDT can also choose to
not dump some areas, e.g GPU stolen memory. Surely, that's another story.
>
> Status summary:
> - patch 03: respun separately per Rob's suggestion, picked up for 7.2
> - patch 06: Acked-by: Marek Szyprowski
> - patch 09: Acked-by: Will Deacon
>
> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
> awaiting review. Your feedback would be greatly appreciated.
>
> I know we are at the end of 7.1-rc cycle, I don't want to rush this
> series, just collecting more feedback, and will send next version based
> on 7.2-rc1.
>
> If splitting the series into smaller logical groups would make review
> easier, please let me know.
>
> Best regards,
> Wandun
>
>
> >>
> >> v2 --> v3:
> >> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
> >> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
> >> 3. Add some prepare patches.
> >>
> >> v1 --> v2:
> >> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
> >> feedback [1], v2 drop that property and exclude reserve memory
> >> by default.
> >> 2. Split some prepared patches from the original patches.
> >> 3. Address coding-style comments on patch 5 from Rob.
> >>
> >> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-
> >> robh@kernel.org/
> >> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-
> >> chenwandun%40lixiang.com?part=4
> >>
> >> Wandun Chen (11):
> >> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
> >> kexec/crash: provide crash_exclude_mem_range() stub when
> >> CONFIG_CRASH_DUMP=n
> >> of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()
> >> fails
> >> of: reserved_mem: zero total_reserved_mem_cnt if no valid
> >> /reserved-memory entry
> >> of: reserved_mem: split alloc_reserved_mem_array() from
> >> fdt_scan_reserved_mem_late()
> >> of: reserved_mem: add dumpable flag to opt-in vmcore
> >> of: reserved_mem: save /memreserve/ entries into the reserved_mem
> >> array
> >> of: reserved_mem: add kdump helpers to exclude non-dumpable regions
> >> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
> >> riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
> >> loongarch: kdump: exclude non-dumpable reserved memory regions from
> >> vmcore
> >>
> >> arch/arm64/kernel/machine_kexec_file.c | 6 ++
> >> arch/loongarch/kernel/machine_kexec_file.c | 6 ++
> >> arch/riscv/kernel/machine_kexec_file.c | 4 +
> >> drivers/of/fdt.c | 11 +-
> >> drivers/of/of_private.h | 3 +
> >> drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++--
> >> include/linux/crash_core.h | 6 ++
> >> include/linux/of_reserved_mem.h | 15 +++
> >> kernel/dma/contiguous.c | 1 +
> >> 9 files changed, 157 insertions(+), 12 deletions(-)
> >>
> >
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Lance Yang @ 2026-06-11 11:58 UTC (permalink / raw)
To: david
Cc: lance.yang, akpm, xueyuan.chen21, linux-mm, linux-kernel,
linux-arm-kernel, x86, catalin.marinas, will, tglx, mingo, bp,
dave.hansen, luto, peterz, hpa, ljs, liam, vbabka, rppt, surenb,
mhocko, ziy, baolin.wang, npache, ryan.roberts, dev.jain, baohua,
yang, jannh, dave.hansen
In-Reply-To: <8c36a91d-288f-4ffb-b2ec-41e3ef789d72@kernel.org>
On Thu, Jun 11, 2026 at 01:28:58PM +0200, David Hildenbrand (Arm) wrote:
>On 6/10/26 04:15, Lance Yang wrote:
>>
>> On Tue, Jun 09, 2026 at 12:45:49PM -0700, Andrew Morton wrote:
>>> On Tue, 9 Jun 2026 22:37:59 +0800 Xueyuan Chen <xueyuan.chen21@gmail.com> wrote:
>>>
>>>> The huge zero folio is shared globally, and its contents should never
>>>> change after initialization. As Jann Horn pointed out[1], the kernel has
>>>> had bugs, including security bugs, where read-only pages were later written
>>>> to. If the persistent huge zero folio is read-only in the direct map, such
>>>> writes fault instead of silently corrupting the shared zero contents.
>>>>
>>>> Add arch_make_pages_readonly() so mm code can request read-only direct-map
>>>> protection for a page range. Direct-map protection is
>>>> architecture-specific, so the generic weak implementation does nothing.
>>>>
>>>> This was inspired by Jann Horn's read-only zero page work[1] and follow-up
>>>> discussion[2] with Yang Shi.
>>>>
>>>> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
>>>> [2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
>>>>
>>>> ...
>>>>
>>>> --- a/mm/huge_memory.c
>>>> +++ b/mm/huge_memory.c
>>>> @@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink,
>>>> return 0;
>>>> }
>>>>
>>>> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
>>>> +{
>>>> + return false;
>>>> +}
>>>> +
>>>> static struct shrinker *huge_zero_folio_shrinker;
>>>>
>>>> #ifdef CONFIG_SYSFS
>>>> @@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void)
>>>> * that get_huge_zero_folio() will most likely not fail as
>>>> * thp_shrinker_init() is invoked early on during boot.
>>>> */
>>>> - if (!get_huge_zero_folio())
>>>> + if (!get_huge_zero_folio()) {
>>>> pr_warn("Allocating persistent huge zero folio failed\n");
>>>> + return 0;
>>>> + }
>>>> +
>>>> + arch_make_pages_readonly(folio_page(huge_zero_folio, 0),
>>>> + HPAGE_PMD_NR);
>>>
>>> Can it simply pass the folio?
>>
>> Right, this came from the RFC v1 discussion[1]. David preferred a page-
>> range helper for possible future non-folio callers, not something folio-
>> only.
>>
>> Of course, we could also add a folio wrapper on top of that if needed :)
>
>Best to document that as part of the patch description: we don't really expect
>to have a lot of read-only folios in the near future (zero page is rather
>special; maybe it won't even be a folio in the future).
Ah, good to know, thanks. Will spell that out in RFC v3.
Maybe something like this?
The huge zero page is pretty special case, and maybe it won't even be a
folio in the future. Since read-only folios are unlikely to become a
common thing, a page-range helper is the cleaner fit.
^ permalink raw reply
* Re: [PATCH 00/18] pinctrl: airoha: split driver on shared code and SoC specific drivers, add supporf of en7523
From: Linus Walleij @ 2026-06-11 11:58 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-1-mikhail.kshevetskiy@iopsys.eu>
On Sun, Jun 7, 2026 at 2:17 AM Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> wrote:
> This patchset
> * fixes a series of issues
> * split combined driver on common code and several SoC specific drivers
> * adds support of en7523 SoC
This seems to be a collection of previously posted, reviewed and now
also applied patches. I don't know what to apply and what not to apply
now.
Please rebase the remaining patches on to of my pinctrl "devel" branch
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=devel
and repost as v2.
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH v3 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-11 11:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
p.zabel@pengutronix.de, Gary Yang, cix-kernel-upstream,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260611-numbat-of-unmistakable-excitement-f6cfed@quoll>
Hi,
[...]
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, June 11, 2026 3:42 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v3 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> EXTERNAL EMAIL
>
> > diff --git a/include/dt-bindings/clock/cix,sky1-audss.h b/include/dt-
> bindings/clock/cix,sky1-audss.h
> > new file mode 100644
> > index 000000000000..033046407dee
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/cix,sky1-audss.h
>
> Filename must match the compatible.
Will rename to include/dt-bindings/clock/cix,sky1-audss-clock.h to match the compatible.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH v5 4/8] dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-06-11 11:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, linux-can, devicetree,
linux-kernel, imx, linux-arm-kernel, NXP S32 Linux Team,
Christophe Lizzi, Alberto Ruiz, Enric Balletbo, Eric Chanudet,
Andra-Teodora Ilie, Larisa Grigore, Conor Dooley, Haibo Chen
In-Reply-To: <20260610-crouching-wild-mushroom-c8bf6a@quoll>
On 6/10/2026 9:37 AM, Krzysztof Kozlowski wrote:
> On Tue, Jun 09, 2026 at 04:29:50PM +0200, Ciprian Costea wrote:
>> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>>
>> Add NXP S32N79 SoC compatible string and interrupt properties.
>>
>> On S32N79, FlexCAN IP is integrated with two interrupt lines:
>> one for the mailbox interrupts (0-127) and one for signaling
>> bus errors and device state changes.
>>
>> Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
>> Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
>> Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
>> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
>> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
>
> You cannot test a binding (in a meaning what "testing" means). Building
> code is not testing.
>
>> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
>
> Not possible.
>
> Best regards,
> Krzysztof
>
Hello Krzysztof,
Yes, my bad. It makes total sense.
I presume I shouldn't send a new version just for this 'Tested-by'
removal - right ?
Best Regards,
Ciprian
^ permalink raw reply
* RE: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-11 11:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <992261bb-6e2e-4662-96f2-c5b18d513b32@kernel.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, June 11, 2026 3:41 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; Gary Yang
> <Gary.Yang@cixtech.com>
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> EXTERNAL EMAIL
>
> On 09/06/2026 08:27, Joakim Zhang wrote:
> >
> > Hi Krzysztof,
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzk@kernel.org>
> >> Sent: Friday, June 5, 2026 5:24 PM
> >> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> >> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
> >> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; Gary
> >> krzk+Yang
> >> <gary.yang@cixtech.com>
> >> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> >> clk@vger.kernel.org; devicetree@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> >> Subject: Re: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock:
> >> add audss clock controller
> >>
> >> EXTERNAL EMAIL
> >>
> >> On 05/06/2026 05:22, joakim.zhang@cixtech.com wrote:
> >>> +description: |
> >>> + Clock provider for the Cix Sky1 audio subsystem (AUDSS).
> >>> +
> >>> + This node is a child of a cix,sky1-audss-system-control
> >>> + MFD/syscon node (see cix,sky1-system-control.yaml). It does not
> >>> + have a reg property; clock mux, divider and gate fields are
> >>> + accessed through the parent
> >> register block.
> >>> +
> >>> + Software reset lines for AUDSS blocks are exposed on the parent
> >>> + syscon via #reset-cells. Reset indices are defined in
> >>> + include/dt-bindings/reset/cix,sky1-audss-system-control.h.
> >>> +
> >>> + Six SoC-level reference clocks listed in clocks/clock-names feed
> >>> + the AUDSS clock tree. The provider exposes the internal AUDSS
> >>> + clocks to other devices via #clock-cells; indices are defined in
> >>> + cix,sky1-
> >> audss.h.
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + const: cix,sky1-audss-clock
> >>> +
> >>> + '#clock-cells':
> >>> + const: 1
> >>> + description:
> >>> + Clock indices are defined in include/dt-bindings/clock/cix,sky1-audss.h.
> >>> +
> >>> + clocks:
> >>> + minItems: 6
> >>
> >> Drop
> > OK
> >
> >>> + maxItems: 6
> >>> + description:
> >>> + Six SoC-level audio reference clocks that feed the audio subsystem,
> >>> + in the same order as clock-names.
> >>> +
> >>> + clock-names:
> >>> + items:
> >>> + - const: audio_clk0
> >>> + - const: audio_clk1
> >>> + - const: audio_clk2
> >>> + - const: audio_clk3
> >>> + - const: audio_clk4
> >>> + - const: audio_clk5
> >>
> >> Pretty pointless names. Names matching indexes have no benefits, drop
> >> all of them and instead list items in "clocks" with description.
> > Yes, you are right, I will describe these more meaningful.
> >
> >>> +
> >>> + resets:
> >>> + maxItems: 1
> >>> + description: Audio subsystem NoC (or bus) reset line.
> >>> +
> >>> + power-domains:
> >>> + maxItems: 1
> >>> + description: Audio subsystem power domain.
> >>
> >> So the clock part has power domain but reset part does not? This is odd.
> >> Especially that parent is audss (right?) and here you describe that
> >> this is audss poer domain.
> >>
> >> Same question about resets.
> >
> > The reset and power domain takes effect on the entire subsystem, i.e., audss
> can be accessed only after powered on and reset released, including the CRU
> registers which contains clock/reset/control bits for all device within the audss.
> >
> > Because the reset controller probe does not access the hardware, while the
> clock controller does, so at that time, the power domain and reset were placed
> in the clock driver. At present, it does not seem very reasonable either.
> >
> > Linking the "reset" and "power domain" to the parent node requires us to
> ensure the order of the probes. We need to perform deferred probes within the
> child nodes until the parent node has been probed.
> >
>
> Please wrap your replies.
>
> You refer here to probe, so driver design, but I did not ask about that.
> I asked about hardware design.
Just as you understand, power domain and noc reset for the whole audss.
Thanks,
Joakim
^ permalink raw reply
* RE: [PATCH v3 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-11 11:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
p.zabel@pengutronix.de, Gary Yang, cix-kernel-upstream,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260611-gorgeous-macho-cricket-f1b78c@quoll>
Hi,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, June 11, 2026 3:40 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v3 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> EXTERNAL EMAIL
>
> On Wed, Jun 10, 2026 at 03:56:41PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> > and control registers in a dedicated CRU block. Software reset lines
> > are exposed on the syscon parent via #reset-cells, following the same
> > model as the existing Sky1 FCH and S5 system control bindings.
> >
> > Add the cix,sky1-audss-system-control compatible to
> > cix,sky1-system-control.yaml for the MFD/syscon parent node, and
> > define AUDSS software reset indices in
> > include/dt-bindings/reset/cix,sky1-audss-system-control.h for I2S,
> > HDA, DMAC, mailbox, watchdog and timer blocks.
>
> All this is pretty pointless - you explained the binding, which answers nothing
> why you did it that way. Instead you must explain the hardware design.
>
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > .../soc/cix/cix,sky1-system-control.yaml | 52 +++++++++++++++++--
> > .../reset/cix,sky1-audss-system-control.h | 25 +++++++++
> > 2 files changed, 72 insertions(+), 5 deletions(-) create mode 100644
> > include/dt-bindings/reset/cix,sky1-audss-system-control.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml index a01a515222c6..61d26a69fd44 100644
> > ---
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-contro
> > +++ l.yaml
> > @@ -15,11 +15,16 @@ description:
> >
> > properties:
> > compatible:
> > - items:
> > - - enum:
> > - - cix,sky1-system-control
> > - - cix,sky1-s5-system-control
> > - - const: syscon
> > + oneOf:
> > + - items:
> > + - enum:
> > + - cix,sky1-system-control
> > + - cix,sky1-s5-system-control
> > + - const: syscon
> > + - items:
> > + - const: cix,sky1-audss-system-control
> > + - const: simple-mfd
>
> Just so you are aware - this means children do not depend on the parent for
> operation. You will not be able to fix it later, if it turns out that children do
> depend...
Understood. simple-mfd is intentional: the clock child only accesses the parent MMIO via syscon and external resets/clocks via phandles. No parent driver coordination is needed today. We attached all resources audss needed from child node now.
> > + - const: syscon
> >
> > reg:
> > maxItems: 1
> > @@ -27,6 +32,28 @@ properties:
> > '#reset-cells':
> > const: 1
> >
> > + clock-controller:
> > + type: object
> > + properties:
> > + compatible:
> > + const: cix,sky1-audss-clock
> > + required:
> > + - compatible
> > + additionalProperties: true
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: cix,sky1-audss-system-control
> > + then:
> > + required:
> > + - clock-controller
> > + else:
> > + properties:
> > + clock-controller: false
> > +
> > required:
> > - compatible
> > - reg
> > @@ -40,3 +67,18 @@ examples:
> > reg = <0x4160000 0x100>;
> > #reset-cells = <1>;
> > };
> > + - |
> > + audss_syscon: system-controller@7110000 {
> > + compatible = "cix,sky1-audss-system-control", "simple-mfd", "syscon";
> > + reg = <0x7110000 0x10000>;
> > + #reset-cells = <1>;
> > +
> > + clock-controller {
> > + compatible = "cix,sky1-audss-clock";
> > + power-domains = <&smc_devpd 0>;
>
> My questions from v2 from the other patch are still valid - why audss system
> clock controller is outside of the power domain? Why the audss reset is outside,
> but audss clock not?
>
> This does not feel like correct hardware representation.
Yes, I agree with your point. This does not really reflect the hardware well. Both noc reset and power-domain takes effect on audss, should move to parent node.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH 1/3] xfrm: extend ESP offload infrastructure for packet engines
From: Leon Romanovsky @ 2026-06-11 11:56 UTC (permalink / raw)
To: Jihong Min
Cc: Christian Marangi, Antoine Tenart, Herbert Xu, David S . Miller,
Lorenzo Bianconi, Andrew Lunn, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Steffen Klassert, linux-kernel,
linux-crypto, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260523121522.3023992-2-hurryman2212@gmail.com>
On Sat, May 23, 2026 at 09:15:20PM +0900, Jihong Min wrote:
> Some ESP offload engines operate on whole ESP packets rather than the
> generic software trailer layout. They can generate outbound ESP padding,
> next-header and ICV bytes in hardware, and inbound decapsulation can
> return an already-trimmed packet with the recovered next-header value.
How does this differ from the existing IPsec packet‑offload support in the
Linux kernel?
Thanks
^ permalink raw reply
* Re: [PATCH 00/11] pinctrl: airoha: small fixes
From: Linus Walleij @ 2026-06-11 11:53 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Lorenzo Bianconi, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
On Sat, Jun 6, 2026 at 4:04 AM Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> wrote:
> This is a set of small fixes for Airoha pinctrl driver.
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 04/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Petr Tesarik @ 2026-06-11 11:50 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <20260611113740.GB1066031@ziepe.ca>
On Thu, 11 Jun 2026 08:37:40 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Thu, Jun 11, 2026 at 10:55:47AM +0530, Aneesh Kumar K.V wrote:
> > Jason Gunthorpe <jgg@ziepe.ca> writes:
> >
> > > The sashiko note does look legit though:
> > >
> > > if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > > !gfpflags_allow_blocking(gfp) && !coherent) {
> > > page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
> > > gfp, attrs, NULL);
> > > if (!page)
> > > return NULL;
> > >
> > > I don't see anything doing the force_dma_unencrypted test along this
> > > callchain..
> > >
> > > I guess it should be done one step up in dma_alloc_attrs() instead of
> > > in dma_direct_alloc()?
> > >
> >
> > I think we should do something similar to what dma_map_phys() does here,
> > considering that we only support DMA direct with DMA_ATTR_CC_SHARED/DMA_ATTR_ALLOC_CC_SHARED.
>
> Yeah, I think that's the right idea for now..
>
> > + if (force_dma_unencrypted(dev))
> > + attrs |= DMA_ATTR_ALLOC_CC_SHARED;
> > +
> > + is_cc_shared = attrs & DMA_ATTR_CC_SHARED;
> > +
> > if (dma_alloc_direct(dev, ops) || arch_dma_alloc_direct(dev)) {
> > cpu_addr = dma_direct_alloc(dev, size, dma_handle, flag, attrs);
> > + } else if (is_cc_shared) {
> > + trace_dma_alloc(dev, NULL, 0, size, DMA_BIDIRECTIONAL, flag,
> > + attrs);
>
> But it would be clearer to put the test in the iommu_ functions I
> think, since they are the ones that have the issue. We will need to
> fix it someday..
>
> I think we can ignore the op-> functions, arches cannot support CC and
> still use dma_map_ops..
Hm, sounds reasonable. Should we probably enforce this at configure or
build time?
Petr T
^ permalink raw reply
* Re: [PATCH v2 0/3] pinctrl: sunxi: a523: fix GPIO IRQ operation
From: Linus Walleij @ 2026-06-11 11:49 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, linux-gpio, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260327113006.3135663-1-andre.przywara@arm.com>
On Fri, Mar 27, 2026 at 12:30 PM Andre Przywara <andre.przywara@arm.com> wrote:
> this is the minimal fix version for the GPIO IRQ operation on the
> Allwinner A523/A527/T527 SoCs. SD card detection is broken as a result,
> which is a major annoyance. Those patches here fix that problem, and
> should go into v7.0 still, if possible.
Patches 1 & 2 applied to the pinctrl tree, please send patch 3 to
the SoC tree.
Sorry for missing this, dunno what happened. Probably it got
lost by me trying to use korgalore and screwing up.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] spi: xilinx: use FIFO occupancy register to determine buffer size
From: Michal Simek @ 2026-06-11 11:46 UTC (permalink / raw)
To: Lars Pöschel, Mark Brown, linux-spi, linux-arm-kernel,
linux-kernel
Cc: Mahapatra, Amit Kumar, lars.poeschel
In-Reply-To: <e6af23c7-1ba9-4acc-af16-394fde75b4da@edag.com>
On 6/11/26 13:36, Lars Pöschel wrote:
> On 6/11/26 10:52 Michal Simek wrote:
>> +Amit,
>>
>> On 6/11/26 09:10, lars.poeschel.linux@edag.com wrote:
>>> From: Lars Pöschel <lars.poeschel@edag.com>
>>>
>>> The method the driver uses to determine the size of the FIFO has a
>>> problem. What it currently does is this:
>>> It stops the SPI hardware and writes to the TX FIFO register until TX
>>> FIFO FULL asserts in the status register. But the hardware does not only
>>> have the FIFO, it also seems to have a shift register. This can be seen,
>>
>> I don't think you should guess here
>
> Ok, I will change that.
>
>>> when writing a byte to the FIFO (while the SPI hardware is stopped,) the
>>> TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for
>>> example, the current method returns a 17.
>>
>>
>>
>>
>>> This is a problem, at least when using the driver in irq mode. The same
>>> size determined for the TX FIFO is also assumed for the RX FIFO. When an
>>> SPI transaction wants to write the amount of the FIFO size or more
>>> bytes, the following happens, let's assume 16 bytes FIFO size:
>>
>> s/let's/for example/
>
> Ok.
>
>>> The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and
>>> starts the SPI hardware and goes sleep.
>>> The hardware then shifts out 17 bytes (FIFO + shift register) and
>>> simultaneously reads bytes into the RX FIFO, but it only has 16 places,
>>> so it looses one byte. Then TX FIFO empty asserts, wakes the driver
>>> again, which has a fast path and reads 16 bytes from the RX FIFO, but
>>> before reading the last 17th byte (which is lost) it does this:
>>>
>>> sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
>>> if (!(sr & XSPI_SR_RX_EMPTY_MASK)) {
>>> xilinx_spi_rx(xspi);
>>> rx_words--;
>>> }
>>>
>>> It reads the status register and checks if the RX FIFO is not empty.
>>> But it is empty in our case. So this check spins in a while loop
>>> forever locking the driver.
>>>
>>> The new method for determining the FIFO size is to read the SPITFOR (TX
>>> FIFO occupancy register, value = occupancy - 1) after filling the TX
>>> FIFO to obtain the true FIFO storage depth, which also equals the RX
>>> FIFO depth. In non-FIFO configurations (n_words == 1) the register does
>>> not exist; return 1 directly in that case.
>>>
>>
>> missing fix tag.
>
> Ok, I will add one.
>
>>> Signed-off-by: Lars Pöschel <lars.poeschel@edag.com>
>>> ---
>>> drivers/spi/spi-xilinx.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
>>> index 9f065d4e27d1..2d31e30fc4eb 100644
>>> --- a/drivers/spi/spi-xilinx.c
>>> +++ b/drivers/spi/spi-xilinx.c
>>> @@ -54,6 +54,7 @@
>>> #define XSPI_RXD_OFFSET 0x6c /* Data Receive Register */
>>> #define XSPI_SSR_OFFSET 0x70 /* 32-bit Slave Select Register */
>>> +#define XSPI_TFOR_OFFSET 0x74 /* Transmit FIFO Occupancy Register */
>>> /* Register definitions as per "OPB IPIF (v3.01c) Product Specification",
>>> DS414
>>> * IPIF registers are 32 bit
>>> @@ -377,7 +378,9 @@ static int xilinx_spi_find_buffer_size(struct xilinx_spi
>>> *xspi)
>>> n_words++;
>>> } while (!(sr & XSPI_SR_TX_FULL_MASK));
>>> - return n_words;
>>> + if (n_words == 1)
>>> + return 1;
>>> + return xspi->read_fn(xspi->regs + XSPI_TFOR_OFFSET) + 1;
>>
>> Based on pg153
>> Exists only when FIFO Depth is set to 16 or 256
>>
>> Based on ds570
>> This register does not exist if C_FIFO_EXIST = 0
>>
>> It means this is not going to work with all HW configurations.
>
> I think it will work with all HW configurations, even with no FIFO configured.
> You are right, TFOR does not exist in non-FIFO configurations, but then you will
> take the
>
> if (n_words ==1)
> return 1;
>
> path and exit before reading this register. And then according to PG153, Table
> 2-6, Tx_Full bit:
> "Note: When FIFOs do not exist, this bit is set High when an AXI write to the
> transmit register has been made (this option is available only in standard SPI
> mode). This bit is cleared when the SPI transfer is completed."
> So n_words should be 1 in this case and I think this should still work.
>
>> Pretty much you wanted to use this register to find out how big is the fifo
>> but I think in this case you should be just fixing logic around +-1 caused by
>> n_words++ in a loop.
>>
>> What about to change logic to be like this? It is clear and it is without any
>> +1 logic and no fifo is handled separately?
>>
>> while (1) {
>>
>> xspi->write_fn(0, xspi->regs + XSPI_TXD_OFFSET);
>>
>> sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
>>
>> if (sr & XSPI_SR_TX_FULL_MASK)
>>
>> break;
>>
>> n_words++;
>>
>> }
>>
>>
>>
>>
>> /* Handle NO FIFO case separately */
>>
>> if (!n_words)
>>
>> return 1;
>>
>>
>>
>>
>> return n_words;
>
> If you still think, this is more clear or better readable, then I can change it
> like this. Let me know!
I understand that without FIFO you should never reach that code but I still
think it is better not to deal with it. Pretty much if you want to wire this
register I think dt binding should be extended to cover this optional feature.
That's why I think it is better not to introduce it.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v6 04/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Jason Gunthorpe @ 2026-06-11 11:37 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
Marek Szyprowski, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley
In-Reply-To: <yq5aa4t1myw4.fsf@kernel.org>
On Thu, Jun 11, 2026 at 10:55:47AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
>
> > The sashiko note does look legit though:
> >
> > if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > !gfpflags_allow_blocking(gfp) && !coherent) {
> > page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
> > gfp, attrs, NULL);
> > if (!page)
> > return NULL;
> >
> > I don't see anything doing the force_dma_unencrypted test along this
> > callchain..
> >
> > I guess it should be done one step up in dma_alloc_attrs() instead of
> > in dma_direct_alloc()?
> >
>
> I think we should do something similar to what dma_map_phys() does here,
> considering that we only support DMA direct with DMA_ATTR_CC_SHARED/DMA_ATTR_ALLOC_CC_SHARED.
Yeah, I think that's the right idea for now..
> + if (force_dma_unencrypted(dev))
> + attrs |= DMA_ATTR_ALLOC_CC_SHARED;
> +
> + is_cc_shared = attrs & DMA_ATTR_CC_SHARED;
> +
> if (dma_alloc_direct(dev, ops) || arch_dma_alloc_direct(dev)) {
> cpu_addr = dma_direct_alloc(dev, size, dma_handle, flag, attrs);
> + } else if (is_cc_shared) {
> + trace_dma_alloc(dev, NULL, 0, size, DMA_BIDIRECTIONAL, flag,
> + attrs);
But it would be clearer to put the test in the iommu_ functions I
think, since they are the ones that have the issue. We will need to
fix it someday..
I think we can ignore the op-> functions, arches cannot support CC and
still use dma_map_ops..
Jason
^ permalink raw reply
* [PATCH net 1/2] net/stmmac: Apply TBS config only to used queues
From: Jakub Raczynski @ 2026-06-11 11:33 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, linux-kernel, linux-arm-kernel, k.domagalski,
k.tegowski, Jakub Raczynski, Chang-Sub Lee
In-Reply-To: <20260611113358.3379518-1-j.raczynski@samsung.com>
While opening stmmac driver, there is enabling of TBS (Time-Based Scheduling)
option in dma config. Currently this is executed for all possible TX queues via
MTL_MAX_TX_QUEUES macro, but actual number of queues used might differ.
While setting this is generally harmless, since memory for MTL_MAX_TX_QUEUES
is allocated, it is incorrect, because it prepares config for unused queues.
Change this to apply tbs config only to tx_queues_to_use.
Fixes: 4896bb7c0b31a ("net: stmmac: do not clear TBS enable bit on link up/down")
Co-developed-by: Chang-Sub Lee <cs0617.lee@samsung.com>
Signed-off-by: Chang-Sub Lee <cs0617.lee@samsung.com>
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3591755ea30b..5917bf47c7de 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4140,7 +4140,7 @@ static int __stmmac_open(struct net_device *dev,
u8 chan;
int ret;
- for (int i = 0; i < MTL_MAX_TX_QUEUES; i++)
+ for (int i = 0; i < priv->plat->tx_queues_to_use; i++)
if (priv->dma_conf.tx_queue[i].tbs & STMMAC_TBS_EN)
dma_conf->tx_queue[i].tbs = priv->dma_conf.tx_queue[i].tbs;
memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));
--
2.34.1
^ permalink raw reply related
* [PATCH net 0/2] net/stmmac: Fixes for maximum TX/RX queues to use by driver
From: Jakub Raczynski @ 2026-06-11 11:33 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, linux-kernel, linux-arm-kernel, k.domagalski,
k.tegowski, Jakub Raczynski
In-Reply-To: <CGME20260611113403eucas1p1f4b61896c875f1f6833d6ca136472af8@eucas1p1.samsung.com>
When contributing other changes preparing functions for new XGMAC hardware
https://lore.kernel.org/netdev/20260601162537.553512-1-j.raczynski@samsung.com/
there have been reports by Sashiko AI review about pre-existing issues
in the code. These problems are non-insignificant and are 'net' material fixes,
rather than net-next features.
One issue in this patchset was reported by Sashiko AI, while other
technically part of new patchset, but is reasonable related fix.
All of issues are wrong DTS configuration, but kernel needs to handle it.
Jakub Raczynski (2):
net/stmmac: Apply TBS config only to used queues
net/stmmac: Apply MTL_MAX queue limit if config missing
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-11 11:31 UTC (permalink / raw)
To: Mark Brown, linux-spi
Cc: linux-arm-kernel, linux-kernel, Kunihiko Hayashi, Sangyun Kim,
Kyungwook Boo, stable, Masami Hiramatsu
The driver calls devm_request_irq() before initializing the completion
used by the interrupt handler. Because the interrupt may occur immediately
after devm_request_irq(), the handler may execute before init_completion().
This may result in calling complete() on an uninitialized completion,
causing undefined behavior. This has been observed with KASAN.
Fix this by initializing the completion before registering the IRQ.
Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Reported-by: Kyungwook Boo <bookyungwook@gmail.com>
Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/spi/spi-uniphier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index 9e1d364a6198..6d3463fe0e3c 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -659,6 +659,8 @@ static int uniphier_spi_probe(struct platform_device *pdev)
priv->host = host;
priv->is_save_param = false;
+ init_completion(&priv->xfer_done);
+
priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(priv->base)) {
ret = PTR_ERR(priv->base);
@@ -690,8 +692,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
goto out_disable_clk;
}
- init_completion(&priv->xfer_done);
-
clk_rate = clk_get_rate(priv->clk);
host->max_speed_hz = DIV_ROUND_UP(clk_rate, SSI_MIN_CLK_DIVIDER);
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: David Hildenbrand (Arm) @ 2026-06-11 11:28 UTC (permalink / raw)
To: Lance Yang, akpm
Cc: xueyuan.chen21, linux-mm, linux-kernel, linux-arm-kernel, x86,
catalin.marinas, will, tglx, mingo, bp, dave.hansen, luto, peterz,
hpa, ljs, liam, vbabka, rppt, surenb, mhocko, ziy, baolin.wang,
npache, ryan.roberts, dev.jain, baohua, yang, jannh, dave.hansen
In-Reply-To: <20260610021508.46000-1-lance.yang@linux.dev>
On 6/10/26 04:15, Lance Yang wrote:
>
> On Tue, Jun 09, 2026 at 12:45:49PM -0700, Andrew Morton wrote:
>> On Tue, 9 Jun 2026 22:37:59 +0800 Xueyuan Chen <xueyuan.chen21@gmail.com> wrote:
>>
>>> The huge zero folio is shared globally, and its contents should never
>>> change after initialization. As Jann Horn pointed out[1], the kernel has
>>> had bugs, including security bugs, where read-only pages were later written
>>> to. If the persistent huge zero folio is read-only in the direct map, such
>>> writes fault instead of silently corrupting the shared zero contents.
>>>
>>> Add arch_make_pages_readonly() so mm code can request read-only direct-map
>>> protection for a page range. Direct-map protection is
>>> architecture-specific, so the generic weak implementation does nothing.
>>>
>>> This was inspired by Jann Horn's read-only zero page work[1] and follow-up
>>> discussion[2] with Yang Shi.
>>>
>>> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
>>> [2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
>>>
>>> ...
>>>
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink,
>>> return 0;
>>> }
>>>
>>> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
>>> +{
>>> + return false;
>>> +}
>>> +
>>> static struct shrinker *huge_zero_folio_shrinker;
>>>
>>> #ifdef CONFIG_SYSFS
>>> @@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void)
>>> * that get_huge_zero_folio() will most likely not fail as
>>> * thp_shrinker_init() is invoked early on during boot.
>>> */
>>> - if (!get_huge_zero_folio())
>>> + if (!get_huge_zero_folio()) {
>>> pr_warn("Allocating persistent huge zero folio failed\n");
>>> + return 0;
>>> + }
>>> +
>>> + arch_make_pages_readonly(folio_page(huge_zero_folio, 0),
>>> + HPAGE_PMD_NR);
>>
>> Can it simply pass the folio?
>
> Right, this came from the RFC v1 discussion[1]. David preferred a page-
> range helper for possible future non-folio callers, not something folio-
> only.
>
> Of course, we could also add a folio wrapper on top of that if needed :)
Best to document that as part of the patch description: we don't really expect
to have a lot of read-only folios in the near future (zero page is rather
special; maybe it won't even be a folio in the future).
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Vinod Koul @ 2026-06-11 11:26 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright
In-Reply-To: <ebcad67e-e14a-4d0e-b3e0-79ae1d146eaf@collabora.com>
On 03-06-26, 13:27, Cristian Ciocaltea wrote:
> On 5/20/26 10:05 PM, Cristian Ciocaltea wrote:
> > Hi Vinod,
> >
> > On 5/11/26 9:21 PM, Cristian Ciocaltea wrote:
> >> This series provides a set of bug fixes and cleanups for the Rockchip
> >> Samsung HDPTX PHY driver.
> >>
> >> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
> >> calculation and synchronization issues. Specifically, it fixes edge
> >> cases where the PHY PLL is pre-programmed by an external component (like
> >> a bootloader) or when changing the color depth (bpc) while keeping the
> >> modeline constant. Because the Common Clock Framework .set_rate()
> >> callback might not be invoked if the pixel clock remains unchanged, this
> >> previously led to out-of-sync states between CCF and the actual HDMI PHY
> >> configuration.
> >>
> >> The second part focuses on code cleanups and modernizing the register
> >> access. Now that dw_hdmi_qp driver has fully switched to using
> >> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
> >> and the restrict_rate_change flag logic. Finally, it refactors the
> >> driver to consistently use standard bitfield macros.
> >>
> >> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> >> ---
> >> Changes in v2:
> >> - Collected Tested-by tags from Thomas and Simon
> >> - Fixed a typo in commit description of patch 1
> >> - Added a comment in patch 2 explaining why PLL config errors are
> >> ignored for rk_hdptx_phy_consumer_get()
> >> - Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
> >> - Rebased onto latest phy/fixes
> >> - Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
> >
> > In case you missed my comments from last week on the Sashiko AI review findings
> > - in short, I don't think there is anything to worry about and the series should
> > be fine to apply as-is. Please let me know if you would still prefer a new
> > revision.
> Kind reminder..
Please post a new revision based on phy/next
Thanks
--
~Vinod
^ permalink raw reply
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