* Re: [PATCH v11 05/11] riscv: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
From: Guo Ren @ 2026-03-30 3:47 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, cfsworks, osandov,
jbohac, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, chenjiahao16, hbathini,
takahiro.akashi, james.morse, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <20260328074013.3589544-6-ruanjinjie@huawei.com>
On Sat, Mar 28, 2026 at 3:41 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> There is a race condition between the kexec_load() system call
> (crash kernel loading path) and memory hotplug operations that can lead
> to buffer overflow and potential kernel crash.
riscv left no margin for hotplug in prepare_elf_headers(). Actually,
this check has been in crash_exclude_mem_range(); this patch makes it
happen earlier.
Although this patch has no real effect for riscv for the current. I
still give an acked-by, because it's a proper check step in this
callback.
Reviewed-by: Guo Ren <guoren@kernel.org>
--
Best Regards
Guo Ren
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: kaanapali-qrd: Add SoCCP node
From: Jingyi Wang @ 2026-03-30 3:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, 20260310-knp-soccp-v4-0-0a91575e0e7e
In-Reply-To: <bb03901e-5054-44cf-a150-6c7d5ee0f78a@oss.qualcomm.com>
On 3/27/2026 5:53 PM, Konrad Dybcio wrote:
> On 3/27/26 4:20 AM, Jingyi Wang wrote:
>> Add SoCCP node on Kaanapali QRD board.
>
> This is really more of an "add firmware path"
>
will update the commit msg in next version.
>>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>> index da0e8f9091c3..6a7eb7f4050a 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
>> @@ -781,6 +781,11 @@ &remoteproc_cdsp {
>> status = "okay";
>> };
>>
>> +&remoteproc_soccp {
>> + firmware-name = "qcom/kaanapali/soccp.mbn",
>> + "qcom/kaanapali/soccp_dtb.mbn";
>
> Given that this contains battmgr now, can MTP and QRD use the same
> firmware?
>
Offline checked with the POC for SoCCP firmware, MTP and QRD board
share the same soccp firmware.
Thanks，
Jingyi
> Konrad
^ permalink raw reply
* Re: [PATCH v5 2/8] ARM: dts: aspeed: yosemite5: Remove ambiguous power monitor DTS nodes
From: Kevin Tung @ 2026-03-30 3:15 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Amithash Prasasd, Kevin Tung, Ken Chen, Leo Yang, Jackson Liu,
Daniel Hsu
In-Reply-To: <d7794f74b26bbc1ee0a70e39c5671acc018f80eb.camel@codeconstruct.com.au>
On Thu, Mar 26, 2026 at 2:07 PM Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> Hi Kevin,
>
> Sorry for the delay.
>
> On Mon, 2026-03-09 at 11:41 -0700, Kevin Tung wrote:
> > On Tue, Mar 3, 2026 at 6:41 PM Andrew Jeffery
> > <andrew@codeconstruct.com.au> wrote:
> > >
> > > Hi Kevin,
> > >
> > > Sorry for the patchy replies so far, but this series bothers me and
> > > other priorities keep bumping it down the list.
> > >
> > > On Mon, 2026-02-23 at 19:17 +0800, Kevin Tung wrote:
> > > > Two different power monitor devices, using different drivers, reuse
> > > > I2C addresses 0x40 and 0x45 on bus 10 across Yosemite5 board variants.
> > > > Defining these devices statically in the DTS can lead to incorrect
> > > > driver binding on newer boards when the wrong device is instantiated.
> > >
> > > There are effective methods of maintaining devicetrees for variants.
> > > Why are we choosing to remove information about the platform rather
> > > than use existing techniques to properly describe them?
> > >
> > Hi Andrew,
> >
> > This is due to hardware design changes during earlier development
> > stages, and the fix is expected to remain stable as the design has
> > matured.
> > Could you guide me on the best way to maintain devicetrees for
> > variants? Thank you :)
>
> My expectation is your platforms move through several design phases
> prior to (mass?) production. My suspicion is that you have sent a
> devicetree for the pre-production design phases, and you're trying to
> evolve that one devicetree to match the design for whatever current
> phase you're in.
>
> So, ideally: Send a devicetree only for the finalised design. Don't
> send devicetrees for pre-production designs.
>
> If you feel you can't do that for some reason, an alternative is to
> have a separate .dts file for each phase in the design process.
>
> This may sound tedious but it doesn't have to be a burden to maintain.
>
> For instance, you can use one or more .dtsi files to describe the
> common components and relationships for your platform. These .dtsi
> files are then #included into .dts files as usual. Often .dtsi files
> are used to isolate different hardware scopes (SoC vs board, for
> instance), but we're not limited to that, we can use them for the
> purpose outlined above too.
>
> If there are only (very) minor differences, there's also the option of
> #including another .dts file. From there you can adjust properties or
> even delete nodes where it makes sense. For example, we maintain a .dts
> file for the latest revision of the AST2600-EVB, but we also have a
> separate .dts for the A1 revision with a different regulator setup:
>
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb.dts?h=v7.0-rc5
> - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed/aspeed-ast2600-evb-a1.dts?h=v7.0-rc5
>
> Any of these are better options than this current approach of trying to
> justify incompatible changes against unclear design boundaries.
>
> Andrew
Hi Andrew,
Thank you for the guidance.
We will submit devicetree changes for the finalized design and ensure
they align with the hardware to maintain stability and avoid
incompatible changes.
Kevin
^ permalink raw reply
* RE: [PATCH v5 08/10] clk: realtek: Add support for MMC-tuned PLL clocks
From: Yu-Chun Lin [林祐君] @ 2026-03-30 3:00 UTC (permalink / raw)
To: Stephen Boyd, afaerber@suse.com, conor+dt@kernel.org,
Edgar Lee [李承諭],
Jyan Chou [周芷安], krzk+dt@kernel.org,
mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <177440366488.5403.14385693004290004608@localhost.localdomain>
> Quoting Yu-Chun Lin (2026-03-23 19:53:29)
> > diff --git a/drivers/clk/realtek/clk-pll-mmc.c
> > b/drivers/clk/realtek/clk-pll-mmc.c
> > new file mode 100644
> > index 000000000000..017663738c1f
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-pll-mmc.c
> > @@ -0,0 +1,399 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2021 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include "clk-pll.h"
>
> Include what you use in this C file, not just this header file. That makes it
> simpler to see what is used without following include trails.
Got it. I will explicitly include the required headers directly in this .c file.
> > +
> > +#define PLL_EMMC1_OFFSET 0x0
> > +#define PLL_EMMC2_OFFSET 0x4
> > +#define PLL_EMMC3_OFFSET 0x8
> > +#define PLL_EMMC4_OFFSET 0xc
> > +#define PLL_SSC_DIG_EMMC1_OFFSET 0x0
> > +#define PLL_SSC_DIG_EMMC3_OFFSET 0xc
> > +#define PLL_SSC_DIG_EMMC4_OFFSET 0x10
> > +
> > +#define PLL_MMC_SSC_DIV_N_VAL 0x1b
> > +
> > +#define PLL_PHRT0_MASK BIT(1)
> > +#define PLL_PHSEL_MASK GENMASK(4, 0)
> > +#define PLL_SSCPLL_RS_MASK GENMASK(12, 10)
> > +#define PLL_SSCPLL_ICP_MASK GENMASK(9, 5)
> > +#define PLL_SSC_DIV_EXT_F_MASK GENMASK(25, 13)
> > +#define PLL_PI_IBSELH_MASK GENMASK(28, 27)
> > +#define PLL_SSC_DIV_N_MASK GENMASK(23, 16)
> > +#define PLL_NCODE_SSC_EMMC_MASK GENMASK(20, 13)
> > +#define PLL_FCODE_SSC_EMMC_MASK GENMASK(12, 0)
> > +#define PLL_GRAN_EST_EM_MC_MASK GENMASK(20, 0)
> > +#define PLL_EN_SSC_EMMC_MASK BIT(0)
> > +#define PLL_FLAG_INITAL_EMMC_MASK BIT(1)
> [...]
> > diff --git a/drivers/clk/realtek/clk-pll.h
> > b/drivers/clk/realtek/clk-pll.h index 2d27a44a270c..9cf219871218
> > 100644
> > --- a/drivers/clk/realtek/clk-pll.h
> > +++ b/drivers/clk/realtek/clk-pll.h
> > @@ -44,4 +44,25 @@ static inline struct clk_pll *to_clk_pll(struct
> > clk_hw *hw) extern const struct clk_ops rtk_clk_pll_ops; extern
> > const struct clk_ops rtk_clk_pll_ro_ops;
> >
> > +struct clk_pll_mmc {
> > + struct clk_regmap clkr;
> > + int pll_ofs;
> > + int ssc_dig_ofs;
>
> These offsets should be unsigned?
>
Yes, I will fix it.
> > + struct clk_hw phase0_hw;
> > + struct clk_hw phase1_hw;
> > + u32 set_rate_val_53_97_set_ipc: 1;
>
> bool? Doubt we care about this unless we're packing structs (which we
> shouldn't be).
>
This member is actually redundant, so I will just remove it.
> > +};
> > +
> > +#define __clk_pll_mmc_hw(_ptr) __clk_regmap_hw(&(_ptr)->clkr)
> > +
> > +static inline struct clk_pll_mmc *to_clk_pll_mmc(struct clk_hw *hw) {
> > + struct clk_regmap *clkr = to_clk_regmap(hw);
> > +
> > + return container_of(clkr, struct clk_pll_mmc, clkr); }
Best regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Liu Ying @ 2026-03-30 3:02 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <DHDNA5HLQPIB.3F21G9QPBUQG8@bootlin.com>
Hi Luca,
On Fri, Mar 27, 2026 at 03:46:43PM +0100, Luca Ceresoli wrote:
> Hello Liu,
>
> On Thu Mar 26, 2026 at 9:15 AM CET, Liu Ying wrote:
>> Hi Luca,
>>
>> On Fri, Mar 20, 2026 at 11:46:18AM +0100, Luca Ceresoli wrote:
>>> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
>>> can operate in two different modes, depending on the platform data as set
>>> by the driver:
>>>
>>> A. hdmi->plat_data->output_port = 0:
>>> the HDMI output (port@1) in device tree is not used [0]
>>>
>>> B. hdmi->plat_data->output_port = 1:
>>> the HDMI output (port@1) is parsed to find the next bridge
>>>
>>> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
>>> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
>>> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>>>
>>> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
>>> in that case it adds the connector programmatically at bridge attach time.
>>>
>>> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
>>> case B. So, in preparation to support DRM_BRIDGE_ATTACH_NO_CONNECTOR in
>>> imx8mp-hdmi-tx, move to case B by setting hdmi->plat_data->output_port = 1.
>>>
>>> However this change requires that port@1 is connected to a "next
>>> bridge" DT node, typically the HDMI connector, because dw-hdmi won't add
>>> the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>>>
>>> Many dts files for imx8mp-based boards in the kernel have such a connector
>>> described and linked to port@1, so a connector is added by the
>>> display-connector driver along with a bridge wrapping it. Sadly some of
>>
>> Hmm, display-connector driver is a bridge driver so it cannot add a connector.
>> I assume that you mean a connector will be added by the bridge connector
>> driver.
>
> Indeed, rewording as:
>
> Many dts files for imx8mp-based boards in the kernel have such a
> connector described and linked to port@1, so the pipeline will be fully
> attached up to a display-connector and a drm_connector added by the
> bridge-connector.
LGTM.
>
>>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>>> Choose this to enable support for the internal HDMI encoder found
>>> on the i.MX8MP SoC.
>>>
>>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>>> + bool "Support device tree blobs without an hdmi-connector node"
>>> + default y
>>
>> depends on DRM_IMX_LCDIF ?
>
> If the imx hdmi-tx is not enabled then HDMI won't work anyway, so users are
> not affected and the overlay is not needed. Am I missing something?
I meant I'm fine with "default y" and think that this could also depend on
DRM_IMX_LCDIF, because no display controller driver other than the LCDIF
driver needs the fixup.
[...]
>>> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>>> new file mode 100644
>>> index 000000000000..ee718ca1b11b
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>>> @@ -0,0 +1,38 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
>>> + *
>>> + * Copyright (C) 2026 GE HealthCare
>>> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>> + */
>>> +
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +&{/} {
>>
>> I see build warnings(W=1):
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:25.8-37.4: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0: node has a unit name, but no reg or ranges property
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:26.16-36.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000: node has a unit name, but no reg or ranges property
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:27.18-35.6: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000: node has a unit name, but no reg or ranges property
>> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:29.13-33.8: Warning (unit_address_vs_reg): /fragment@0/__overlay__/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1: node has a unit name, but no reg or ranges property
>
> AFAIK the device tree checkes just can't work on overlays. The tools just
> cannot know on which base tree the overlay can be applied, so they cannot
> know the existing properties. That might change in the future, but for now
> my understanding is that it is OK to have overlays which produce such
> harmless warnings, at least for driver-specific overlays like the tilcdc
> one [0] which is already in linux-next since a few weeks.
Hmm, not sure a few weeks in linux-next is long enough ;)
I'd say, I saw the warnings, so simply reported along with a fix to suppress
them. TBH, build warnings make me nervous, especially this DT overlay is
under the "DRM DRIVERS FOR FREESCALE IMX BRIDGE" umbrella.
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0ff223d991477fa4677dcb0f1fb00065847e2212
>
>> Here is a patch to suppress them:
>>
>> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
>> @@ -10,6 +10,9 @@
>> /plugin/;
>>
>> &{/} {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> fixup-hdmi-connector {
>> compatible = "hdmi-connector";
>> label = "HDMI";
>> @@ -23,10 +26,25 @@ fixup_hdmi_connector_in: endpoint {
>> };
>>
>> soc@0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x0 0x0 0x3e000000>;
>> +
>> bus@32c00000 {
>> + reg = <0x32c00000 0x400000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> hdmi@32fd8000 {
>> + reg = <0x32fd8000 0x7eff>;
>> +
>> ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> port@1 {
>> + reg = <1>;
>> +
>> hdmi_tx_out: endpoint {
>> remote-endpoint = <&fixup_hdmi_connector_in>;
>> };
>
> Thanks for taking time to look into how to get rid of the warnings.
>
> However the sheer amount of lines added, by just duplicating lines already
> in the base tree and no added value, reinforces my opinion that we should
> keep the overlay as simple as it is.
>
> Also, what if one of the property values that your diff is duplicating from
> the base tree turns out being wrong in the base tree and gets fixed later
> there? The wrong value would be re-added by the overlay unless someone goes
> hunting all the duplicated lines around.
>
> Based on this, do you think we really need to get rid of those warnings?
Well, I tend to get rid of those warning, because it seems that people
usually avoid this kind of warnings for regular DT overlays, but I might
be wrong.
>
> Side note: this discussion made me think about what would happen if
> DRM_IMX8MP_DW_HDMI_BRIDGE is enabled on a non-imx8mp board (as for
> distribution kernels as mentioned by Laurent). I think it makes sense to
> add a check that /soc@0/compatible matches "fsl,imx8mp-soc" and not apply
> the overlay otherwise. I'll look into that for v2.
Makes sense to me.
>
>>> + fixup-hdmi-connector {
>>> + compatible = "hdmi-connector";
>>> + label = "HDMI";
>>> + type = "a";
>>
>> What if a board uses another type?
>
> For boards affected by this patch, currently the connector is created by
> dw_hdmi_connector_create() which hardcodes type A [0], so there would be no
> difference.
Yes, that's from driver's PoV. However, userspace may get the type
from /sys/firmware/devicetree/base/fixup-hdmi-connector/type and use it
to do something.
Maybe, that's trivial.
>
> OTOH how can a common module know the specific connector?
Hmm, maybe add a module parameter or let users set the type through Kconfig
or even define an unknown type to honestly tell users that we don't know it?
>
> Boards with a different connector should describe the connector in the
> device tree, if they need to instantiate the exact type.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
>
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: kaanapali: Add SoCCP for Kaanapali SoC
From: Jingyi Wang @ 2026-03-30 2:53 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
devicetree, linux-kernel, 20260310-knp-soccp-v4-0-0a91575e0e7e
In-Reply-To: <ac75a339-ca20-4264-9295-d7290e218bc5@oss.qualcomm.com>
On 3/27/2026 5:52 PM, Konrad Dybcio wrote:
> On 3/27/26 4:20 AM, Jingyi Wang wrote:
>> Add remoteproc PAS loader for SoCCP with its SMP2P. On Kaanapali, it
>> is brought up by bootloader, so set the status "okay".
>
> Simply remove it, "okay" is the default if the property is absent
>
> [...]
>
well noted
>> + remoteproc_soccp: remoteproc-soccp@d00000 {
>
> -> remoteproc@
well noted
>
> Konrad
Thanks,
Jingyi
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Jingyi Wang @ 2026-03-30 2:52 UTC (permalink / raw)
To: Krishna Kurapati, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja
In-Reply-To: <20260329175249.2946508-2-krishna.kurapati@oss.qualcomm.com>
On 3/30/2026 1:52 AM, Krishna Kurapati wrote:
> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>
> Add the base USB devicetree definitions for Kaanapali platform. The overall
> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
> (rev. v8) and M31 eUSB2 PHY.
>
> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 154 ++++++++++++++++++++++++
> 1 file changed, 154 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index ac6a6c789902..08d7c1a1d829 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> @@ -6026,6 +6026,160 @@ pdp_tx: scp-sram-section@100 {
> reg = <0x100 0x80>;
> };
> };
> +
> + usb_hsphy: phy@88e3000 {
> + compatible = "qcom,kaanapali-m31-eusb2-phy",
> + "qcom,sm8750-m31-eusb2-phy";
> + reg = <0x0 0x88e3000 0x0 0x29c>;
> +
> + clocks = <&tcsr TCSR_USB2_CLKREF_EN>;
> + clock-names = "ref";
> +
> + resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
> +
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> + usb_dp_qmpphy: phy@88e8000 {
> + compatible = "qcom,kaanapali-qmp-usb3-dp-phy",
> + "qcom,sm8750-qmp-usb3-dp-phy";
> + reg = <0x0 0x088e8000 0x0 0x4000>;
> +
> + clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
> + <&tcsr TCSR_USB3_CLKREF_EN>,
> + <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
> + <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
> + clock-names = "aux",
> + "ref",
> + "com_aux",
> + "usb3_pipe";
> +
> + resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
> + <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
> + reset-names = "phy",
> + "common";
> +
> + power-domains = <&gcc GCC_USB3_PHY_GDSC>;
> +
> + #clock-cells = <1>;
> + #phy-cells = <1>;
> +
> + orientation-switch;
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb_dp_qmpphy_out: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_dp_qmpphy_usb_ss_in: endpoint {
> + remote-endpoint = <&usb_dwc3_ss>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + usb_dp_qmpphy_dp_in: endpoint {
> + };
> + };
> + };
> + };
> +
> + usb: usb@a600000 {
> + compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
> + reg = <0x0 0x0a600000 0x0 0xfc100>;
> +
> + clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
> + <&gcc GCC_USB30_PRIM_MASTER_CLK>,
> + <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
> + <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
> + <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>;
> + clock-names = "cfg_noc",
> + "core",
> + "iface",
> + "sleep",
> + "mock_utmi";
> +
> + assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
> + <&gcc GCC_USB30_PRIM_MASTER_CLK>;
> + assigned-clock-rates = <19200000>, <200000000>;
> +
> + interrupts-extended = <&intc GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
> + <&intc GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
> + <&intc GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
> + <&pdc 14 IRQ_TYPE_EDGE_BOTH>,
> + <&pdc 15 IRQ_TYPE_EDGE_BOTH>,
> + <&pdc 17 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "dwc_usb3",
> + "pwr_event",
> + "hs_phy_irq",
> + "dp_hs_phy_irq",
> + "dm_hs_phy_irq",
> + "ss_phy_irq";
> +
> + power-domains = <&gcc GCC_USB30_PRIM_GDSC>;
> + required-opps = <&rpmhpd_opp_nom>;
> +
> + resets = <&gcc GCC_USB30_PRIM_BCR>;
> +
> + interconnects = <&aggre_noc MASTER_USB3 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc SLAVE_USB3 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "usb-ddr", "apps-usb";
> + iommus = <&apps_smmu 0x40 0x0>;
> +
> + phys = <&usb_hsphy>, <&usb_dp_qmpphy QMP_USB43DP_USB3_PHY>;
> + phy-names = "usb2-phy", "usb3-phy";
> +
> + snps,hird-threshold = /bits/ 8 <0x0>;
> + snps,usb2-gadget-lpm-disable;
> + snps,dis_u2_susphy_quirk;
> + snps,dis_enblslpm_quirk;
> + snps,dis-u1-entry-quirk;
> + snps,dis-u2-entry-quirk;
> + snps,is-utmi-l1-suspend;
> + snps,usb3_lpm_capable;
> + snps,usb2-lpm-disable;
> + snps,has-lpm-erratum;
> + tx-fifo-resize;
> + dma-coherent;
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + usb_dwc3_hs: endpoint {
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + usb_dwc3_ss: endpoint {
> + remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
> + };
> + };
> + };
> + };
please make sure the nodes are sorted in address order.
Thanks,
Jingyi
> };
>
> thermal-zones {
^ permalink raw reply
* RE: [PATCH v5 01/10] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller
From: Yu-Chun Lin [林祐君] @ 2026-03-30 2:48 UTC (permalink / raw)
To: Stephen Boyd, afaerber@suse.com, conor+dt@kernel.org,
Edgar Lee [李承諭],
Jyan Chou [周芷安], krzk+dt@kernel.org,
mturquette@baylibre.com, p.zabel@pengutronix.de, robh@kernel.org
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <177440394165.5403.17868576455504268400@localhost.localdomain>
> Quoting Yu-Chun Lin (2026-03-23 19:53:22)
> > diff --git
> > a/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > new file mode 100644
> > index 000000000000..6fabc2da3975
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/realtek,rtd1625-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Realtek RTD1625 Clock & Reset Controller
> > +
> > +maintainers:
> > + - Yu-Chun Lin <eleanor.lin@realtek.com>
> > +
> > +description: |
> > + The Realtek RTD1625 Clock Controller manages and distributes clock
> > + signals to various controllers and implements a Reset Controller
> > +for the
> > + SoC peripherals.
> > +
> > + Clocks and resets are referenced by unique identifiers, which are
> > + defined as preprocessor macros in
> > + include/dt-bindings/clock/realtek,rtd1625-clk.h and
> include/dt-bindings/reset/realtek,rtd1625.h.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - realtek,rtd1625-crt-clk
> > + - realtek,rtd1625-iso-clk
> > + - realtek,rtd1625-iso-s-clk
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + "#clock-cells":
> > + const: 1
> > +
> > + "#reset-cells":
> > + const: 1
>
> Are there any input clks for the clk tree?
>
We don't dynamically calculate frequencies based on an input clock.
Since all of our current SoCs use a fixed 27MHz oscillator, we use
predefined lookup tables in the driver for the target frequencies instead.
Nevertheless, to properly describe the hardware layout, I will add the clock
properties in the bindings and DTS in v6.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#clock-cells"
> > + - "#reset-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + clock-controller@98000000 {
> > + compatible = "realtek,rtd1625-crt-clk";
> > + reg = <98000000 0x1000>;
>
> Should be 0x98000000 to match the unit address.
>
Ack.
Best Regards,
Yu-Chun
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Add RK3562 serial aliases
From: 谢致邦 (XIE Zhibang) @ 2026-03-30 2:46 UTC (permalink / raw)
To: krzk
Cc: Yeking, conor+dt, devicetree, finley.xiao, heiko, kever.yang,
krzk+dt, linux-arm-kernel, linux-kernel, linux-rockchip, robh
In-Reply-To: <9b3ee9e9-d44d-49b1-81ac-9c3806dc0efb@kernel.org>
On Sat, Mar 28, 2026 at 04:08:57PM +0100, Krzysztof Kozlowski wrote:
> On 28/03/2026 14:05, 谢致邦 (XIE Zhibang) wrote:
> > This fixes the stdout-path in rk3562-evb2-v10.dts.
> >
> > Fixes: ceb6ef1ea900 ("arm64: dts: rockchip: Add RK3562 evb2 devicetree")
> > Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3562.dtsi | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3562.dtsi b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > index e4816aa3dae0..14e74e8ac7df 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3562.dtsi
> > @@ -26,6 +26,16 @@ aliases {
> > gpio2 = &gpio2;
> > gpio3 = &gpio3;
> > gpio4 = &gpio4;
> > + serial0 = &uart0;
> > + serial1 = &uart1;
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + serial4 = &uart4;
> > + serial5 = &uart5;
> > + serial6 = &uart6;
> > + serial7 = &uart7;
> > + serial8 = &uart8;
> > + serial9 = &uart9;
>
> UART aliases are properties of the boards, not SoC.
>
> Best regards,
> Krzysztof
So are you saying that we need to remove the serial aliases from files
like rk3308.dtsi, rk3328.dtsi, rk3368.dtsi, rk3399-base.dtsi,
rk356x-base.dtsi, rk3576.dtsi, rk3588-base.dtsi, and so on?
Kind regards,
XIE Zhibang
^ permalink raw reply
* Re: [PATCH v2 4/7] pwm: tegra: Parametrize enable register offset
From: Mikko Perttunen @ 2026-03-30 2:24 UTC (permalink / raw)
To: Thierry Reding
Cc: Mikko Perttunen, Thierry Reding, Uwe Kleine-König,
Jonathan Hunter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pwm, linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <acT_nz0TRM4yXwkb@orome>
On 2026-03-26 10:47 +0100, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 07:17:02PM +0900, Mikko Perttunen wrote:
> > On Tegra264, the PWM enablement bit is not located at the base address
> > of the PWM controller. Hence, introduce an enablement offset field in
> > the tegra_pwm_soc structure to describe the offset of the register.
> >
> > Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
> > Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
> > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > ---
> > drivers/pwm/pwm-tegra.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
> > index cf54f75d92a5..22d709986e8c 100644
> > --- a/drivers/pwm/pwm-tegra.c
> > +++ b/drivers/pwm/pwm-tegra.c
> > @@ -61,6 +61,7 @@
> >
> > struct tegra_pwm_soc {
> > unsigned int num_channels;
> > + unsigned int enable_reg;
> > };
> >
> > struct tegra_pwm_chip {
> > @@ -197,8 +198,9 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > err = pm_runtime_resume_and_get(pwmchip_parent(chip));
> > if (err)
> > return err;
> > - } else
> > + } else if (pc->soc->enable_reg == PWM_CSR_0) {
> > val |= PWM_ENABLE;
> > + }
>
> This looks incomplete for the Tegra264 case where
>
> pc->soc->enable_reg == PWM_CSR_1
>
> >
> > pwm_writel(pwm, PWM_CSR_0, val);
>
> I think we need another write for PWM_CSR_1 here to properly toggle the
> PWM_ENABLE bit on Tegra264.
>
> Or am I missing something?
This check is here just so we don't change the value of PWM_ENABLE when
writing the CSR_0 register. The function doesn't write to CSR_1 so
nothing needs to be done on Tegra264.
I agree it's not the clearest, but it'll get cleaned up when adding
support for configurable depth, as at that point we will need to write
both registers on Tegra264.
>
> Thierry
^ permalink raw reply
* Re: [PATCH v3 5/6] PCI: tegra: Add Tegra264 support
From: Mikko Perttunen @ 2026-03-30 2:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jon Hunter, Mikko Perttunen, linux-pci, devicetree,
linux-tegra
In-Reply-To: <20260326135855.2795149-6-thierry.reding@kernel.org>
On Thu, 26 Mar 2026 14:58:52 +0100, Thierry Reding <thierry.reding@kernel.org> wrote:
> diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> new file mode 100644
> index 000000000000..21872797e41a
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-tegra264.c
> @@ -0,0 +1,522 @@
> [ ... skip 137 lines ... ]
> +
> + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> +
> + bw = width * (PCIE_SPEED2MBS_ENC(pcie_link_speed[speed]));
Nit: this now has unnecessary double parentheses.
--
^ permalink raw reply
* Re: [PATCH v3 0/6] PCI: tegra: Add Tegra264 support
From: Mikko Perttunen @ 2026-03-30 2:17 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jon Hunter, Mikko Perttunen, linux-pci, devicetree,
linux-tegra
In-Reply-To: <20260326135855.2795149-1-thierry.reding@kernel.org>
On Thu, 26 Mar 2026 14:58:47 +0100, Thierry Reding <thierry.reding@kernel.org> wrote:
> [...]
> 16 files changed, 4629 insertions(+), 955 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> create mode 100644 drivers/pci/controller/pcie-tegra264.c
>
> --
> 2.52.0
Thank you! Works nicely.
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Mikko Perttunen <mperttunen@nvidia.com>
--
^ permalink raw reply
* [PATCH v2 1/1] arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
From: Ziyue Zhang @ 2026-03-30 2:09 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, ziyue.zhang,
jingoohan1, mani, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
Historically, the Qualcomm PCIe controller node (Host bridge) described
all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide
a more accurate hardware description and to support future multi-Root Port
controllers, these properties were moved to the Root Port node in the
devicetree bindings.
Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
initiated this transition for the Hamoa platform by moving the PHY
property to the Root Port node in hamoa.dtsi. However, it only updated
some platform specific DTS files for PERST# and WAKE#, leaving others in
a "mixed" binding state.
While the PCIe controller driver supports both legacy and Root Port
bindings, It cannot correctly handle a mix of both. In these cases, the
driver parses the PHY from the Root Port node, but fails to find the
PERST# property (which it then assumes is not present, as it is optional).
Consequently, the controller probe succeeds, but PERST# remains
uncontrolled, preventing PCIe endpoints from functioning.
So, fix the incomplete migration by moving the PERST# and WAKE# properties
from the controller node to the Root Port node in all remaining Hamoa
platform DTS files.
Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
---
.../boot/dts/qcom/x1-asus-zenbook-a14.dtsi | 16 ++++++++-----
arch/arm64/boot/dts/qcom/x1-crd.dtsi | 24 ++++++++++++-------
arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi | 14 ++++++-----
.../boot/dts/qcom/x1-hp-omnibook-x14.dtsi | 14 ++++++-----
.../boot/dts/qcom/x1-microsoft-denali.dtsi | 8 ++++---
.../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 6 ++---
.../qcom/x1e80100-medion-sprchrgd-14-s1.dts | 14 +++++------
.../dts/qcom/x1p42100-lenovo-thinkbook-16.dts | 14 ++++++-----
8 files changed, 64 insertions(+), 46 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
index cd062f844b2d..66d566808f58 100644
--- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
@@ -1079,9 +1079,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1095,10 +1092,12 @@ &pcie4_phy {
status = "okay";
};
-&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+};
+&pcie6a {
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1114,6 +1113,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
index 485dcd946757..a9c5c523575e 100644
--- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
@@ -1248,15 +1248,17 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
status = "okay";
};
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+};
+
&pcie4_phy {
vdda-phy-supply = <&vreg_l3i_0p8>;
vdda-pll-supply = <&vreg_l3e_1p2>;
@@ -1265,9 +1267,6 @@ &pcie4_phy {
};
&pcie5 {
- perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_wwan>;
pinctrl-0 = <&pcie5_default>;
@@ -1283,10 +1282,12 @@ &pcie5_phy {
status = "okay";
};
-&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+&pcie5_port0 {
+ reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+};
+&pcie6a {
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-names = "default";
@@ -1302,6 +1303,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
kypd_vol_up_n: kypd-vol-up-n-state {
pins = "gpio6";
diff --git a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
index 343844cc62f2..0d9a324cc6cc 100644
--- a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
@@ -1081,9 +1081,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1098,6 +1095,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1115,9 +1115,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1126,6 +1123,11 @@ &pcie6a {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pcie6a_phy {
vdda-phy-supply = <&vreg_l1d_0p8>;
vdda-pll-supply = <&vreg_l2j_1p2>;
diff --git a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
index 16437139d336..b773a4976d1b 100644
--- a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
@@ -1065,9 +1065,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1082,6 +1079,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1099,9 +1099,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1110,6 +1107,11 @@ &pcie6a {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pcie6a_phy {
vdda-phy-supply = <&vreg_l1d_0p8>;
vdda-pll-supply = <&vreg_l2j_1p2>;
diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
index 6ab595b6ea30..dd2de1f723b0 100644
--- a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
@@ -964,9 +964,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -982,6 +979,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
index bd0e3009fb41..beb1475d7fa0 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
@@ -1126,9 +1126,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1143,6 +1140,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
index 763efb9e070d..23a298248a29 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
@@ -1033,9 +1033,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1050,6 +1047,8 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1067,10 +1066,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1086,6 +1081,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
index ab309d547ed5..500809772097 100644
--- a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
+++ b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
@@ -1131,9 +1131,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1148,6 +1145,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1165,9 +1165,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1183,6 +1180,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_pwm {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: display: bridge: ldb: Require reg property only for i.MX6SX/8MP LDBs
From: Liu Ying @ 2026-03-30 2:05 UTC (permalink / raw)
To: Marco Felsch
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Laurentiu Palcu,
dri-devel, devicetree, linux-kernel
In-Reply-To: <crqzju5cqhvmy5msxvuquydmnpb2ft2t3gsyr6qsre6ccqjvzz@46gfcrelczsr>
On Sun, Mar 29, 2026 at 07:42:23PM +0200, Marco Felsch wrote:
> Hi Liu,
Hi Marco,
>
> sorry for not writting back earlier, the last weeks were quite busy.
>
> On 26-03-29, Liu Ying wrote:
>> LDB's parent device could be a syscon which doesn't allow a reg property
>> to be present in it's child devices, e.g., NXP i.MX93 Media blk-ctrl
>> has a child device NXP i.MX93 Parallel Display Format Configuration(PDFC)
>> without a reg property(LDB is also a child device of the Media blk-ctrl).
>> To make the LDB schema be able to describe LDBs without the reg property
>> like i.MX93 LDB, require the reg property only for i.MX6SX/8MP LDBs.
>
> NACK, we want to describe the HW and from HW PoV the LDB is and was
> always part of a syscon. This is the case for all SoCs i.MX6SX/8MP/93.
The reality is that i.MX6SX and i.MX8MP LDB DT nodes are already in-tree.
People may take them as ABI(not only for Linux, but also for other
potential projects which use the LDB schema and/or the DT nodes).
>
>> Fixes: 8aa2f0ac08d3 ("dt-bindings: display: bridge: ldb: Add check for reg and reg-names")
>
> Therefore I would just revert this patch completely.
IMHO, it doesn't make too much difference between my patch and reverting
this offending patch, because of the ABI, i.e., the reg properties in
i.MX6SX and i.MX8MP LDB DT nodes are supposed to be stable.
I feel that what you are asking for is even more than simply reverting
this offending patch, that is to say, completely disallowing the reg and
reg-names properties for LDBs across all SoCs. But again, that would
break the ABI.
>
> Regards,
> Marco
>
>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>> ---
>> .../bindings/display/bridge/fsl,ldb.yaml | 23 ++++++++++++++++------
>> 1 file changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>> index 7f380879fffd..5f6dc2b11d7b 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml
>> @@ -28,6 +28,7 @@ properties:
>> const: ldb
>>
>> reg:
>> + minItems: 1
>> maxItems: 2
>>
>> reg-names:
>> @@ -68,7 +69,6 @@ required:
>> - compatible
>> - clocks
>> - ports
>> - - reg
>>
>> allOf:
>> - if:
>> @@ -83,12 +83,23 @@ allOf:
>> ports:
>> properties:
>> port@2: false
>> +
>> - if:
>> - not:
>> - properties:
>> - compatible:
>> - contains:
>> - const: fsl,imx6sx-ldb
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - fsl,imx6sx-ldb
>> + - fsl,imx8mp-ldb
>> + then:
>> + required:
>> + - reg
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: fsl,imx8mp-ldb
>> then:
>> required:
>> - reg-names
>>
>> ---
>> base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
>> change-id: 20260329-fsl_ldb_schema_fix-4fe01c42bff3
>>
>> Best regards,
>> --
>> Liu Ying <victor.liu@nxp.com>
>>
>>
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
From: Chaoyi Chen @ 2026-03-30 1:34 UTC (permalink / raw)
To: Sebastian Reichel, Sandy Huang, Heiko Stübner, Andy Yan,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Damon Ding, Dmitry Baryshkov, Alexey Charkov, dri-devel,
linux-rockchip, linux-kernel, devicetree, kernel
In-Reply-To: <20260326-synopsys-dw-dp-improvements-v1-0-501849162290@collabora.com>
Hello Sebastian,
On 3/27/2026 1:31 AM, Sebastian Reichel wrote:
> This patch series updates the Synopsys Designware DisplayPort bridge
> together with the only existing user: The Rockchip RK3576/RK3588:
>
> 1. follow-up bridges (PHY, USB-C connector)
> this is needed to get USB-C DP AltMode working; I've followed the
> Qualcomm driver as reference
>
> 2. runtime PM
> the initial driver has been upstreamed without RPM; add it to
> avoid wasting power when nothing is plugged
>
> 3. audio
> the initial driver has been upstreamed without audio support;
> this adds all missing bits for audio with single stream transport
>
> The series is based on drm-misc-next with Cristian's cleanup series
> applied as I expect that to land first:
>
> https://lore.kernel.org/linux-rockchip/20260310-drm-rk-fixes-v2-0-645ecfb43f49@collabora.com/
>
> To properly make use of the bridge code the following USBDP PHY series
> is also needed:
>
> https://lore.kernel.org/linux-rockchip/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com/
>
> There are two parts, which possibly need some discussion:
>
> 1. I added a dedicated bridge callback for out-of-band hotplug events,
> which is separate from the hotplug_notify. I have a feeling, that
> there might be a better solution, but haven't found it.
>
Could you explain what an out-of-band hotplug event is?
Can't the drivers/usb/typec/altmodes/displayport.c respond to these
hot-plug events? Thank you.
> 2. The DT binding for audio support - explicitly marked as RFC - works
> perfectly fine, but is not ready for MST. I don't intend to
> implement that right now, but the binding should obviously take it
> into consideration to avoid breaking it in the future. I've put
> some points for discussion into the relevant patch.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> Sebastian Reichel (10):
> drm/bridge: synopsys: dw-dp: Simplify driver data setting
> drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED
> drm/bridge: synopsys: dw-dp: Add follow-up bridge support
> drm/bridge: Add out-of-band HPD notify handler
> drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD
> drm/rockchip: dw_dp: Implement out-of-band HPD handling
> drm/bridge: synopsys: dw-dp: Add Runtime PM support
> drm/rockchip: dw_dp: Add runtime PM support
> [RFC] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells
> drm/bridge: synopsys: dw-dp: Add audio support
>
> .../bindings/display/rockchip/rockchip,dw-dp.yaml | 5 +-
> drivers/gpu/drm/bridge/synopsys/dw-dp.c | 284 ++++++++++++++++++++-
> drivers/gpu/drm/display/drm_bridge_connector.c | 6 +
> drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 167 +++++++++++-
> include/drm/bridge/dw_dp.h | 6 +
> include/drm/drm_bridge.h | 14 +
> 6 files changed, 469 insertions(+), 13 deletions(-)
> ---
> base-commit: 0660ee19141e5e90b422b7daa0d8518a8d0d898b
> change-id: 20260325-synopsys-dw-dp-improvements-7da2e98df1dd
>
> Best regards,
--
Best,
Chaoyi
^ permalink raw reply
* Re: [PATCH 4/8] drm/bridge: dw-hdmi: document the output_port field
From: Damon Ding @ 2026-03-30 1:13 UTC (permalink / raw)
To: Luca Ceresoli, Liu Ying, Marek Vasut, Stefan Agner,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Rob Herring,
Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <DHDIOSVSDG9W.B7BW87297KT3@bootlin.com>
On 3/27/2026 7:10 PM, Luca Ceresoli wrote:
> Hello Damon,
>
> On Thu Mar 26, 2026 at 10:15 AM CET, Damon Ding wrote:
>> On 3/26/2026 3:25 PM, Liu Ying wrote:
>>> Hi Luca,
>>>
>>> On Fri, Mar 20, 2026 at 11:46:15AM +0100, Luca Ceresoli wrote:
>>>> The meaning of this flag may not be obvious at first sight.
>>>>
>>>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>>>> ---
>>>> include/drm/bridge/dw_hdmi.h | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>
>> First of all, these changes related to the DW HDMI controller work well
>> when tested on RK3399 HDMI.
>
> Great!
>
> You'd be welcome to send your Tested-by: tag if you tested the series on
> hardware, that would be useful.
>
> However at this point I suggest to wait for v2, which I'm sending soon, and
> test that. I added you in Cc for it.
>
>>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>>>> index 336f062e1f9d..45f6ba1a8ee1 100644
>>>> --- a/include/drm/bridge/dw_hdmi.h
>>>> +++ b/include/drm/bridge/dw_hdmi.h
>>>> @@ -126,6 +126,11 @@ struct dw_hdmi_phy_ops {
>>>> struct dw_hdmi_plat_data {
>>>> struct regmap *regm;
>>>>
>>>> + /*
>>>> + * The HDMI output port number (which must be 1) if it is described
>>>
>>> I'd rephrase:
>>> The HDMI output port number must be 1 ...
>>>
>>
>> Yes, the output port number should be 1, but I found that the output
>> port number in the Rockchip-side dw-hdmi driver remains 0.
>
> Really? I checked all the bindings in
> Documentation/devicetree/bindings/display/rockchip/*hdmi* and all mention
> port@1 as the output port number. Can you point to code using port@0 as the
> output port?
>
> Should it be true, that would be unfortunate because the output_port
> variable does not handle this case. It's used as a sort of bool-or-int
> variable:
>
> * as a bool [0] to find out whether the DT is supposed to describe the
> output port
> * as an integer to tell the port number to parse in DT [1]
>
> So saying "please parse port 0" is impossible.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
> [1] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3315
>
Aha, my description might be a little misleading. The
&dw_hdmi_plat_data.output_port is 0 on the Rockchip side, so the next
bridge will not be parsed for it.
Then I think the &dw_hdmi_plat_data.output_port should be 1, as this
helps support the hdmi-connector and other bridge chips.
>> Therefore, it may be better to adapt the dw-hdmi drivers across all
>> platforms to the bridge-connector architecture simultaneously.
>>
>> This would allow removing &dw_hdmi_plat_data.output_port and unify the
>> setting of DRM_BRIDGE_ATTACH_NO_CONNECTOR during the attach stage.
>> (Just as the Analogix DP driver does [0])
>>
>> [0]
>> https://lore.kernel.org/all/20260319071452.1961274-1-damon.ding@rock-chips.com/
>
> I agree converting all users is a good goal, but I disagree it should be
> done simultaneously. There are various users of dw-hdmi, and converting one
> having the hardware to test it was painful enough for me. Converting all of
> them without testing on hardware would be a hell.
>
> However I might be wrong. Having a precise list of all users, which ones
> need to be converted, and whether they have any special detail to be taken
> care of would be good to estimate the work to convert all users. Without
> that I'd rather let users convert one by one and hopefully get rid of
> legacy code eventually.
>
Yes, I've noticed that there are quite a few drivers associated with the
DW HDMI controller. It would be a better idea to let users handle this
themselves.
BTW: The Rockchip side dw-hdmi patches for bridge connector support will
be updated as a follow-up to your patch series. :-)
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v3 2/3] riscv: dts: spacemit: Define the P1 PMIC regulators for OrangePi RV2
From: Yixun Lan @ 2026-03-30 0:31 UTC (permalink / raw)
To: Han Gao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, devicetree,
linux-riscv, spacemit, linux-kernel, Han Gao
In-Reply-To: <492e0bea0fb84f49f4bead3dc3d563b13d98df11.1774803532.git.gaohan@iscas.ac.cn>
Hi Han,
On 01:05 Mon 30 Mar , Han Gao wrote:
> Define the DC power input and the 4v power as fixed regulator supplies.
>
> Define the SpacemiT P1 PMIC voltage regulators and their constraints.
>
..
> The power management hardware design on the OrangePi RV2 is identical to
> the Banana Pi BPI-F3, so the DT Nodes were taken from k1-bananapi-f3.dts.
I'd suggest to drop above comment, it's vague and even not a direct reason..
>
> Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
> ---
> .../boot/dts/spacemit/k1-orangepi-rv2.dts | 137 ++++++++++++++++++
> 1 file changed, 137 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
> index 93880ba7bdfe..1b1b27bc95d8 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
> @@ -23,6 +23,25 @@ chosen {
> stdout-path = "serial0";
> };
>
..
> + reg_dc_in: regulator-vcc-in-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_in_5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
This regulator can be dropped, it's not used by *device*, take a look at Krzysztof's comment
https://lore.kernel.org/all/6530526f-59ca-4753-a068-46c62a1a1fed@kernel.org
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v4 0/5] Add initial Milk-V Duo S board support
From: Michael Opdenacker @ 2026-03-29 21:14 UTC (permalink / raw)
To: Joshua Milas, tglx, robh, krzk+dt, conor+dt, pjw, samuel.holland,
unicorn_wang, inochiama, daniel.lezcano, palmer, aou, alex,
liujingqi, alexander.sverdlin, rabenda.cn, dlan, chao.wei, anup
Cc: michael.opdenacker, linux-kernel, devicetree, linux-riscv, sophgo,
hanguidong02
In-Reply-To: <20260328173450.219664-1-josh.milas@gmail.com>
Hi Joshua
On 3/28/26 6:34 PM, Joshua Milas wrote:
> This adds an initial device tree for the Milk-V Duo S board
> with support for reading from the SD card and network over
> Ethernet. This is continued work from Michael Opdenacker's
> v6 series [1] on the ARM64 and RISCV side. It has been tested
> with ARM64 and RISCV64 to boot from an SD card, have networking,
> and read I2C slave devices over i2c4.
I could test successfully on RISC-V, booting from MMC on a command line
shell, and testing i2c4. However, I have an issue with Ethernet. When I
add "ip=172.24.0.2" (for example) to the kernel command line, I'm
getting this:
[ 2.586984] stmmaceth 4070000.ethernet eth0: Register
MEM_TYPE_PAGE_POOL RxQ-0
[ 2.596428] stmmaceth 4070000.ethernet eth0: cannot attach to PHY
(error: -ENODEV)
[ 2.627351] IP-Config: Failed to open eth0
[ 2.631859] IP-Config: No network devices available
However, "eth0" appears in the list of networking devices.
Does this work on your side?
Cheers
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
^ permalink raw reply
* Re: [PATCH net-next v5 00/14] macb usrio/tsu patches
From: patchwork-bot+netdevbpf @ 2026-03-29 21:40 UTC (permalink / raw)
To: Conor Dooley
Cc: netdev, conor.dooley, Valentina.FernandezAlanis, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
daire.mcnamara, pjw, palmer, aou, alex, nicolas.ferre,
claudiu.beznea, richardcochran, samuel.holland, devicetree,
linux-kernel, linux-riscv, dave.stevenson, sean.anderson,
vineeth.karumanchi, abin.joseph, theo.lebrun, Ryan.Wanner,
haokexin
In-Reply-To: <20260325-unsterile-flail-4c7729750dc4@spud>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 16:28:04 +0000 you wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> Hey folks,
>
> At the very least, it'd be good of the soc vendor folks could check
> their platforms and see if their usrio stuff actually lines up with what
> the driver currently calls "macb_default_usrio". Ours didn't and it was
> a nasty surprise.
>
> [...]
Here is the summary with links:
- [net-next,v5,01/14] Revert "net: macb: Clean up the .usrio settings in macb_config instances"
https://git.kernel.org/netdev/net-next/c/8ccf062c6770
- [net-next,v5,02/14] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio
https://git.kernel.org/netdev/net-next/c/a17871778ee2
- [net-next,v5,03/14] net: macb: split USRIO_HAS_CLKEN capability in two
https://git.kernel.org/netdev/net-next/c/039f185a0060
- [net-next,v5,04/14] dt-bindings: net: cdns,macb: replace cdns,refclk-ext with cdns,refclk-source
https://git.kernel.org/netdev/net-next/c/dfa36d7e860c
- [net-next,v5,05/14] net: macb: rework usrio refclk selection code
https://git.kernel.org/netdev/net-next/c/6c5b565d7d41
- [net-next,v5,06/14] net: macb: np4 doesn't need a usrio pointer
https://git.kernel.org/netdev/net-next/c/826cbe636e10
- [net-next,v5,07/14] net: macb: add mpfs specific usrio configuration
https://git.kernel.org/netdev/net-next/c/c711311d6ba3
- [net-next,v5,08/14] net: macb: warn on pclk use as a tsu_clk fallback
https://git.kernel.org/netdev/net-next/c/3fe13d858f83
- [net-next,v5,09/14] net: macb: clean up tsu clk rate acquisition
https://git.kernel.org/netdev/net-next/c/b698a1e397ab
- [net-next,v5,10/14] dt-bindings: net: macb: add property indicating timer adjust mode
https://git.kernel.org/netdev/net-next/c/09a6164a4f1d
- [net-next,v5,11/14] net: macb: timer adjust mode is not supported
https://git.kernel.org/netdev/net-next/c/41adda8764fd
- [net-next,v5,12/14] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED
https://git.kernel.org/netdev/net-next/c/47c86c463612
- [net-next,v5,13/14] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided
https://git.kernel.org/netdev/net-next/c/32fc6a9f6e75
- [net-next,v5,14/14] net: macb: drop usrio pointer on EyeQ5 config
https://git.kernel.org/netdev/net-next/c/cd1082a96f9a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 2/5] arm64: dts: sophgo: add initial Milk-V Duo S board support
From: Michael Opdenacker @ 2026-03-29 20:21 UTC (permalink / raw)
To: Joshua Milas, tglx, robh, krzk+dt, conor+dt, pjw, samuel.holland,
unicorn_wang, inochiama, daniel.lezcano, palmer, aou, alex,
liujingqi, alexander.sverdlin, rabenda.cn, dlan, chao.wei, anup
Cc: michael.opdenacker, linux-kernel, devicetree, linux-riscv, sophgo,
hanguidong02
In-Reply-To: <20260328173450.219664-3-josh.milas@gmail.com>
Hi Joshua
Thanks a lot for this new update!
On 3/28/26 6:34 PM, Joshua Milas wrote:
> Adds initial arm64 support for the Milk-V Duo S board
> [1] making it possible to boot Linux to the command line.
>
> Link: https://milkv.io/duo-s [1]
>
> Signed-off-by: Joshua Milas <josh.milas@gmail.com>
...
> diff --git a/arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts b/arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts
> new file mode 100644
> index 0000000000000..4ae44b40f9edb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts
...
> +
> +&usb {
> + dr_mode = "host";
> + status = "okay";
> +};
You have a small checkpatch.pl issue here:
./scripts/checkpatch.pl *.patch
...
WARNING: please, no spaces at the start of a line
#120: FILE: arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts:82:
+ dr_mode = "host";$
WARNING: please, no spaces at the start of a line
#121: FILE: arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts:83:
+ status = "okay";$
Replace the spaces by a tab as in the other entries in the DTS and you
should be fine.
Thanks again
Cheers
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: gemini: Rename power controller node to gemini-poweroff
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260329205151.15161-1-khushalchitturi@gmail.com>
Update the node name for the Cortina Gemini power controller from
power-controller to gemini-poweroff since node "power controller" is
reserved for power domain controller.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
index befe322bd7de..c524adadcf81 100644
--- a/arch/arm/boot/dts/gemini/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini/gemini.dtsi
@@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
#interrupt-cells = <2>;
};
- power-controller@4b000000 {
+ gemini-poweroff@4b000000 {
compatible = "cortina,gemini-power-controller";
reg = <0x4b000000 0x100>;
interrupts = <26 IRQ_TYPE_EDGE_RISING>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
In-Reply-To: <20260329205151.15161-1-khushalchitturi@gmail.com>
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema.
Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
---
Changelog:
v1 -> v2:
- Renamed the node from power-controller to gemini-poweroff to resolve dtschema warnings.
Note:
* This patch series is part of the GSoC2026 application process for device tree bindings conversions
* https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
2 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
new file mode 100644
index 000000000000..8fbe7e952b25
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems Gemini Poweroff Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that
+ controls system power-down operations.
+
+properties:
+ compatible:
+ const: cortina,gemini-power-controller
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gemini-poweroff@4b000000 {
+ compatible = "cortina,gemini-power-controller";
+ reg = <0x4b000000 0x100>;
+ interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
deleted file mode 100644
index 7fec3e100214..000000000000
--- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-* Device-Tree bindings for Cortina Systems Gemini Poweroff
-
-This is a special IP block in the Cortina Gemini SoC that only
-deals with different ways to power the system down.
-
-Required properties:
-- compatible: should be "cortina,gemini-power-controller"
-- reg: should contain the physical memory base and size
-- interrupts: should contain the power management interrupt
-
-Example:
-
-power-controller@4b000000 {
- compatible = "cortina,gemini-power-controller";
- reg = <0x4b000000 0x100>;
- interrupts = <26 IRQ_TYPE_EDGE_FALLING>;
-};
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] dt-bindings: power: reset: cortina: Convert to DT schema and rename node
From: Khushal Chitturi @ 2026-03-29 20:51 UTC (permalink / raw)
To: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
devicetree, linux-arm-kernel, linux-kernel, Khushal Chitturi
Convert the Cortina Systems Gemini Poweroff Controller bindings to
DT schema and update corresponding dtsi file with new node name
---
Khushal Chitturi (2):
dt-bindings: power: reset: cortina,gemini-power-controller: convert to
DT schema
ARM: dts: gemini: Rename power controller node to gemini-poweroff
.../cortina,gemini-power-controller.yaml | 42 +++++++++++++++++++
.../bindings/power/reset/gemini-poweroff.txt | 17 --------
arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
3 files changed, 43 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt
--
2.53.0
^ permalink raw reply
* [PATCH] arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
From: Erikas Bitovtas @ 2026-03-29 23:37 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming, phone-devel, Erikas Bitovtas
VCNL4000 includes support for regulators. Add regulators listed in the
downstream device tree so they can be powered in during initialization.
VLED supply is missing downstream, so it will be powered on by a dummy.
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
---
arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light
and proximity sensor.
This patch series describes regulators needed for the ambient light and
proximity sensor.
In the patch series which added the ambient light and proximity sensor
for this device, regulators were missing, as they were not yet supported
by the sensor's device tree binding. Missing regulators for the ambient
light and proximity sensor resulted in it not powering on when a
regulator supplied only the ambient light and proximity sensor. In Asus
ZenFone 2 Laser case, the regulators were shared with the panel and
magnetometer, so it was not affected by this bug. However, for the sake
of completeness of the binding, we add the neccessary regulators anyway.
The mainline binding for the sensor also includes vled-supply, however,
in downstream, it is missing, and we have no datasheet for the device,
so for now, we'll have it being supplied by a dummy.
---
arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
index 1a340fa92755..90e966242720 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-asus-z00t.dts
@@ -154,6 +154,9 @@ light-sensor@60 {
interrupts-extended = <&tlmm 113 IRQ_TYPE_EDGE_FALLING>;
proximity-near-level = <30>;
+ vdd-supply = <&pm8916_l8>;
+ vio-supply = <&pm8916_l6>;
+
pinctrl-0 = <&light_int_default>;
pinctrl-names = "default";
};
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260325-z00t-cm36686-regulators-8f138d47090c
Best regards,
--
Erikas Bitovtas <xerikasxx@gmail.com>
^ permalink raw reply related
* Re: [PATCH net-next v2 9/9] net: dsa: lan9645x: add port statistics
From: Jakub Kicinski @ 2026-03-29 19:56 UTC (permalink / raw)
To: jensemil.schulzostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260324-dsa_lan9645x_switch_driver_base-v2-9-f7504e3b0681@microchip.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: lan9645x: add port statistics
Add statistics support for the port counters. Chip registers are 32 bit,
so this unit is responsible maintaining a 64bit software cache, and
updating it frequently to handle overflows in hardware.
> diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> index 24a60f40f6b8..9a46c08dad59 100644
> --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
[ ... ]
> @@ -262,6 +264,12 @@ static int lan9645x_setup(struct dsa_switch *ds)
> if (!lan9645x->owq)
> return -ENOMEM;
>
> + err = lan9645x_stats_init(lan9645x);
> + if (err) {
> + dev_err(dev, "Failed to init stats.\n");
> + goto owq_destroy;
> + }
> +
[ ... ]
> diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> index 000000000000..3e82a859f173
> --- /dev/null
> +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
[ ... ]
> +static const struct lan9645x_ethtool_stat lan9645x_port_ethtool_stats[] = {
> + { "rx_uc", SCNT_RX_UC },
> + { "rx_cat_drop", SCNT_RX_CAT_DROP },
[ ... ]
> + { "tx_uc", SCNT_TX_UC },
> + { "tx_drop", SCNT_TX_DROP },
[ ... ]
> +};
Is it necessary to duplicate standard networking statistics in the driver
private ethtool output?
The networking subsystem guidelines state that stats possessing a standard UAPI
representation, such as tx_dropped and rx_packets in struct rtnl_link_stats64,
should not be duplicated in the ethtool -S output.
Could these redundant strings be removed since the driver natively supports
them via lan9645x_stats_get_stats64?
[ ... ]
> +static const struct lan9645x_view_stats lan9645x_view_stat_cfgs[] = {
> + [LAN9645X_STAT_PORTS] = {
> + .name = "ports",
> + .type = LAN9645X_STAT_PORTS,
> + .layout = lan9645x_port_stats_layout,
> + .num_cnts = ARRAY_SIZE(lan9645x_port_stats_layout),
> + .num_indexes = NUM_PHYS_PORTS,
> + },
> +};
[ ... ]
> +static u64 *lan9645x_stats_view_idx_update(struct lan9645x *lan9645x,
> + enum lan9645x_view_stat_type vtype,
> + int idx)
> +{
> + struct lan9645x_stats *s = lan9645x->stats;
> +
> + mutex_lock(&s->hw_lock);
> + __lan9645x_stats_view_idx_update(lan9645x, vtype, idx);
> + mutex_unlock(&s->hw_lock);
> +
> + return STAT_COUNTERS(lan9645x, vtype, idx);
> +}
Does this code overflow the allocated buffer when called for the CPU port?
The stats buffer cnts is allocated using num_indexes, which is NUM_PHYS_PORTS
(9). This covers ports 0 to 8. However, the CPU port is defined as index 9
(CPU_PORT = 9).
When the DSA core invokes stat callbacks like get_ethtool_stats or get_stats64
for the CPU port, the idx argument is 9. While the helper
__lan9645x_stats_view_idx_update skips the hardware read for out-of-bounds
indices, lan9645x_stats_view_idx_update ignores that failure and returns the
result of STAT_COUNTERS(lan9645x, vtype, idx).
This computes a pointer past the end of the cnts array, which the callers then
blindly dereference, potentially leaking kernel memory or causing a crash. Can
bounds checking be added to the callers, or should the buffer be sized to
include the CPU port?
[ ... ]
> +void lan9645x_stats_get_ethtool_stats(struct lan9645x *lan9645x, int port,
> + u64 *data)
> +{
> + struct lan9645x_stats *stats = lan9645x->stats;
> + u64 *c;
> + int i;
> +
> + c = lan9645x_stats_view_idx_update(lan9645x, LAN9645X_STAT_PORTS, port);
> +
> + spin_lock(&stats->sw_lock);
> + for (i = 0; i < ARRAY_SIZE(lan9645x_port_ethtool_stats); i++)
> + *data++ = c[lan9645x_port_ethtool_stats[i].idx];
> + spin_unlock(&stats->sw_lock);
> +}
[ ... ]
> +/* Called in atomic context */
> +void lan9645x_stats_get_stats64(struct lan9645x *lan9645x, int port,
> + struct rtnl_link_stats64 *stats)
> +{
> + struct lan9645x_stats *s = lan9645x->stats;
> + u64 *c;
> +
> + c = STAT_COUNTERS(lan9645x, LAN9645X_STAT_PORTS, port);
> +
> + spin_lock(&s->sw_lock);
Can this code deadlock when a softirq interrupts a process holding the lock?
The sw_lock spinlock protects the 64-bit software stats counters. In
lan9645x_stats_get_stats64, which acts as the ndo_get_stats64 callback, this
lock is acquired using a plain spin_lock. The code comment notes this function
is called in atomic context (such as from NET_RX_SOFTIRQ via dev_get_stats).
Concurrently, process context paths like lan9645x_stats_get_ethtool_stats and
lan9645x_check_stats_work also acquire sw_lock using plain spin_lock. Because
plain spin_lock does not disable softirqs, if a softirq preempts the execution
on a CPU while process context holds sw_lock, the softirq will spin
indefinitely waiting for the lock.
Should the process-context acquisitions use spin_lock_bh instead?
[ ... ]
> +int lan9645x_stats_init(struct lan9645x *lan9645x)
> +{
> + const struct lan9645x_view_stats *vs;
> + struct lan9645x_stats *stats;
> + int err, i;
> +
> + lan9645x->stats = devm_kzalloc(lan9645x->dev, sizeof(*stats),
> + GFP_KERNEL);
Will this memory be leaked when the DSA switch unbinds and rebinds?
The lan9645x_stats_init function allocates lan9645x->stats, vstat->cnts, and
vstat->buf using devm_kzalloc and devm_kcalloc. This function is called from
lan9645x_setup, which is the DSA .setup callback.
The DSA tree lifecycle is independent of the platform device lifecycle. If the
master netdevice is unbound and bound again, the DSA switch's .teardown and
.setup callbacks will be invoked multiple times. Because .teardown cannot free
devres-managed memory, the memory tied to the platform device will be leaked
on every setup cycle until the switch's platform device itself is destroyed.
Could this use standard kzalloc allocations paired with kfree in teardown?
^ 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