* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-04-08 7:18 UTC (permalink / raw)
To: Rob Herring
Cc: Jeremy Kerr, Krzysztof Kozlowski,
andriy.shevchenko@linux.intel.com, Andi Shyti,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260407204402.GA3641251-robh@kernel.org>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> On Tue, Mar 31, 2026 at 07:30:58AM +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> > > global-regs and enable-dma properties
> > >
> > > Hi Ryan,
> > >
> > > > > Sounds reasonable, but before you do so, how are you planning to
> > > > > manage the allocation of DMA channels across multiple i2c
> peripherals?
> > > > >
> > > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > > To avoid the complexity of managing DMA channel contention, I plan
> > > > to use buffer mode by default for all controllers, which still
> > > > provides better performance than byte mode without requiring DMA
> > > > channel
> > > allocation.
> > >
> > > OK, but your wording there ("by default") implies that DMA is still
> > > selectable for one controller peripheral. In which case: you still
> > > have the problem of managing DMA channel contention, but now it's at
> runtime instead.
> > >
> > > So my question still stands: how are you planning to enforce that
> > > DMA is only enabled for one controller?
> > >
> > > Or are you planning to disable I2C DMA entirely on AST2600?
> > Yes, This is my intent to do.
> > Disable I2C DMA entirely on AST2600.
> > If I remove DMA, should can I keep byte and buffer for sysfs?
>
> 28 versions and it's still not clear when you need what mode. Sigh. The only
> thing better about sysfs then it's not my problem, but that really doesn't sound
> much better.
>
> DMA is only going to be useful for transfers above a certain size. If you are
> doing the typical SMBus style register accesses, then DMA is completely
> useless. The setup DMA overhead is going to be greater than just directly
> reading/writing the I2C controller FIFOs.
Sorry, why you think DMA overhead is greater than read/write FIFO?
When enable DMA, all dma allocate will be initial in probe.
And the DMA mode data is going to dram, that will be read/write data from
dram. Compare with buffer mode, data is from FIFO register to read/write.
So DMA will not have overhead.
> What's the size that makes DMA
> useful? 16, 32, 64 bytes?
The i2c ast2600 can be 4096 byte for each tx/rx dma,
buffer mode is 32byte (16 byte for TX, 16 byte for RX).
>Something greater than the max size in buffer mode
> probably. Really, provide some data that DMA gives better performance
> and/or less CPU usage.
In general i2c transfer len < buffer size. dma did not gain.
But if large than buffer size (16 byte), it will reduce the cpu interrupt latency.
For example, mctp transfer :
https://github.com/torvalds/linux/blob/master/drivers/net/mctp/mctp-i2c.c#L29
mctp max len is 256, that will 1 interrupt for each package transfer.
But in fifo mode will be 256/16 = 16 interrupts.
Compare the smbus I2C_SMBUS_BLOCK_MAX is 32 byte + 2
https://github.com/torvalds/linux/blob/master/include/uapi/linux/i2c.h#L145
That is only (32 + 2)/16 = 2~3 interrupts. It may not gain more.
>If you set some minimum size and request DMA only
> above that size, is there really that much contention?
Sorry, I don't know your point here, could you give more your statement?
> If there's some specific
> device that really needs DMA, then make that device's driver request it and
> reserve it.
>
> For byte mode, there's not a clear need nor description of why. Someone once
> long ago asked for it... Who cares, if they really want it, then the issue needs to
> be described. If a certain device requires certain timing that byte mode
> provides, then that should be some property the driver for the device
> communicates to the controller. No need for DT nor sysfs in that case.
>
I agree with your point.
My proposal will remove byte mode. And keep dma/buffer. And remove sysfs for
transfer mode selection, default will be buffer mode. And keep properties
aspeed,enable-dma, which indicate the channel have DMA capability to use.
And if dts add aspeed,enable-dma, the i2c will use DMA otherwise will keep buffer
transfer, is it ok?
^ permalink raw reply
* Re: [PATCH v4 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Krzysztof Kozlowski @ 2026-04-08 7:14 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, broonie, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, perex, tiwai, shenghao-ding, kevin-lu, baojun.xu,
niranjan.hy, l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <20260408053149.1369350-3-sen@ti.com>
On Wed, Apr 08, 2026 at 12:31:46AM -0500, Sen Wang wrote:
> +static const struct dev_pm_ops tas675x_pm_ops = {
> + SYSTEM_SLEEP_PM_OPS(tas675x_system_suspend, tas675x_system_resume)
> + RUNTIME_PM_OPS(tas675x_runtime_suspend, tas675x_runtime_resume, NULL)
> +};
> +
> +static const struct of_device_id tas675x_of_match[] = {
> + { .compatible = "ti,tas6754", .data = (void *)TAS6754 },
Drop. This is the entire point of compatibility.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v21 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Laurentiu Palcu @ 2026-04-08 7:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: imx, Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, dri-devel, Alexander Stein,
Dmitry Baryshkov, Ying Liu, devicetree, linux-kernel
In-Reply-To: <20260408-large-marigold-pheasant-bef65f@quoll>
On Wed, Apr 08, 2026 at 08:42:09AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 02:31:27PM +0000, Laurentiu Palcu wrote:
> > From: Sandor Yu <Sandor.yu@nxp.com>
> >
> > Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
> >
> > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> > ---
> > .../bindings/display/bridge/cdns,mhdp8501.yaml | 131 +++++++++++++++++++++
> > 1 file changed, 131 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> > new file mode 100644
> > index 0000000000000..77e16ee9d855d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> > @@ -0,0 +1,131 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Cadence MHDP8501 DP/HDMI bridge
> > +
> > +maintainers:
> > + - Sandor Yu <Sandor.yu@nxp.com>
> > +
> > +description:
> > + Cadence MHDP8501 DisplayPort/HDMI interface.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - fsl,imx8mq-mhdp8501
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > + description: MHDP8501 DP/HDMI APB clock.
> > +
> > + phys:
> > + maxItems: 1
> > + description:
> > + phandle to the DP/HDMI PHY
> > +
> > + interrupts:
> > + items:
> > + - description: Hotplug cable plugin.
> > + - description: Hotplug cable plugout.
> > +
> > + interrupt-names:
> > + items:
> > + - const: plug_in
> > + - const: plug_out
> > +
> > + cdns,bridge-type:
>
> Drop property. Graph defines what is connected on the other side. And if
> this is for different devices then compatible tells what bridge is that.
Initially, Sandor did use the remote compatible to decide the bridge
type but he assumed the remote is always the connector. However, as
Dmitry pointed out [1], this is not reliable as we can have another bridge
in-between this one and the connector.
[1] https://lore.kernel.org/all/dpj333mzr5azqhrgw3cxd7x5kiwxms4iomwy74uqfhr2zu4ocr@36rkth27d2jc/
--
Thanks,
Laurentiu
^ permalink raw reply
* Re: [PATCH v4 1/4] ASoC: dt-bindings: Add ti,tas67524
From: Krzysztof Kozlowski @ 2026-04-08 7:13 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, broonie, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, perex, tiwai, shenghao-ding, kevin-lu, baojun.xu,
niranjan.hy, l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <20260408053149.1369350-2-sen@ti.com>
On Wed, Apr 08, 2026 at 12:31:45AM -0500, Sen Wang wrote:
> Add device tree binding for the Texas Instruments TAS67524 family
> of four-channel Class-D audio amplifiers with integrated DSP.
>
> Signed-off-by: Sen Wang <sen@ti.com>
> ---
> Changes in v4:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 05/14] net: enetc: add support for the "Add" operation to VLAN filter table
From: Wei Fang @ 2026-04-08 7:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011729.1795413-1-kuba@kernel.org>
> > diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c
> b/drivers/net/ethernet/freescale/enetc/ntmp.c
> > --- a/drivers/net/ethernet/freescale/enetc/ntmp.c
> > +++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
>
> [ ... ]
>
> > @@ -652,5 +655,52 @@ int ntmp_fdbt_search_port_entry(struct ntmp_user
> *user, int port,
> > +int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
> > + const struct vft_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct vft_req_ua),
> > + };
> > + struct vft_req_ua *req;
> > + union netc_cbd cbd;
> > + u32 len;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + /* Request data */
> > + ntmp_fill_crd(&req->crd, user->tbl.vft_ver, 0,
> > + NTMP_GEN_UA_CFGEU);
> > + req->ak.exact.vid = cpu_to_le16(vid);
> > + req->cfge = *cfge;
> > +
> > + /* Request header */
> > + len = NTMP_LEN(data.size, NTMP_STATUS_RESP_LEN);
> > + ntmp_fill_request_hdr(&cbd, data.dma, len, NTMP_VFT_ID,
> > + NTMP_CMD_ADD, NTMP_AM_EXACT_KEY);
> > +
> > + err = netc_xmit_ntmp_cmd(user, &cbd);
> > + if (err)
> > + dev_err(user->dev,
> > + "Failed to add %s entry, vid: %u, err: %pe\n",
> > + ntmp_table_name(NTMP_VFT_ID), vid, ERR_PTR(err));
> > +
> > + ntmp_free_data_mem(&data);
>
> Does this code safely handle hardware timeouts?
>
> If netc_xmit_ntmp_cmd() times out and returns an error, the pending
> transaction is not explicitly aborted before ntmp_free_data_mem()
> unconditionally frees the DMA buffer.
>
> Could the hardware eventually process the pending command and perform a
> DMA write of the response to the physical address of the freed buffer?
>
> This might lead to silent memory corruption if that memory has already
> been reallocated to another subsystem. Would it be safer to explicitly
> abort the pending DMA transaction, reset the device on timeout, or
> intentionally delay freeing the buffer until it is proven safe?
This is indeed a potential issue, I will add a patch to fix it.
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: display: panel: Add ChipWealth CH13726A AMOLED driver
From: Krzysztof Kozlowski @ 2026-04-08 7:09 UTC (permalink / raw)
To: Aaron Kling
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, dri-devel, devicetree,
linux-kernel, Teguh Sobirin
In-Reply-To: <20260408-ch13726a-v4-1-9bb1a9b8f329@gmail.com>
On Wed, Apr 08, 2026 at 12:32:39AM -0500, Aaron Kling wrote:
> The Chip Wealth Technology CH13726A AMOLED driver is a single chip
> solution for MIPI-DSI. This is used for the AYN Thor bottom panel.
>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> .../display/panel/chipwealth,ch13726a.yaml | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: perf: marvell: Add CN20K DDR PMU binding
From: Krzysztof Kozlowski @ 2026-04-08 7:09 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260407153511.4250-2-gakula@marvell.com>
On Tue, Apr 07, 2026 at 09:05:10PM +0530, Geetha sowjanya wrote:
> Marvell CN20K SoCs integrate a DDR Performance Monitoring Unit (PMU)
> associated with the DDR controller. The block provides hardware counters
> to monitor DDR traffic and performance events and is accessed via a
> dedicated MMIO region.
>
> The CN20K DDR PMU is functionally equivalent to the CN10K DDR PMU, with
> minor register offset differences. This binding documents the CN20K
> variant and introduces a specific compatible string to allow software
> to distinguish between the two implementations.
Drop last sentence, I already asked for that.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr-pmu.yaml | 39 +++++++++++++++++++
Still wrong filename.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:07 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <1ef8adf850f2fd41b6c4e3c89e4f4e6e0f469a0e.1775559102.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 01:42:33PM +0200, Nora Schiffer wrote:
> The J722S WIZ is mostly identical to the AM64's, but additionally supports
> SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:06 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <b67c8b0bc9cc918667e9329d79f617d033d025d5.1775559102.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 01:42:34PM +0200, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++--------
> 1 file changed, 14 insertions(+), 9 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Krzysztof Kozlowski @ 2026-04-08 7:06 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux
In-Reply-To: <191e9f7e3a6c14eabe891a98c5fb646766479c0a.1775558273.git.nora.schiffer@ew.tq-group.com>
On Tue, Apr 07, 2026 at 12:48:01PM +0200, Nora Schiffer wrote:
> The J722S CPSW3G is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
>
> v2: keep ti,am642-cpsw-nuss as a fallback
> v3: resubmission for net-next, no changes
> v4: remove redundant items: level
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 04/14] net: enetc: add basic operations to the FDB table
From: Wei Fang @ 2026-04-08 7:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011727.1795379-1-kuba@kernel.org>
> > @@ -116,6 +158,31 @@ static inline int ntmp_rsst_query_entry(struct
> ntmp_user *user,
> > return 0;
> > }
> >
> > +static inline int ntmp_fdbt_add_entry(struct ntmp_user *user, u32 *entry_id,
> > + const struct fdbt_keye_data *keye,
> > + const struct fdbt_cfge_data *data)
> > +{
> > + return 0;
> > +}
>
> If CONFIG_NXP_NETC_LIB is disabled, will returning 0 here cause callers to
> falsely assume the operation succeeded and proceed to use an uninitialized
> entry_id pointer? Would it be safer to return an error code such as
> -EOPNOTSUPP for stubs that have output parameters?
>
The ntmp_fdbt_add_entry() is only called by the netc switch driver,
and the driver will select CONFIG_NXP_NETC_LIB option, so actually
this inline function is not used by any drivers. I suppose such inline
functions could be removed. Thanks.
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: reduce SG2042 MSI count to 16
From: Chen Wang @ 2026-04-08 7:04 UTC (permalink / raw)
To: Icenowy Zheng, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Inochi Amaoto, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: Han Gao, Zixian Zeng, Manivannan Sadhasivam, devicetree, sophgo,
linux-riscv, linux-kernel
In-Reply-To: <20260407160143.1182430-1-zhengxingda@iscas.ac.cn>
On 4/8/2026 12:01 AM, Icenowy Zheng wrote:
> The SG2042 MSI controller has one 32-bit doorbell register, and each bit
> corresponds to an interrupt. At a glance, it seems that the MSI
> controller can support 32 interrupts; however the PCI MSI capability
> only supports 16-bit messages, which makes the high 16 interrupts
> unusable in such way.
>
> Reduce the MSI count to 16 to prevent producing MSI message values that
> cannot fit 16-bit integers.
>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
> arch/riscv/boot/dts/sophgo/sg2042.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/boot/dts/sophgo/sg2042.dtsi b/arch/riscv/boot/dts/sophgo/sg2042.dtsi
> index 9fddf3f0b3b99..9f1820a7b5a9f 100644
> --- a/arch/riscv/boot/dts/sophgo/sg2042.dtsi
> +++ b/arch/riscv/boot/dts/sophgo/sg2042.dtsi
> @@ -234,7 +234,7 @@ msi: msi-controller@7030010304 {
> reg-names = "clr", "doorbell";
> msi-controller;
> #msi-cells = <0>;
> - msi-ranges = <&intc 64 IRQ_TYPE_EDGE_RISING 32>;
> + msi-ranges = <&intc 64 IRQ_TYPE_EDGE_RISING 16>;
> };
>
> rpgate: clock-controller@7030010368 {
LGTM.
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Tested-by: Chen Wang <unicorn_wang@outlook.com> on Pioneerbox.
Thanks,
Chen
Hi, Han,
Will you please run some quick test on EVB boards, I have no such
hardware in hand, thanks.
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
From: Krzysztof Kozlowski @ 2026-04-08 6:59 UTC (permalink / raw)
To: David Heidelberg
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio, Paul Sajna,
Baochen Qiang, Vasanthakumar Thiagarajan, Dmitry Baryshkov,
Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260407-skip-host-cam-qmi-req-v5-1-dfa8a05c6538@ixit.cz>
On Tue, Apr 07, 2026 at 08:43:54AM +0200, David Heidelberg wrote:
> From: Amit Pundir <amit.pundir@linaro.org>
>
> Some firmware versions do not support the host-capability QMI request.
> Since this request occurs before firmware and board files are loaded,
> the quirk cannot be expressed in the firmware itself and must be described
> in the device tree.
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Co-developed-by: David Heidelberg <david@ixit.cz>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 03/14] net: enetc: add pre-boot initialization for i.MX94 switch
From: Wei Fang @ 2026-04-08 6:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011723.1795349-1-kuba@kernel.org>
> > +static int imx94_switch_link_config(struct netc_blk_ctrl *priv,
> > + struct device_node *np,
> > + bool *swp2_en)
> > +{
> > + struct device_node *ports;
> > + int port_id, err = 0;
>
> Since of_property_read_u32() expects a u32 pointer, does passing a
> signed int pointer here trigger an incompatible pointer types warning
> during compilation?
>
Okay, I will change port_id to u32 type.
> > +
> > + ports = netc_get_switch_ports(np);
> > + if (!ports)
> > + return -ENODEV;
> > +
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + if (of_property_read_u32(child, "reg", &port_id) < 0) {
>
> If the device tree provides a reg value with the MSB set, port_id
> would be evaluated as a negative number.
>
> [ ... ]
> > static int imx94_netcmix_init(struct platform_device *pdev)
> > {
> > struct netc_blk_ctrl *priv = platform_get_drvdata(pdev);
> > struct device_node *np = pdev->dev.of_node;
> > + bool enetc0_en = false, swp2_en = false;
> > u32 val;
> > int err;
> >
> > for_each_child_of_node_scoped(np, child) {
> > for_each_child_of_node_scoped(child, gchild) {
> > - if (!of_device_is_compatible(gchild, "pci1131,e101"))
> > - continue;
> > -
> > - err = imx94_enetc_link_config(priv, gchild);
> > - if (err)
> > - return err;
> > + if (of_device_is_compatible(gchild, "pci1131,e101")) {
> > + err = imx94_enetc_link_config(priv, gchild,
> > + &enetc0_en);
> > + if (err)
> > + return err;
> > + } else if (of_device_is_compatible(gchild,
> > + "pci1131,eef2")) {
>
> Is it possible for the switch node to be disabled in the device tree?
>
> If so, should we check of_device_is_available() for gchild before proceeding,
> similar to how it is checked for enetc0_en?
The switch may be owned by a guest OS, in this case, the switch node of the
host OS will be disabled, but we still hope that the host OS could do some
configurations for the switch, as the netc_blk_ctrl is owned by host OS, so
we cannot check of_device_is_available() for the switch node.
>
> Without checking availability, if the disabled switch lacks a ports subnode,
> imx94_switch_link_config() might return -ENODEV and abort the entire probe.
This is the expected behavior, only one of swp2 and enetc0 can be enabled,
as they share the same parallel interface. If all of them are enabled, the driver
will detect this incorrect DTS configuration and return a failure.
> Alternatively, if the disabled switch node has a ports subnode with an
> available port 2, it could spuriously set swp2_en = true and cause a false
> conflict with ENETC 0.
>
> > + err = imx94_switch_link_config(priv, gchild,
> > + &swp2_en);
> > + if (err)
> > + return err;
> > + }
> > }
> > }
^ permalink raw reply
* [PATCH v3] leds: rgb: lp5860: add enable-gpio
From: Steffen Trumtrar @ 2026-04-08 6:51 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Steffen Trumtrar
Cc: linux-leds, devicetree, linux-kernel, Steffen Trumtrar
The VIO_EN pin can either be connected with VIO power supply or GPIO.
Get the GPIO from DT if provided and set it on chip enable and disable.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Changes in v3:
- remove unnecessary validation checks
- update dep to newer lp5860 series
- Link to v2: https://lore.kernel.org/r/20260310-v6-19-topic-ti-lp5860-enable-gpio-v2-0-3fcc617fe03a@pengutronix.de
Changes in v2:
- add acked-by
- updated deps to newer lp5860 series
- rebased to v7.0-rc1
- Link to v1: https://lore.kernel.org/r/20260217-v6-19-topic-ti-lp5860-enable-gpio-v1-0-f5e8edeb5d74@pengutronix.de
---
drivers/leds/rgb/leds-lp5860-core.c | 9 +++++++++
drivers/leds/rgb/leds-lp5860.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/leds/rgb/leds-lp5860-core.c b/drivers/leds/rgb/leds-lp5860-core.c
index 31eebaf0269ab..5bccca47b20a1 100644
--- a/drivers/leds/rgb/leds-lp5860-core.c
+++ b/drivers/leds/rgb/leds-lp5860-core.c
@@ -5,6 +5,7 @@
* Author: Steffen Trumtrar <kernel@pengutronix.de>
*/
+#include <linux/gpio/consumer.h>
#include <linux/led-class-multicolor.h>
#include <linux/module.h>
#include <linux/of_platform.h>
@@ -59,6 +60,8 @@ static int lp5860_set_mc_brightness(struct led_classdev *cdev,
static int lp5860_chip_enable(struct lp5860 *lp, bool enable)
{
+ gpiod_direction_output(lp->enable_gpiod, enable);
+
return regmap_write(lp->regmap, LP5860_REG_CHIP_EN, enable);
}
@@ -189,6 +192,12 @@ int lp5860_device_init(struct device *dev)
struct lp5860 *lp = dev_get_drvdata(dev);
int ret;
+ lp->enable_gpiod = devm_gpiod_get_optional(lp->dev, "enable", GPIOD_ASIS);
+ if (IS_ERR(lp->enable_gpiod))
+ return PTR_ERR(lp->enable_gpiod);
+
+ gpiod_set_consumer_name(lp->enable_gpiod, "LP5860 VIO enable");
+
ret = lp5860_chip_enable(lp, LP5860_CHIP_ENABLE);
if (ret)
return ret;
diff --git a/drivers/leds/rgb/leds-lp5860.h b/drivers/leds/rgb/leds-lp5860.h
index b3ad8c46720cd..48a6afc4227d6 100644
--- a/drivers/leds/rgb/leds-lp5860.h
+++ b/drivers/leds/rgb/leds-lp5860.h
@@ -257,6 +257,7 @@ struct lp5860_led {
struct lp5860 {
struct device *dev;
struct regmap *regmap;
+ struct gpio_desc *enable_gpiod;
unsigned int leds_count;
DECLARE_FLEX_ARRAY(struct lp5860_led, leds);
---
base-commit: 559f264e403e4d58d56a17595c60a1de011c5e20
change-id: 20260217-v6-19-topic-ti-lp5860-enable-gpio-83c0652d34ad
prerequisite-message-id: <20260403-v6-14-topic-ti-lp5860-v8-1-e127e80e875a@pengutronix.de>
prerequisite-patch-id: 2fc7123c98bf6c53d946af75269ecb1a7b421f14
Best regards,
--
Steffen Trumtrar <s.trumtrar@pengutronix.de>
^ permalink raw reply related
* Re: [PATCH v6 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Krzysztof Kozlowski @ 2026-04-08 6:49 UTC (permalink / raw)
To: Iker Pedrosa
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Troy Mitchell, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel
In-Reply-To: <20260407-orangepi-sd-card-uhs-v6-1-b5b8a1b2bfc8@gmail.com>
On Tue, Apr 07, 2026 at 10:25:21AM +0200, Iker Pedrosa wrote:
> Document pinctrl properties to support voltage-dependent pin
> configuration switching for UHS-I SD card modes.
>
> Add optional pinctrl-names property with two states:
> - "default": For 3.3V operation with standard drive strength
> - "state_uhs": For 1.8V operation with optimized drive strength
>
> These pinctrl states allow the SDHCI driver to coordinate voltage
> switching with pin configuration changes, ensuring proper signal
> integrity during UHS-I mode transitions.
>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> ---
> .../devicetree/bindings/mmc/spacemit,sdhci.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> index 9a055d963a7f0cdba4741c1e3e7269688dcd5f45..932fccc609bf8dbaf3ecfe09d9e610852ac7afa0 100644
> --- a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml
> @@ -11,6 +11,7 @@ maintainers:
>
> allOf:
> - $ref: mmc-controller.yaml#
Drop
> + - $ref: sdhci-common.yaml#
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: PCI: Add UltraRISC DP1000 PCIe controller
From: Krzysztof Kozlowski @ 2026-04-08 6:49 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <177563059910.3194559.10112671473525736823.b4-reply@b4>
On 08/04/2026 08:43, Jia Wang wrote:
> On 2026-04-08 08:28 +0200, Krzysztof Kozlowski wrote:
>> On 08/04/2026 05:34, Jia Wang wrote:
>>>>> + max-link-speed:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>> + const: 4
>>>>
>>>> If const then deducible from the compatible. Drop the property.
>>>>
>>>
>>> Will replace `const: 4` with `maximum: 4` in v3.
>>
>> Why? Wasn't maximum link speed fixed to 4?
>>
>
> Just to make sure I fully understand: since the maximum link speed is a
> fixed hardware property and is implied by the compatible, we should drop
> the `max-link-speed` property from the binding.
>
> In that case, should I set `pci->max_link_speed = 4` in the driver during
> probe? I want to make sure this is the correct way to handle it.
>
Yes
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: PCI: Add UltraRISC DP1000 PCIe controller
From: Jia Wang @ 2026-04-08 6:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jia Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <13907c0e-0502-413d-b54d-4e903f5c781e@kernel.org>
On 2026-04-08 08:28 +0200, Krzysztof Kozlowski wrote:
> On 08/04/2026 05:34, Jia Wang wrote:
> >>> + max-link-speed:
> >>> + $ref: /schemas/types.yaml#/definitions/uint32
> >>> + const: 4
> >>
> >> If const then deducible from the compatible. Drop the property.
> >>
> >
> > Will replace `const: 4` with `maximum: 4` in v3.
>
> Why? Wasn't maximum link speed fixed to 4?
>
Just to make sure I fully understand: since the maximum link speed is a
fixed hardware property and is implied by the compatible, we should drop
the `max-link-speed` property from the binding.
In that case, should I set `pci->max_link_speed = 4` in the driver during
probe? I want to make sure this is the correct way to handle it.
>
> Best regards,
> Krzysztof
>
Best regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH v21 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Krzysztof Kozlowski @ 2026-04-08 6:42 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: imx, Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, dri-devel, Alexander Stein,
Dmitry Baryshkov, Ying Liu, devicetree, linux-kernel
In-Reply-To: <20260407-dcss-hdmi-upstreaming-v21-3-4681070ab82f@oss.nxp.com>
On Tue, Apr 07, 2026 at 02:31:27PM +0000, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
>
> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
> .../bindings/display/bridge/cdns,mhdp8501.yaml | 131 +++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> new file mode 100644
> index 0000000000000..77e16ee9d855d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
> @@ -0,0 +1,131 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cadence MHDP8501 DP/HDMI bridge
> +
> +maintainers:
> + - Sandor Yu <Sandor.yu@nxp.com>
> +
> +description:
> + Cadence MHDP8501 DisplayPort/HDMI interface.
> +
> +properties:
> + compatible:
> + enum:
> + - fsl,imx8mq-mhdp8501
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> + description: MHDP8501 DP/HDMI APB clock.
> +
> + phys:
> + maxItems: 1
> + description:
> + phandle to the DP/HDMI PHY
> +
> + interrupts:
> + items:
> + - description: Hotplug cable plugin.
> + - description: Hotplug cable plugout.
> +
> + interrupt-names:
> + items:
> + - const: plug_in
> + - const: plug_out
> +
> + cdns,bridge-type:
Drop property. Graph defines what is connected on the other side. And if
this is for different devices then compatible tells what bridge is that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: dma: arm-dma350: document combined and per-channel IRQ topologies
From: Jun Guo @ 2026-04-08 6:39 UTC (permalink / raw)
To: Rob Herring
Cc: peter.chen, fugang.duan, krzk+dt, conor+dt, vkoul, ychuang3,
schung, robin.murphy, Frank.Li, dmaengine, devicetree,
linux-kernel, cix-kernel-upstream, linux-arm-kernel
In-Reply-To: <20260407172014.GA3090142-robh@kernel.org>
Hi Rob,
Thanks for your review. I have already resubmitted the V6 patch. Please
take a look at the latest v6 patch when you have time, as it includes
considerable changes compared to the v5 version.
On 4/8/2026 1:20 AM, Rob Herring wrote:
> EXTERNAL EMAIL
>
> On Tue, Mar 24, 2026 at 08:01:11PM +0800, Jun Guo wrote:
>> Document the interrupt topologies supported by DMA-350 integration:
>> - one combined interrupt for all channels, or
>> - one interrupt per channel (up to 8 channels).
>>
>> Assisted-by: Cursor:GPT-5.3-Codex
>> Signed-off-by: Jun Guo <jun.guo@cixtech.com>
>> ---
>> .../devicetree/bindings/dma/arm,dma-350.yaml | 25 ++++++++++++-------
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
>> index 429f682f15d8..bec9dc32541b 100644
>> --- a/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
>> +++ b/Documentation/devicetree/bindings/dma/arm,dma-350.yaml
>> @@ -22,15 +22,22 @@ properties:
>>
>> interrupts:
>> minItems: 1
>> - items:
>> - - description: Channel 0 interrupt
>> - - description: Channel 1 interrupt
>> - - description: Channel 2 interrupt
>> - - description: Channel 3 interrupt
>> - - description: Channel 4 interrupt
>> - - description: Channel 5 interrupt
>> - - description: Channel 6 interrupt
>> - - description: Channel 7 interrupt
>> + maxItems: 8
>
> Don't need maxItems
>
>> + description:
>> + Either one interrupt per channel (8 interrupts), or one
>> + combined interrupt for all channels.
>> + oneOf:
>> + - items:
>> + - description: Channel 0 interrupt
>> + - description: Channel 1 interrupt
>> + - description: Channel 2 interrupt
>> + - description: Channel 3 interrupt
>> + - description: Channel 4 interrupt
>> + - description: Channel 5 interrupt
>> + - description: Channel 6 interrupt
>> + - description: Channel 7 interrupt
>> + - items:
>> + - description: Combined interrupt shared by all channels
>>
>> "#dma-cells":
>> const: 1
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v3 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Sandie Cao @ 2026-04-08 6:39 UTC (permalink / raw)
To: Troy Mitchell
Cc: Yixun Lan, Troy Mitchell, Conor Dooley, Emil Renner Berthing,
Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel
In-Reply-To: <DHNJQN4PPTH8.MEVXM2TL2MT7@linux.spacemit.com>
Hi, Troy:
> From: "Troy Mitchell"<troy.mitchell@linux.spacemit.com>
> Date: Wed, Apr 8, 2026, 14:07
> On Tue Apr 7, 2026 at 1:57 PM CST, Sandie Cao wrote:
> > The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
> > SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
> > which has (Framework) SKU FRANHQ0001.
> >
> > The FML13V05 board features:
> > - SpacemiT K3 RISC-V SoC
> > - LPDDR5 16GB or 32GB
> > - eMMC 32GB ~128GB (Optional)
> > - UFS 3.1 256G (Optional)
> > - QSPI Flash
> > - MicroSD Slot
> > - PCIe-based Wi-Fi
> > - 4 USB-C Ports
> > - Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
> > - Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
> > - Port 3 & 4: USB 3.2 Gen 1
> >
> > This minimal device tree enables booting into a serial console with UART
> > output.
> >
> > Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
> > ---
> > arch/riscv/boot/dts/spacemit/Makefile | 1 +
> > .../spacemit/k3-deepcomputing-fml13v05.dts | 31 +++++++++++++++++++
> > 2 files changed, 32 insertions(+)
> > create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> > index 7e2b87702571..acb993c452ba 100644
> > --- a/arch/riscv/boot/dts/spacemit/Makefile
> > +++ b/arch/riscv/boot/dts/spacemit/Makefile
> > @@ -4,4 +4,5 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
> > +dtb-$(CONFIG_ARCH_SPACEMIT) += k3-deepcomputing-fml13v05.dtb
> > dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
> > diff --git a/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
> > new file mode 100644
> > index 000000000000..783066fc7ad7
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
> > @@ -0,0 +1,31 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (C) 2024 DeepComputing (HK) Limited
> ^^^^
> Just like Yixun said, it needs to cover this year.
>
> - Troy
>
Got it. Will change to 2026.
Sandie
^ permalink raw reply
* Re: [PATCH v21 0/8] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
From: Krzysztof Kozlowski @ 2026-04-08 6:38 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: imx, Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
Alexander Stein, Dmitry Baryshkov, Ying Liu, Dmitry Baryshkov,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <20260407-dcss-hdmi-upstreaming-v21-0-4681070ab82f@oss.nxp.com>
On Tue, Apr 07, 2026 at 02:31:24PM +0000, Laurentiu Palcu wrote:
> From: Sandor Yu <Sandor.yu@nxp.com>
>
> Hi,
>
> Since Sandor left NXP some time back, I'll be taking over this patchset
> and continue the upstreaming process from where he left off.
>
> The patchset adds initial support for Cadence MHDP8501(HDMI/DP) DRM bridge
> and Cadence HDP-TX PHY(HDMI/DP) for Freescale i.MX8MQ.
>
> I addressed all remaining reviewers' comments from v20 but I'm not sure
> whether Alexander's issue is still present. Alexander, let me know if
> you're still experiencing a black screen with this patch-set and I'll
> try to address it in the next revision.
>
> --
> Changes in v21:
> - Dropped "phy: Add HDMI configuration options" patch because it was
> already merged separately;
> - Rebased to latest linux-next (7.0-rc6) and fixed all issues
> introduced by API changes in DRM;
> - Addressed Maxime's comment on patch #5 and used debugfs file instead
> of sysfs for printing firmware version;
> - Addressed all Dmitry's comments: handled the
> cdns_mhdp_mailbox_send_recv_multi() error, removed the RGB 10bit
> unused code, added a dts property in order to get the bridge type (I
> couldn't find another way to do it...);
> - Dropped Krzysztof's r-b tag for patch #4 (which is now patch #3)
> since I added a new property;
Whych property? You really are not supposed to add new properties at
v21. This means your binding was incomplete while being discussed for
~20 revisions.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH V11 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-08 6:34 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <lnzprzrdwra7pn7d6m3sbj5pvjy64blwpjl6i3lmlnfbyho63b@czpyhpgz5vum>
> On Tue, Apr 07, 2026 at 06:41:44PM +0800, Sherry Sun wrote:
> > Introduce generic helper functions to parse Root Port device tree
> > nodes and extract common properties like reset GPIOs. This allows
> > multiple PCI host controller drivers to share the same parsing logic.
> >
> > Define struct pci_host_port to hold common Root Port properties
> > (currently only reset GPIO descriptor) and add
> > pci_host_common_parse_ports() to parse Root Port nodes from device
> tree.
> >
> > Also add the 'ports' list to struct pci_host_bridge for better
> > maintain parsed Root Port information.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/pci-host-common.c | 77
> > ++++++++++++++++++++++++ drivers/pci/controller/pci-host-common.h |
> 16 +++++
> > drivers/pci/probe.c | 1 +
> > include/linux/pci.h | 1 +
> > 4 files changed, 95 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pci-host-common.c
> > b/drivers/pci/controller/pci-host-common.c
> > index d6258c1cffe5..0fb6991dde7b 100644
> > --- a/drivers/pci/controller/pci-host-common.c
> > +++ b/drivers/pci/controller/pci-host-common.c
> > @@ -9,6 +9,7 @@
> >
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > +#include <linux/gpio/consumer.h>
> > #include <linux/of.h>
> > #include <linux/of_address.h>
> > #include <linux/of_pci.h>
> > @@ -17,6 +18,82 @@
> >
> > #include "pci-host-common.h"
> >
> > +/**
> > + * pci_host_common_delete_ports - Cleanup function for port list
> > + * @data: Pointer to the port list head */ void
> > +pci_host_common_delete_ports(void *data) {
> > + struct list_head *ports = data;
> > + struct pci_host_port *port, *tmp;
> > +
> > + list_for_each_entry_safe(port, tmp, ports, list)
> > + list_del(&port->list);
> > +}
> > +EXPORT_SYMBOL_GPL(pci_host_common_delete_ports);
> > +
> > +/**
> > + * pci_host_common_parse_port - Parse a single Root Port node
> > + * @dev: Device pointer
> > + * @bridge: PCI host bridge
> > + * @node: Device tree node of the Root Port
> > + *
> > + * Returns: 0 on success, negative error code on failure */ static
> > +int pci_host_common_parse_port(struct device *dev,
> > + struct pci_host_bridge *bridge,
> > + struct device_node *node)
> > +{
> > + struct pci_host_port *port;
> > + struct gpio_desc *reset;
> > +
> > + reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > + "reset", GPIOD_ASIS, "PERST#");
>
> Sorry, I missed this earlier.
>
> Since PERST# is optional, you cannot reliably detect whether the Root Port
> binding intentionally skipped the PERST# GPIO or legacy binding is used, just
> by checking for PERST# in Root Port node.
>
> So this helper should do 3 things:
>
> 1. If PERST# is found in Root Port node, use it.
> 2. If not, check the RC node and if present, return -ENOENT to fallback to the
> legacy binding.
> 3. If not found in both nodes, assume that the PERST# is not present in the
> design, and proceed with parsing Root Port binding further.
Hi Mani, understand, does the following code looks ok for above three cases?
/* Check if PERST# is present in Root Port node */
reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
"reset", GPIOD_ASIS, "PERST#");
if (IS_ERR(reset)) {
/* If error is not -ENOENT, it's a real error */
if (PTR_ERR(reset) != -ENOENT)
return PTR_ERR(reset);
/* PERST# not found in Root Port node, check RC node */
rc_has_reset = of_property_read_bool(dev->of_node, "reset-gpios") ||
of_property_read_bool(dev->of_node, "reset-gpio");
if (rc_has_reset)
return -ENOENT;
/* No PERST# in either node, assume not present in design */
reset = NULL;
}
port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
if (!port)
return -ENOMEM;
...
>
> But there is one more important limitation here. Right now, this API only
> handles PERST#. But if another vendor tries to use it and if they need other
> properties such as PHY, clocks etc... those resources should be fetched
> optionally only by this helper. But if the controller has a hard dependency on
> those resources, the driver will fail to operate.
>
> I don't think we can fix this limitation though and those platforms should
> ensure that the resource dependency is correctly modeled in DT binding and
> the DTS is validated properly. It'd be good to mention this in the kernel doc of
> this API.
Ok, I will add a NOTE for this in this API description.
>
> > + if (IS_ERR(reset))
> > + return PTR_ERR(reset);
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + port->reset = reset;
> > + INIT_LIST_HEAD(&port->list);
> > + list_add_tail(&port->list, &bridge->ports);
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * pci_host_common_parse_ports - Parse Root Port nodes from device
> > +tree
> > + * @dev: Device pointer
> > + * @bridge: PCI host bridge
> > + *
> > + * This function iterates through child nodes of the host bridge and
> > +parses
> > + * Root Port properties (currently only reset GPIO).
> > + *
> > + * Returns: 0 on success, -ENOENT if no ports found, other negative
> > +error codes
> > + * on failure
> > + */
> > +int pci_host_common_parse_ports(struct device *dev, struct
> > +pci_host_bridge *bridge) {
> > + int ret = -ENOENT;
> > +
> > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > + if (!of_node_is_type(of_port, "pci"))
> > + continue;
> > + ret = pci_host_common_parse_port(dev, bridge, of_port);
> > + if (ret)
> > + return ret;
>
> As Sashiko flagged, you need to make sure that devm_add_action_or_reset()
> is added even during the error path:
Yes, it needs to be fixed. We can handle it with the following two methods, I am not sure which method is better or more preferable?
#1: register cleanup action after first successful port parse and use cleanup_registered flag to avoid duplicate register.
int ret = -ENOENT;
bool cleanup_registered = false;
for_each_available_child_of_node_scoped(dev->of_node, of_port) {
if (!of_node_is_type(of_port, "pci"))
continue;
ret = pci_host_common_parse_port(dev, bridge, of_port);
if (ret)
return ret;
/* Register cleanup action after first successful port parse */
if (!cleanup_registered) {
ret = devm_add_action_or_reset(dev,
pci_host_common_delete_ports,
&bridge->ports);
if (ret)
return ret;
cleanup_registered = true;
}
}
#2: call devm_add_action to register cleanup action before the loop begins.
ret = devm_add_action(dev, pci_host_common_delete_ports,
&bridge->ports);
if (ret)
return ret;
ret = -ENOENT;
for_each_available_child_of_node_scoped(dev->of_node, of_port) {
if (!of_node_is_type(of_port, "pci"))
continue;
ret = pci_host_common_parse_port(dev, bridge, of_port);
if (ret)
return ret;
}
Best Regards
Sherry
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsashiko
> .dev%2F%23%2Fpatchset%2F20260407104154.2842132-1-
> sherry.sun%2540nxp.com%3Fpart%3D2&data=05%7C02%7Csherry.sun%40nx
> p.com%7Ca19d6997cb63454afd7808de94a961fe%7C686ea1d3bc2b4c6fa92cd
> 99c5c301635%7C0%7C0%7C639111652420710900%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P4Vz%2B7kH
> i07bzBnR1w4smYzRWDKPbzQsEcJXqEGyzP4%3D&reserved=0
>
> - Mani
>
> > + }
> > +
> > + if (ret)
> > + return ret;
> > +
> > + return devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> > + &bridge->ports);
> > +}
> > +EXPORT_SYMBOL_GPL(pci_host_common_parse_ports);
> > +
> > static void gen_pci_unmap_cfg(void *ptr) {
> > pci_ecam_free((struct pci_config_window *)ptr); diff --git
> > a/drivers/pci/controller/pci-host-common.h
> > b/drivers/pci/controller/pci-host-common.h
> > index b5075d4bd7eb..37714bedb625 100644
> > --- a/drivers/pci/controller/pci-host-common.h
> > +++ b/drivers/pci/controller/pci-host-common.h
> > @@ -12,6 +12,22 @@
> >
> > struct pci_ecam_ops;
> >
> > +/**
> > + * struct pci_host_port - Generic Root Port properties
> > + * @list: List node for linking multiple ports
> > + * @reset: GPIO descriptor for PERST# signal
> > + *
> > + * This structure contains common properties that can be parsed from
> > + * Root Port device tree nodes.
> > + */
> > +struct pci_host_port {
> > + struct list_head list;
> > + struct gpio_desc *reset;
> > +};
> > +
> > +void pci_host_common_delete_ports(void *data); int
> > +pci_host_common_parse_ports(struct device *dev, struct
> > +pci_host_bridge *bridge);
> > +
> > int pci_host_common_probe(struct platform_device *pdev); int
> > pci_host_common_init(struct platform_device *pdev,
> > struct pci_host_bridge *bridge,
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> > eaa4a3d662e8..629ae08b7d35 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -677,6 +677,7 @@ static void pci_init_host_bridge(struct
> > pci_host_bridge *bridge) {
> > INIT_LIST_HEAD(&bridge->windows);
> > INIT_LIST_HEAD(&bridge->dma_ranges);
> > + INIT_LIST_HEAD(&bridge->ports);
> >
> > /*
> > * We assume we can manage these PCIe features. Some systems
> may
> > diff --git a/include/linux/pci.h b/include/linux/pci.h index
> > 8f63de38f2d2..a73ea81ce88f 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -636,6 +636,7 @@ struct pci_host_bridge {
> > int domain_nr;
> > struct list_head windows; /* resource_entry */
> > struct list_head dma_ranges; /* dma ranges resource list */
> > + struct list_head ports; /* Root Port list (pci_host_port) */
> > #ifdef CONFIG_PCI_IDE
> > u16 nr_ide_streams; /* Max streams possibly active in
> @ide_stream_ida */
> > struct ida ide_stream_ida;
> > --
> > 2.37.1
> >
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Kuninori Morimoto @ 2026-04-08 6:33 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <CAABR9nH-1eBPFxtzVR6QBE1=esDN8x=hZpAkRSCO-TLmn0tRKA@mail.gmail.com>
Hi Bui, Geert
> > Hmm... fsi_dai_trigger() seems strange.
> > It seems (A) stops clock, and (B) sets register after that.
> > Is this the reason why you get error ? I think (A) and (B) should be
> > reversed. The balance between SNDRV_PCM_TRIGGER_START, and with
> > __fsi_suspend() are also not good.
> > If so, can you use hw_start/stop() ?
>
> Thank you for the guidance. After reordering the sequence and moving the
> SPU power control to fsi_hw_start/shutdown, the system hang is now resolved.
Nice !
> By the way, I’d like to discuss the fsidiv clock handling.
> In the legacy implementation, it was handled here:
> https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/sh/clk/cpg.c.
> Currently, this has not been ported to the Common Clock Framework (CCF) for
> R8A7740, and it resides in a different register range from the core CPG.
> For v2, would you prefer that I implement a small clock provider for
> fsidiv within
> the FSI driver, or should it be added under drivers/clk/renesas/?
I think it should be under drivers/clk/renesas, but Geert ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v1 02/13] dt-bindings: clock: Add system-0 domain PLL clock
From: Krzysztof Kozlowski @ 2026-04-08 6:29 UTC (permalink / raw)
To: Changhuang Liang
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Chen Wang,
Inochi Amaoto, Alexey Charkov, Thomas Bogendoerfer, Keguang Zhang,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Leyfoon Tan
In-Reply-To: <ZQ4PR01MB120210CE64AEE9CD57002CCAF25B2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
On 08/04/2026 07:17, Changhuang Liang wrote:
>
> In the next version, it will be changed to this, correct?
>
> sys0_syscon: syscon@13010000 {
> compatible = "starfive,jhb100-sys0-syscon", "syscon";
> reg = <0x0 0x13010000 0x0 0x2000>;
> clocks = <&osc>;
> #clock-cells = <1>;
Yes
Best regards,
Krzysztof
^ 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