* Re: [PATCH 4/4] arm64: dts: qcom: sdm845-lg: Enable qcom,snoc-host-cap-skip-quirk
From: Konrad Dybcio @ 2026-04-09 8:18 UTC (permalink / raw)
To: Paul Sajna, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jeff Johnson, Dmitry Baryshkov,
David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming
In-Reply-To: <20260408-judyln-followup-v1-4-823467519b59@postmarketos.org>
On 4/9/26 4:41 AM, Paul Sajna wrote:
> The WCN3990 firmware for judyln does not respond to the request for
> host capabilities. Add the devicetree quirk to skip this request.
>
> Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Krzysztof Kozlowski @ 2026-04-09 8:17 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-2-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:16AM +0200, Gregor Herburger wrote:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> drivers/nvmem/Kconfig | 12 +++
> drivers/nvmem/Makefile | 1 +
> drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 2 +
> 4 files changed, 174 insertions(+)
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
> This driver can also be built as a module. If so, the module
> will be called nvmem_qoriq_efuse.
>
> +config NVMEM_RASPBERRYPI_OTP
> + tristate "Raspberry Pi OTP support"
> + # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> + # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
Drop comment and use standard rules for multiple modules.
https://lwn.net/Articles/944368/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: marvell: armada-37xx: USB3 PHY cleanup
From: Gregory CLEMENT @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gabor Juhos, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
In-Reply-To: <20260330-armada-37xx-usb3-phy-cleanup-v1-0-34d77f1a1784@gmail.com>
Gabor Juhos <j4g8y7@gmail.com> writes:
> There are two small patches in the series. The first helps to avoid
> triggering a bug in the USB core code, whereas the second one is a
> small cleanup to align PHY definitions of the USB3 node with other
> platforms.
>
> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
> ---
> Gabor Juhos (2):
> arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
>
> arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 2 +-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> base-commit: 2ff6cc999a04bcb094b8cbba68a9251f03a5c876
> change-id: 20260330-armada-37xx-usb3-phy-cleanup-922a5472794a
>
> Best regards,
> --
> Gabor Juhos <j4g8y7@gmail.com>
>
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Krzysztof Kozlowski @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-3-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> to the devicetree.
So this sentence confirms my question on bindings - your device
raspberrypi,bcm2835-firmware has these, thus you do not need these child
nodes at all. Neither compatibles.
Drop entire DTS and binding patches.
See also writing-bindings and DTS101 why we do not allow this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Krzysztof Kozlowski @ 2026-04-09 8:13 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-1-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:15AM +0200, Gregor Herburger wrote:
> The firmware running on the Raspberry Pi VideoCore can be used to access
> OTP registers. There are two OTP regions (private and customer). Add a
> binding for these.
A nit, subject: drop second/last, redundant "a binding for the". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec9..975c8927d75b 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -137,6 +137,20 @@ required:
> - compatible
> - mboxes
>
> +patternProperties:
> + "^otp-(customer|private)$":
Not a pattern but just "otp".
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + enum:
> + - raspberrypi,firmware-otp-customer
> + - raspberrypi,firmware-otp-private
I don't understand why having OTP regions is not deducible from
top-level compatible. I also do not get why do you need per OTP
compatible.
There are no resources here, so standard review would be "no" and you
need strong justification in terms of DT.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Krzysztof Kozlowski @ 2026-04-09 8:10 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland, linux-arm-kernel,
iommu, devicetree, linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-1-d75dac96e828@nxp.com>
On Wed, Apr 08, 2026 at 03:51:15PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The Arm SMMU v3 specification defines an optional PMCG (Performance
"optional" in a meaning some SMMUv3 implementations do not have it?
> Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
> with TCU Performance Monitor Counter Group (PMCG) registers starting at
> offset 0x02000 in page 0. So PMCG could be described as a child node of the
> SMMU in Devicetree.
>
> Add a patternProperties entry to the arm,smmu-v3 binding to allow child
> nodes matching "pmu@<addr>" and reference the existing
> arm,smmu-v3-pmcg.yaml schema.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -50,6 +50,10 @@ properties:
> - cmdq-sync # CMD_SYNC complete
> - priq # PRI Queue not empty
>
> + '#address-cells': true
Instead enum [1, 2]
> + '#size-cells': true
Same here
> + ranges: true
I guess only one mapping is allowed so:
maxItems: 1
> +
> '#iommu-cells':
> const: 1
>
> @@ -83,6 +87,12 @@ properties:
> register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
> doesn't support SMMU page1 register space.
>
> +patternProperties:
> + '^pmu@[0-9a-f]+$':
> + type: object
> + $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
> + unevaluatedProperties: false
Please add another example with 4-space indentation.
> +
> allOf:
> - if:
> not:
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Vladimir Oltean @ 2026-04-09 8:07 UTC (permalink / raw)
To: Wei Fang
Cc: Jakub Kicinski, Claudiu Manoil, 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: <AM8PR04MB72840DBFC7F3FD578DFF6AF8885BA@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 11:59:24AM +0300, Wei Fang wrote:
> > > +static int netc_init_switch_id(struct netc_switch *priv)
> > > +{
> > > + struct netc_switch_regs *regs = &priv->regs;
> > > + struct dsa_switch *ds = priv->ds;
> > > +
> > > + /* The value of 0 is reserved for the VEPA switch and cannot
> > > + * be used.
> > > + */
> > > + if (ds->index > SWCR_SWID || !ds->index) {
> > > + dev_err(priv->dev, "Switch index %d out of range\n",
> > > + ds->index);
> > > + return -ERANGE;
> > > + }
> >
> > Does this check cause the probe to fail unconditionally for standard
> > single-switch topologies?
> >
> > The DSA core typically assigns ds->index = 0 by default for the first switch.
> > Because !ds->index evaluates to true for index 0, this setup function will
> > always fail unless the dsa,member property is explicitly overridden in the
> > device tree.
>
> As I mentioned in another mail, we added the 'dsa,member' property to the
> netc switch DT-binding doc, specifying that the 'member' (switch index) value
> cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> >
> > Could the driver translate the hardware ID internally, for example by writing
> > ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> > restriction onto the software DSA index?
>
> The current approach is based on Vladimir's suggestion. I need to confirm with
> Vladimir which approach is better.
>
> Hi Vladimir,
>
> What are your thoughts on this suggestion? Is this approach better?
I maintain it is preferable/simpler the way you are doing it, with a 1:1 mapping.
The LLM's concern would be more valid if the switch were discrete and every
board DTS author would have to remember to place the dsa,member property.
But the switch OF node will live in an SoC dtsi.
Maybe you could put something along these lines in the commit message,
hopefully the LLM will pick it up and stop complaining.
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-04-09 8:05 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Srinivas Kandagatla, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <90f54202-6eb6-4c44-b029-a4e0dafad861@gmx.net>
On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
> > Hi Stefan,
> >
> > thanks for the review.
> > > Is there any reason, why we cannot register this driver in
> > > rpi_firmware_probe() like hwmon and clk driver?
> > >
> > > I like to avoid the complete dt-binding from patch 1.
> > The private OTP registers are not available on all Raspberries. Afaik
> > only on 4 and 5. So I think these registers must be described through
> > the device tree. Therefore the bindings are needed.
> This binding doesn't represent some kind of hardware, it's just some
> firmware interface. A proper DT binding would describe the MMIO address
> range for OTP access.
I think it does represent real hardware. Although it is hidden through the
firmware. Not all hardware must be MMIO addresses.
The only driver that does not have a DT node is the hwmon driver. All
other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
binding. Looking at the comment in rpi_register_clk_driver this
seems to be some legacy behaviour for older DTs for the clock driver.
> If you need some distinction between the Raspberry Pi generations there are
> firmware tags to do this.
So what is your suggestion? What tags do you mean?
I don't understand why you want to avoid the dt-binding. What is the
problem with dt-bindings?
What is the benefit of registering the driver in rpi_firmware_probe?
Imho describing this in the DT is the more natural way to do this. E.g.
if in the future there is a raspberry pi with a 64Byte otp it could easily
be supported by adding a devicetree property and add it to the driver.
Regards
Gregor
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: timestamp: Add Tegra264 support
From: Krzysztof Kozlowski @ 2026-04-09 8:05 UTC (permalink / raw)
To: Suneel Garapati
Cc: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260408212413.217692-2-suneelg@nvidia.com>
On Wed, Apr 08, 2026 at 09:24:11PM +0000, Suneel Garapati wrote:
> Add timestamp provider support for the Tegra264 in devicetree
> bindings. Tegra264 has two generic timestamping engines (GTE)
> which are the always-on GTE (AON) and legacy interrupt
> controller (LIC) GTE.
> 'nvidia,slices' property is deprecated and hence not allowed for
> Tegra264.
>
> Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: fpga: Technologic Systems TS-7300 FPGA Manager
From: Krzysztof Kozlowski @ 2026-04-09 8:03 UTC (permalink / raw)
To: Phil Pemberton
Cc: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tom Rix, Florian Fainelli, linux-fpga, devicetree,
linux-kernel
In-Reply-To: <20260408165223.3051759-2-philpem@philpem.me.uk>
On Wed, Apr 08, 2026 at 05:52:22PM +0100, Phil Pemberton wrote:
> Add device tree binding documentation for the Altera Cyclone II FPGA
> found on Technologic Systems (now EmbeddedTS) TS-7300 boards, programmed
> via the memory-mapped interface in the CPLD.
Subject - I did not ask to drop "Add". The subject makes little sense now.
With subject fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
<form letter>
This is an automated instruction, just in case, because many review
tags are being ignored. If you know the process, just skip it entirely
(please do not feel offended by me posting it here - no bad intentions
intended, no patronizing, I just want to avoid wasted efforts). If you
do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here ('b4 trailers -u ...').
However, there's no need to repost patches *only* to add the tags. The
upstream maintainer will do that for tags received on the version they
apply.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/process/submitting-patches.rst#L591
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/2] Add device tree binding for ts73xx-fpga
From: Krzysztof Kozlowski @ 2026-04-09 8:01 UTC (permalink / raw)
To: Phil Pemberton
Cc: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tom Rix, Florian Fainelli, linux-fpga, devicetree,
linux-kernel
In-Reply-To: <20260408165223.3051759-1-philpem@philpem.me.uk>
On Wed, Apr 08, 2026 at 05:52:21PM +0100, Phil Pemberton wrote:
> The driver for the Technologic Systems (EmbeddedTS) TS-7300 board's
> onboard FPGA didn't have an OF match table. This prevented it from being
> instantiated from a device tree. This is undesirable given EP93xx is
> moving to device tree, and effectively prevents it from being used.
> This patch series adds the OF match table and a device tree binding.
>
> Changes since v1:
> - Use specific compatible "technologic,ts7300-fpga" instead of
> wildcard "technologic,ts73xx-fpga" (Krzysztof)
> - Fix subject line for dt-bindings patch (Krzysztof)
> - Simplify example in binding doc (Krzysztof)
Missing explanation of dropping tags.
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: patchwork-bot+netdevbpf @ 2026-04-09 8:00 UTC (permalink / raw)
To: Luca Weiss
Cc: elder, andrew+netdev, davem, edumazet, kuba, pabeni, robh,
krzk+dt, conor+dt, andersson, konradybcio, akoskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 03 Apr 2026 18:43:46 +0200 you wrote:
> First, two fixes that unbreak IPA v5.0+, which can be applied
> independently.
>
> Then add support for IPA v5.2 which can be found in the Milos SoC. And
> finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
> starts working.
>
> [...]
Here is the summary with links:
- [1/6] net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
https://git.kernel.org/netdev/net/c/9709b56d908a
- [2/6] net: ipa: fix event ring index not programmed for IPA v5.0+
https://git.kernel.org/netdev/net/c/56007972c0b1
- [3/6] dt-bindings: net: qcom,ipa: add Milos compatible
(no matching commit)
- [4/6] net: ipa: add IPA v5.2 configuration data
(no matching commit)
- [5/6] arm64: dts: qcom: milos: Add IPA node
(no matching commit)
- [6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [5/6] arm64: dts: qcom: milos: Add IPA node
From: Krzysztof Kozlowski @ 2026-04-09 8:00 UTC (permalink / raw)
To: Paolo Abeni, luca.weiss
Cc: krzk+dt, akoskovich, konradybcio, linux-kernel, conor+dt,
devicetree, andersson, netdev, kuba, linux-arm-msm, andrew+netdev,
davem, robh, edumazet, ~postmarketos/upstreaming, phone-devel,
elder
In-Reply-To: <20260409075854.308955-1-pabeni@redhat.com>
On 09/04/2026 09:58, Paolo Abeni wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
...
>> +
>> + qcom,smem-states = <&smp2p_ipa_out 0>,
>> + <&smp2p_ipa_out 1>;
>> + qcom,smem-state-names = "ipa-clock-enabled-valid",
>> + "ipa-clock-enabled";
>> +
>> + sram = <&ipa_modem_tables>;
>> ^^^^^^^^^^^^^^^^^^
>
> Is the ipa_modem_tables label defined anywhere? The Device Tree Compiler
> will fail with "Reference to non-existent node or label
> 'ipa_modem_tables'" if this label doesn't exist.
Paul, please ignore all of such review from AI tools. It is completely
wrong and pointless.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [5/6] arm64: dts: qcom: milos: Add IPA node
From: Paolo Abeni @ 2026-04-09 7:58 UTC (permalink / raw)
To: luca.weiss
Cc: pabeni, krzk+dt, akoskovich, konradybcio, linux-kernel, conor+dt,
devicetree, andersson, netdev, kuba, linux-arm-msm, andrew+netdev,
davem, robh, edumazet, ~postmarketos/upstreaming, phone-devel,
elder
In-Reply-To: <20260403-milos-ipa-v1-5-01e9e4e03d3e@fairphone.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
arm64: dts: qcom: milos: Add IPA node
Add the description of the IPA block in the Milos SoC.
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..a244e136a877 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -1281,6 +1281,50 @@ adreno_smmu: iommu@3da0000 {
> dma-coherent;
> };
>
> + ipa: ipa@3f40000 {
> + compatible = "qcom,milos-ipa";
> +
> + reg = <0x0 0x03f40000 0x0 0x10000>,
> + <0x0 0x03f50000 0x0 0x5000>,
> + <0x0 0x03e04000 0x0 0xfc000>;
> + reg-names = "ipa-reg",
> + "ipa-shared",
> + "gsi";
> +
> + interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING 0>,
> + <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH 0>,
> + <&smp2p_ipa_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&smp2p_ipa_in 1 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "ipa",
> + "gsi",
> + "ipa-clock-query",
> + "ipa-setup-ready";
> +
> + clocks = <&rpmhcc RPMH_IPA_CLK>;
> + clock-names = "core";
> +
> + interconnects = <&aggre2_noc MASTER_IPA QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_IPA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "memory",
> + "config";
> +
> + iommus = <&apps_smmu 0x4a0 0x0>,
> + <&apps_smmu 0x4a2 0x0>;
> +
> + qcom,qmp = <&aoss_qmp>;
> +
> + qcom,smem-states = <&smp2p_ipa_out 0>,
> + <&smp2p_ipa_out 1>;
> + qcom,smem-state-names = "ipa-clock-enabled-valid",
> + "ipa-clock-enabled";
> +
> + sram = <&ipa_modem_tables>;
> ^^^^^^^^^^^^^^^^^^
Is the ipa_modem_tables label defined anywhere? The Device Tree Compiler
will fail with "Reference to non-existent node or label
'ipa_modem_tables'" if this label doesn't exist.
The sram property is optional according to the qcom,ipa.yaml binding, and
other similar Qualcomm SoCs like SM8350, SM8550, and SM8650 don't include
this property in their IPA nodes. Should this line be removed, or does the
ipa_modem_tables node need to be added to the reserved-memory section?
> +
> + status = "disabled";
> + };
> +
[ ... ]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: qcom: Describe Hawi TLMM block
From: Krzysztof Kozlowski @ 2026-04-09 7:59 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260408-hawi-pinctrl-v2-1-fd7f681f5e05@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 07:45:47PM +0530, Mukesh Ojha wrote:
> The Top Level Mode Multiplexer (TLMM) in the Qualcomm Hawi SoC
> provides GPIO and pinctrl functionality for UFS, SDC and 226
> GPIO pins.
>
> Add a DeviceTree binding to describe the TLMM block on Qualcomm's
> Hawi SoC.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> .../bindings/pinctrl/qcom,hawi-tlmm.yaml | 120 +++++++++++++++++++++
> 1 file changed, 120 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: i2c: cnxt,cx92755-i2c: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-04-09 7:52 UTC (permalink / raw)
To: Shi Hao
Cc: robh, krzk+dt, andi.shyti, conor+dt, linux-i2c, devicetree,
linux-kernel, daniel.baluta, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <20260408083549.12815-1-i.shihao.999@gmail.com>
On Wed, Apr 08, 2026 at 02:05:49PM +0530, Shi Hao wrote:
> Convert the Conexant Digicolor I2C bindings to DT schema.
>
> Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
> ---
>
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
You missed Rob's tag.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Stefano Radaelli @ 2026-04-09 7:48 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <adcdWdTcVR2T2F5c@lizhi-Precision-Tower-5810>
Hi Frank!
On Wed, Apr 08, 2026 at 11:30:33PM -0400, Frank Li wrote:
>
> what' difference with imx93-var-som ? Can you reuse it?
>
The imx91-var-som is conceptually similar to imx93-var-som, and I used
it as a reference while preparing this DTS.
However, it cannot be directly reused as there are several hardware
differences between the two platforms, including SoC integration and
peripheral configuration (e.g. pinctrl, and available IPs).
So a separate description is required for imx91.
Best regards,
Stefano
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: lemans: Move PCIe devices into soc node
From: Shawn Guo @ 2026-04-09 7:48 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Krzysztof Kozlowski, Manivannan Sadhasivam,
Mrinmay Sarkar, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260331090147.18522-1-shengchao.guo@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 05:01:47PM +0800, Shawn Guo wrote:
> These PCIe devices with MMIO address should be inside soc node rather
> than outside.
>
> Fixes: 489f14be0e0a ("arm64: dts: qcom: sa8775p: Add pcie0 and pcie1 nodes")
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
As this is a prerequisite of my Lemans DTS split series, I'm including
it into the series.
Shawn
^ permalink raw reply
* Re: [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Paolo Abeni @ 2026-04-09 7:46 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
On 4/3/26 6:43 PM, Luca Weiss wrote:
> First, two fixes that unbreak IPA v5.0+, which can be applied
> independently.
>
> Then add support for IPA v5.2 which can be found in the Milos SoC. And
> finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
> starts working.
You should have probably split the series in 2, with patches 1 & 2
targeting net and the following ones targeting net-next. It looks like
patch 5 needs some adjustment. I'm applying the first 2.
/P
^ permalink raw reply
* [PATCH] dt-bindings: mmc: st,sdhci: convert to DT schema
From: Charan Pedumuru @ 2026-04-09 7:43 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin
Cc: linux-mmc, devicetree, linux-kernel, Charan Pedumuru
Convert STMicroelectronics sdhci-st MMC/SD controller binding to DT schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 -------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 122 +++++++++++++++++++++
2 files changed, 122 insertions(+), 110 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
deleted file mode 100644
index ccf82b4ee838..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* STMicroelectronics sdhci-st MMC/SD controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties
-used by the sdhci-st driver.
-
-Required properties:
-- compatible: Must be "st,sdhci" and it can be compatible to "st,sdhci-stih407"
- to set the internal glue logic used for configuring the MMC
- subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
- family).
-
-- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- interrupts: One mmc interrupt should be described here.
-- interrupt-names: Should be "mmcirq".
-
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-- reg: This must provide the host controller base address and it can also
- contain the FlashSS Top register for TX/RX delay used by the driver
- to configure DLL inside the flashSS, if so reg-names must also be
- specified.
-
-Optional properties:
-- reg-names: Should be "mmc" and "top-mmc-delay". "top-mmc-delay" is optional
- for eMMC on stih407 family silicon to configure DLL inside FlashSS.
-
-- non-removable: Non-removable slot. Also used for configuring mmcss in STiH407 SoC
- family.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- bus-width: Number of data lines.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- max-frequency: Can be 200MHz, 100MHz or 50MHz (default) and used for
- configuring the CCONFIG3 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- resets: Phandle and reset specifier pair to softreset line of HC IP.
- See: Documentation/devicetree/bindings/reset/reset.txt
-
-- vqmmc-supply: Phandle to the regulator dt node, mentioned as the vcc/vdd
- supply in eMMC/SD specs.
-
-- sd-uhs-sdr50: To enable the SDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-sdr104: To enable the SDR104 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-ddr50: To enable the DDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-Example:
-
-/* Example stih416e eMMC configuration */
-
-mmc0: sdhci@fe81e000 {
- compatible = "st,sdhci";
- reg = <0xfe81e000 0x1000>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_a1_ls 1>;
- bus-width = <8>
-
-/* Example SD stih407 family configuration */
-
-mmc1: sdhci@9080000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09080000 0x7ff>;
- reg-names = "mmc";
- interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sd1>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_1>;
- resets = <&softreset STIH407_MMC1_SOFTRESET>;
- bus-width = <4>;
-};
-
-/* Example eMMC stih407 family configuration */
-
-mmc0: sdhci@9060000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
- reg-names = "mmc", "top-mmc-delay";
- interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
- vqmmc-supply = <&vmmc_reg>;
- max-frequency = <200000000>;
- bus-width = <8>;
- non-removable;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
- sd-uhs-ddr50;
-};
diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
new file mode 100644
index 000000000000..22060fe6e364
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/st,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SDHCI-ST MMC/SD Controller
+
+description:
+ The STMicroelectronics SDHCI-ST MMC/SD host controller, which is
+ compliant with the SD Host Controller Interface (SDHCI) specification and
+ is used to interface with MMC, SD and SDIO cards. The ST SDHCI controller
+ extends the standard SDHCI capabilities with platform-specific
+ configurations such as additional register regions,clock inputs, and delay
+ control mechanisms required for signal timing adjustments which are
+ necessary to support high-speed modes and ensure reliable data transfer
+ across different ST SoCs.
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,sdhci
+ - items:
+ - const: st,sdhci-stih407
+ - const: st,sdhci
+
+ reg:
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - mmc
+ - top-mmc-delay
+
+ clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum:
+ - mmc
+ - icn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: mmcirq
+
+ pinctrl-names:
+ const: default
+
+ resets:
+ maxItems: 1
+ description: Phandle to reset line of host controller.
+
+ vqmmc-supply:
+ description: Regulator supplying I/O voltage (Vcc/Vdd for SD/eMMC).
+
+ non-removable:
+ type: boolean
+ description:
+ Indicates a non-removable device (e.g., eMMC). Also used for mmcss config.
+
+ bus-width:
+ description: Number of data lines.
+ enum: [1, 4, 8]
+
+ max-frequency:
+ enum: [50000000, 100000000, 200000000]
+ default: 50000000
+ description:
+ Maximum bus frequency. Used to configure CCONFIG3 in mmcss.
+
+ sd-uhs-sdr50:
+ type: boolean
+
+ sd-uhs-sdr104:
+ type: boolean
+
+ sd-uhs-ddr50:
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - pinctrl-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ sdhci@9060000 {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
+ reg-names = "mmc", "top-mmc-delay";
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0>;
+ clock-names = "mmc", "icn";
+ clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+ <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+ bus-width = <8>;
+ };
+...
---
base-commit: e77a5a5cfe43b4c25bd44a3818e487033287517f
change-id: 20260327-st-mmc-c906ad95ff83
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: rtc: nct3018y: add nuvoton,ctrl-reg-val property
From: David Wang @ 2026-04-09 7:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: a.zummo, alexandre.belloni, robh, krzk+dt, conor+dt, andrew,
avi.fishman, tmaimon77, tali.perry1, venture, yuenn, benjaminfair,
ctcchien, mimi05633, openbmc, linux-rtc, devicetree, linux-kernel,
davidwang
In-Reply-To: <a1e24b69-b90a-47d7-b952-bca45fcc6281@kernel.org>
On Apr 9, 2026, at 15:23, Krzysztof Kozlowski wrote:
>
> On 09/04/2026 09:21, David Wang wrote:
> > Add "nuvoton,ctrl-reg-val" vendor property to allow optional
> > initialization of the RTC control register (0x0A).
> >
> > This allows platform-specific configurations like 24h mode and
> > write ownership to be defined via Device Tree.
> >
> > Signed-off-by: David Wang <tomato1220@gmail.com>
> > ---
> > Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > index 4f9b5604acd9..0984dfb77170 100644
> > --- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > @@ -24,6 +24,10 @@ properties:
> >
> > reset-source: true
> >
> > + nuvoton,ctrl-reg-val:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: Initial value for the control register (0x0A).
>
> 24h mode is not a property of a board. I don't know what "write
> ownership" is.
>
> Best regards,
> Krzysztof
Hi Krzysztof,
Thanks for your feedback. Let me clarify these two points based on the
NCT3018Y datasheet:
1. Regarding "write ownership": The NCT3018Y features two I2C
interfaces (Primary and Secondary). The TWO (Time Write Ownership) bit
in the control register determines which interface has the authority
to write to the RTC. We need to ensure the interface connected to our
SoC is granted this ownership during probe—especially for factory-new
chips—to ensure the RTC is writable.
2. Regarding "24h mode": This bit determines the internal data format
in which time is stored within the RTC hardware. Setting this ensures
the hardware's internal storage layout matches the driver's
expectation from the start.
Best regards,
David Wang
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-09 7:43 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, tychang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260408025243.1155482-3-eleanor.lin@realtek.com>
On Wed, Apr 08, 2026 at 10:52:41AM +0800, Yu-Chun Lin wrote:
> +maintainers:
> + - Tzuyi Chang <tychang@realtek.com>
> +
> +description: |
> + GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
> + architecture that differs significantly from earlier RTD series controllers.
> + Each GPIO has dedicated registers for configuration (direction, input/output
> + values, debounce), and interrupt control supporting edge and level detection
> + modes.
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,rtd1625-iso-gpio
> + - realtek,rtd1625-isom-gpio
> +
> + reg:
> + maxItems: 1
> + description: |
> + Memory region containing both interrupt control and GPIO
> + configuration registers in a contiguous address space.
> +
> + For realtek,rtd1625-iso-gpio:
> + - Base + 0x0 ~ 0xff: Interrupt control registers
> + - Base + 0x100 ~ 0x397: GPIO configuration registers
> +
> + For realtek,rtd1625-isom-gpio:
> + - Base + 0x0 ~ 0x1f: Interrupt control registers
> + - Base + 0x20 ~ 0x2f: GPIO configuration registers
Drop description, you are duplicating here DTS. Bindings do not need to
serve as reference manual for the device.
However when you state them like this and give them names, I have the
same concerns as last time - please consult your datasheet whether this
is really one address space.
With description dropped:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 19/19] gpio: add GPIO controller found on Waveshare DSI TOUCH panels
From: Bartosz Golaszewski @ 2026-04-09 7:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Neil Armstrong,
Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij
In-Reply-To: <l6pezliurpgv2mopw2xl4gfgpki6r3v6ufpsaavj774qnxgept@h3jxxpco23oa>
On Thu, Apr 9, 2026 at 3:26 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> >
> > This driver looks like it could be easily converted to use gpio-regmap and
> > become much shorter in the process. Could you please take a look at
> > linux/gpio/regmap.h?
>
> I took a glance. It is a nice wrapper, but I think being able to call
> waveshare_gpio_set() internally without extra troubles overweights the
> bonuses of the wrapper. Also, I'd agree if there were extra complexity
> here (e.g. the stride or the in/out handling), but having just the out
> GPIOs doesn't seem to warrant it.
>
> An alternative would be to split away the backlight into a separate
> pwm-backlight device. Then having waveshare_gpio_set() isn't that
> important and thus I could switch to GPIO_REGMAP. But then... We don't
> have real control over the PWM. We are really programming some values,
> with the actual PWM duty cycle calculations being handled internally.
>
> With all that in mind, unless you really insist, I'd prefer to leave
> this part the driver as is.
>
Ok, with the other issues fixed it's good to go then.
Bart
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:31 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
> + compatible = "aspeed,ast2600-i3c-global", "syscon";
Also undocumented ABI. Apply this patch and run checkpatch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <20260409-beneficial-sociable-tamarin-dbcaeb@quoll>
On 09/04/2026 09:28, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
>> Introduce the device-tree bindings for I3C global registers found on
>> AST2600 SoCs.
>>
>> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
>> ---
>> I wasn't sure if I should add newline at the end of the
>> file or not so I took
>> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
>> as an example.
>
> Answer is: you cannot have patch warnings.
>
> Documentation/devicetree/bindings/i3c does not have patch warning, does
> it?
And if you tested this code with standard tools, you would see that...
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