* Re: [PATCH v2 1/2] dt-bindings: sram: Document qcom,milos-imem
From: Krzysztof Kozlowski @ 2026-04-08 7:33 UTC (permalink / raw)
To: Luca Weiss
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260407-milos-imem-v2-1-5084a490340c@fairphone.com>
On Tue, Apr 07, 2026 at 05:11:10PM +0200, Luca Weiss wrote:
> Add compatible for Milos SoC IMEM.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v21 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Krzysztof Kozlowski @ 2026-04-08 7:32 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: <wowfuuvnhnm6fjuynow4uvle7idvuyf77hct46gxakjre63y2z@xlmau2vl3lwb>
On 08/04/2026 09:13, Laurentiu Palcu wrote:
>>> + 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/
So you still know what is on the other side, e.g. second bridge for HDMI
or DP, even if this is DP over USB-C.
I understand that Dmitry did not want to use that part of code in the
drivers, but what is located at the end is not really a separate
property of this bridge, because it already duplicates that information.
The final endpoint defines the type.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Jorge Ramirez @ 2026-04-08 7:32 UTC (permalink / raw)
To: Trilok Soni
Cc: Sumit Garg, Jorge Ramirez, vikash.garodia, linux-arm-msm,
devicetree, dri-devel, freedreno, linux-media, netdev,
linux-wireless, ath12k, linux-remoteproc, andersson, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
dikshita.agarwal, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier, mukesh.ojha,
pavan.kondeti, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <439f9bbf-1ba1-465f-b5af-01ba0ebb86d4@oss.qualcomm.com>
On 07/04/26 15:14:22, Trilok Soni wrote:
> On 4/6/2026 4:42 AM, Sumit Garg wrote:
> > Hi Jorge,
> >
> > On Fri, Apr 03, 2026 at 11:37:07AM +0200, Jorge Ramirez wrote:
> >> On 27/03/26 18:40:39, Sumit Garg wrote:
> >>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>
> >>> Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> >>> TZ service allows to support multiple TZ implementation backends like QTEE
> >>> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> >>> backend service.
> >>
> >> OP-TEE based PAS service relies on the linux driver to configure the
> >> iommu (just as it is done on the no_tz case). This generic patch does
> >> not cover that requirement.
> >
> > That's exactly the reason why the kodiak EL2 dtso disables venus by
> > default in patch #1 due to missing IOMMU configuration.
> >
> >>
> >> Because of that, it is probably better if the commit message doesnt
> >> mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
> >> implement the same restrictions that QTEE (ie, iommu configuration).
> >
> > The scope for this patch is to just adopt the generic PAS layer without
> > affecting the client functionality.
the patchset cover letter + the commit message + the OP-TEE pull request
being referenced gives the ilusion to users that with the current set
they will get something functional (they will get a broken video
platform instead if they try to use OP-TEE).
That was the point I was making: IMO the commit message walks on a thin
line of "completeness"
QTEE and OP-TEE at this time implement different use cases (Venus with
QTEE runs with Linux on EL1 , OP-TEE runs with Linux on EL2). So maybe
worth mentioning this divergence.
> >
> >>
> >> I can send an RFC for OP-TEE support based on the integration work being
> >> carried out here [1]
> >
> > @Vikash may know better details about support for IOMMU configuration
> > for venus since it's a generic functionality missing when Linux runs in
> > EL2 whether it's with QTEE or OP-TEE.
> >
> > However, feel free to propose your work to initiate discussions again.
>
> Vikas and team depends on some of the IOMMU patches to get accepted
> before they enable the EL2 venus support. Please reach out to him
> and Prakash Gupta at Qualcomm.
isn't Vikash in this thread, he can ping me too no :) ? but sure, we'll
synch later
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Bartosz Golaszewski @ 2026-04-08 7:31 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-4-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v2:
> - Remove "default y".
> - Add base_offset member to struct rtd1625_gpio_info to handle merged regions.
> ---
> drivers/gpio/Kconfig | 11 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-rtd1625.c | 584 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 596 insertions(+)
> create mode 100644 drivers/gpio/gpio-rtd1625.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5ee11a889867..281549ad72ac 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -638,6 +638,17 @@ config GPIO_RTD
> Say yes here to support GPIO functionality and GPIO interrupt on
> Realtek DHC SoCs.
>
> +config GPIO_RTD1625
> + tristate "Realtek DHC RTD1625 GPIO support"
> + depends on ARCH_REALTEK || COMPILE_TEST
> + select GPIOLIB_IRQCHIP
> + help
> + This option enables support for the GPIO controller on Realtek
> + DHC (Digital Home Center) RTD1625 SoC.
> +
> + Say yes here to support both basic GPIO line functionality
> + and GPIO interrupt handling capabilities for this platform.
> +
> config GPIO_SAMA5D2_PIOBU
> tristate "SAMA5D2 PIOBU GPIO support"
> depends on MFD_SYSCON
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index c05f7d795c43..c95ba218d53a 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
> obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> new file mode 100644
> index 000000000000..bcc1bbb115fa
> --- /dev/null
> +++ b/drivers/gpio/gpio-rtd1625.c
> @@ -0,0 +1,584 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Realtek DHC RTD1625 gpio driver
> + *
> + * Copyright (c) 2023 Realtek Semiconductor Corp.
No modifications since 2023?
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +
> +#define RTD1625_GPIO_DIR BIT(0)
> +#define RTD1625_GPIO_OUT BIT(2)
> +#define RTD1625_GPIO_IN BIT(4)
> +#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
> +#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
> +#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
> +#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
> +#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
> +#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> +
> +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> +
> +/* Write-enable masks for all GPIO configs and reserved hardware bits */
> +#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
> +#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> +
> +#define RTD1625_GPIO_DEBOUNCE_1US 0
> +#define RTD1625_GPIO_DEBOUNCE_10US 1
> +#define RTD1625_GPIO_DEBOUNCE_100US 2
> +#define RTD1625_GPIO_DEBOUNCE_1MS 3
> +#define RTD1625_GPIO_DEBOUNCE_10MS 4
> +#define RTD1625_GPIO_DEBOUNCE_20MS 5
> +#define RTD1625_GPIO_DEBOUNCE_30MS 6
> +#define RTD1625_GPIO_DEBOUNCE_50MS 7
> +
> +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> +
> +/**
> + * struct rtd1625_gpio_info - Specific GPIO register information
> + * @num_gpios: The number of GPIOs
> + * @irq_type_support: Supported IRQ types
> + * @gpa_offset: Offset for GPIO assert interrupt status registers
> + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> + * @level_offset: Offset of level interrupt status register
> + * @write_en_all: Write-enable mask for all configurable bits
> + */
> +struct rtd1625_gpio_info {
> + unsigned int num_gpios;
> + unsigned int irq_type_support;
> + unsigned int base_offset;
> + unsigned int gpa_offset;
> + unsigned int gpda_offset;
> + unsigned int level_offset;
> + unsigned int write_en_all;
> +};
Please remove the tabs in the above struct.
> +
> +struct rtd1625_gpio {
> + struct gpio_chip gpio_chip;
> + const struct rtd1625_gpio_info *info;
> + void __iomem *base;
> + void __iomem *irq_base;
> + unsigned int irqs[3];
> + raw_spinlock_t lock;
> + unsigned int *save_regs;
> +};
I'd also personally remove these tabs here but won't die on that hill.
> +
> +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpa_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->gpda_offset + ((offset / 32) * 4);
> +}
> +
> +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
> +{
> + return data->info->level_offset + ((offset / 32) * 4);
> +}
Looking at these, I'm under the impression that this driver could quite easily
be converted to using gpio-mmio or even gpio-regmap with an MMIO regmap, have
you looked into it by any chance?
Bart
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Bartosz Golaszewski @ 2026-04-08 7:28 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai, linusw,
brgl, robh, krzk+dt, conor+dt, afaerber, tychang
In-Reply-To: <20260408025243.1155482-5-eleanor.lin@realtek.com>
On Wed, 8 Apr 2026 04:52:43 +0200, Yu-Chun Lin <eleanor.lin@realtek.com> said:
> Add the GPIO node for the Realtek RTD1625 SoC.
>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Krzysztof Kozlowski @ 2026-04-08 7:26 UTC (permalink / raw)
To: Biju
Cc: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Biju Das,
linux-spi, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260407145753.101840-2-biju.das.jz@bp.renesas.com>
On Tue, Apr 07, 2026 at 03:57:50PM +0100, Biju wrote:
> - items:
> @@ -90,6 +91,33 @@ required:
>
> allOf:
> - $ref: spi-controller.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,r9a08g046-rspi
> + then:
> + properties:
> + clocks:
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: pclk
> + - const: tclk
Blank line here, but no need to resend just for that.
> + dmas:
> + maxItems: 2
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 net-next 06/14] net: enetc: add support for the "Update" operation to buffer pool table
From: Wei Fang @ 2026-04-08 7:25 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: <20260403011731.1795517-1-kuba@kernel.org>
> > @@ -702,5 +708,38 @@ int ntmp_vft_add_entry(struct ntmp_user *user,
> u16 vid,
> > }
> > EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
> >
> > +int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
> > + const struct bpt_cfge_data *cfge)
> > +{
> > + struct ntmp_dma_buf data = {
> > + .dev = user->dev,
> > + .size = sizeof(struct bpt_req_update),
> > + };
> > + struct bpt_req_update *req;
> > + union netc_cbd cbd;
> > + int err;
> > +
> > + err = ntmp_alloc_data_mem(&data, (void **)&req);
> > + if (err)
> > + return err;
> > +
> > + ntmp_fill_crd_eid(&req->rbe, user->tbl.bpt_ver, 0,
> > + NTMP_GEN_UA_CFGEU | BPT_UA_BPSEU, entry_id);
>
> Does this update action mask match the size of the request buffer?
>
> The mask includes both NTMP_GEN_UA_CFGEU and BPT_UA_BPSEU, which
> instructs
> the hardware to update both the configuration entry and the status entry.
> However, struct bpt_req_update only contains the configuration data,
> omitting the status data.
>
> If the hardware attempts to read the missing BPSE data, could it reject
> the command due to an undersized request length, or read beyond the
> intended payload into zero-initialized DMA padding? This might overwrite
> critical buffer pool tracking variables like amount_used_hwm.
>
> If only the configuration is being updated, should the BPT_UA_BPSEU flag
> be removed?
The BPSE_DATA is a set of statistics and status records kept by the hardware
(internal buffer), and does not require the user to provide additional data to
the hardware for updates. Therefore, for the 'update' operation, the request
buffer does not need to provide BPSE_DATA data.
^ permalink raw reply
* [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Axel Flordal @ 2026-04-08 7:21 UTC (permalink / raw)
To: asahi, linux-arm-kernel, devicetree, linux-kernel
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Change "configiguration" to "configuration".
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Axel Flordal <axel@flordal.net>
---
Original patch: https://lore.kernel.org/asahi/CAEg-Je-KwNNGoi3mpPeNq3Jmtzj_5seuj1Qeh2_1dt994iCJSA@mail.gmail.com/T/#t
If this is unwanted I of course won't send again.
---
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
index 9740fbf200f0..d2720b307774 100644
--- a/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
+++ b/arch/arm64/boot/dts/apple/spi1-nvram.dtsi
@@ -2,7 +2,7 @@
//
// Devicetree include for common spi-nor nvram flash.
//
-// Apple uses a consistent configiguration for the nvram on all known M1* and
+// Apple uses a consistent configuration for the nvram on all known M1* and
// M2* devices.
//
// Copyright The Asahi Linux Contributors
--
2.53.0
^ permalink raw reply related
* 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
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