* Re: [PATCH V17 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Chris Morgan @ 2026-07-20 17:15 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260719000530.62bad145@jic23-huawei>
On Sun, Jul 19, 2026 at 12:05:30AM +0100, Jonathan Cameron wrote:
> On Thu, 16 Jul 2026 13:26:30 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
>
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Add the core component of a new inv_icm42607 driver. This includes
> > a few setup functions and the full register definition in the
> > header file, as well as the bits necessary to compile and probe the
> > device when used on an i2c bus.
> >
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> Hi Chris,
>
> Just one small thing below given you are probably going to do
> a v18. If it had just been this I might have tweaked it whilst
> applying
>
> Thanks,
>
> Jonathan
>
>
> > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> > new file mode 100644
> > index 000000000000..8f74bf38aad1
> > --- /dev/null
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
>
> ...
>
> > +static int inv_icm42607_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + const struct inv_icm42607_hw *hw;
> > + struct regmap *regmap;
> > +
> > + hw = i2c_get_match_data(client);
> > + if (!hw)
> > + return dev_err_probe(dev, -ENODEV, "Failed to get i2c data\n");
> > +
> > + regmap = devm_regmap_init_i2c(client, &inv_icm42607_regmap_config);
> > + if (IS_ERR(regmap))
> > + return dev_err_probe(dev, PTR_ERR(regmap),
> > + "Failed to register i2c regmap\n");
> > +
> > + return inv_icm42607_core_probe(regmap, hw, inv_icm42607_i2c_bus_setup);
> > +}
> > +
> > +static const struct i2c_device_id inv_icm42607_id[] = {
> > + {
> > + .name = "icm42607",
> > + .driver_data = (kernel_ulong_t)&inv_icm42607_hw_data,
> > + }, {
> > + .name = "icm42607p",
> > + .driver_data = (kernel_ulong_t)&inv_icm42607p_hw_data,
> > + },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, inv_icm42607_id);
> > +
> > +static const struct of_device_id inv_icm42607_of_matches[] = {
> > + {
> > + .compatible = "invensense,icm42607",
>
> I'd expect to see the data here as well. Look at implementation of i2c_get_match_data()
> and consider what would happen if there was a slightly mismatch between which devices
> were listed in each table. To avoid that fragility we normally just put
> the data pointers in both places.
I was advised in the notes for patch v16 that it could be removed. Should I go back and
undo the remove?
Thank you,
Chris
>
> > + }, {
> > + .compatible = "invensense,icm42607p",
> > + },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, inv_icm42607_of_matches);
>
>
^ permalink raw reply
* Re: [PATCH v16 02/10] dt-bindings: iio: imu: icm42600: Remove interrupts from required
From: Chris Morgan @ 2026-07-20 17:16 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Krzysztof Kozlowski, Chris Morgan, linux-iio, andy, nuno.sa,
dlechner, jean-baptiste.maneyrol, linux-rockchip, devicetree,
heiko, conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260719001848.435886e0@jic23-huawei>
On Sun, Jul 19, 2026 at 12:19:00AM +0100, Jonathan Cameron wrote:
> On Wed, 15 Jul 2026 15:34:53 -0500
> Chris Morgan <macromorgan@hotmail.com> wrote:
>
> > On Wed, Jul 15, 2026 at 08:29:44PM +0200, Krzysztof Kozlowski wrote:
> > > On 15/07/2026 16:52, Chris Morgan wrote:
> > > > On Wed, Jul 15, 2026 at 07:52:52AM +0200, Krzysztof Kozlowski wrote:
> > > >> On Mon, Jul 13, 2026 at 04:58:32PM -0500, Chris Morgan wrote:
> > > >>> From: Chris Morgan <macromorgan@hotmail.com>
> > > >>>
> > > >>> Interrupts are almost never required for IIO devices per upstream
> > > >>> maintainers. Remove interrupt as a required parameter for the
> > > >>> devicetree binding.
> > > >>
> > > >> That's an odd statement. We do require interrupts when the hardware
> > > >> requires them. We do not require interrupts, not because we have such
> > > >> policy, but because hardware does not require them.
> > > >>
> > > >> Plus, we do require interrupts when software implementing ABI requires
> > > >> them.
> > > >>
> > > >> Above commit msg is simply inaccurate and misleading. Instead, please
> > > >> use actual hardware arguments or how ABI is actually used. You must not
> > > >> introduce changes to ABI just "because" while for example making that
> > > >> ABI conflicting with existing implementation.
> > > >
> > > > I will defer then to Jonathan on the specifics of this, but from what I
> > > > can tell:
> > > >
> > > > 1) The icm42600 devices don't need an interrupt for operation other
> > > > than for buffered mode or wake on movement. One-shot should work
> > > > without it.
> > > >
> > > > 2) The existing icm42600 driver does require an interrupt however, and
> > > > refuses to bind without it. The driver could in theory be modified to
> > > > not require an interrupt though and skip using buffered mode and WoM
> > > > when no interrupt is present; however I don't plan on making these
> > > > changes at this time.
> > > >
> > > > 3) The new icm42607 driver I'm trying to upstream does not use an
> > > > interrupt, because on my current test device it's not even wired up.
> > > > On future devices that I have with this chip I may pursue using an
> > > > interrupt, but it will never be required.
> > > >
> > > > So should I go back to requiring the interrupt for all devices except
> > > > for the new driver then?
> > >
> > > You mentioned two drivers, I don't know how does this relate to them. In
> > > any case your commit msg is inaccurate and not a correct reason to make
> > > a change.
> > >
> > > Best regards,
> > > Krzysztof
> >
> > I'm confused, so again should I just go back to the way things were?
> >
> > This binding is to describe the hardware for devices using two distinct
> > drivers, the inv_icm42600 and the new (that I am trying to finish)
> > inv_icm42607 driver. The hardware requires an interrupt if you want to
> > use features such as wake-on-motion or hardware buffers. The existing
> > driver inv_icm42600 always assumes an interrupt is present and thus
> > fails to probe if one is not (making it a "requirement"). The new
> > driver I'm writing does not use the interrupt, because I don't have
> > one.
>
> For dt-bindings, look at it from the question of 'is the hardware useful
> without this interrupt?' Answer is yes for vast majority of sensors as we
> can either reduce features but still have some useful ones, or use another
> approach such as polling a ready flag to replace doing it with an interrupt.
> It is very common for boards to come out where none of the interrupts are
> wired.
>
> The only time I've seen that they are actually required for IIO stuff is
> for very simple devices where the interrupt is the data - e.g. stand alone
> threshold detectors with no ADC like functionality.
>
> All this is independent of the driver working without the interrupt.
> It is fully allowed to refuse to probe because it relies on something
> optional in the DT-binding.
>
> Jonathan
>
At this point (if it's okay with you) I'll just make sure the interrupt
is not required for the new chips supported, as the distinction between
whether the hardware needs it versus the driver is a bit lost on me;
however for now the driver will fail on all the older chips if the
interrupt isn't present.
Thank you,
Chris
>
> >
> > I'm thinking I'll just go back to the way it was previously, unless
> > Jonathan disagrees. The interrupt will be listed as required for all
> > devices using the inv_icm42600 driver, and not required for devices
> > using the inv_icm42607 driver.
> >
> > Thank you.
> >
>
^ permalink raw reply
* Re: [PATCH v6 0/2] remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
From: Mathieu Poirier @ 2026-07-20 17:18 UTC (permalink / raw)
To: Ben Levinsky
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-remoteproc, devicetree, linux-kernel, Tanmay Shah,
Michal Simek
In-Reply-To: <20260714202441.554065-1-ben.levinsky@amd.com>
On Tue, Jul 14, 2026 at 01:24:39PM -0700, Ben Levinsky wrote:
> Add a MicroBlaze/V BRAM-based remoteproc driver and corresponding binding
> for AMD soft processors located in programmable logic.
>
> The series models a soft-core processor subsystem that executes firmware
> from dual-port BRAM. The BRAM window is described in the processor-local
> address space and translated to the Linux-visible system physical address
> through the parent bus ranges property.
>
> This series depends on the remoteproc cleanup series available here:
>
> https://lore.kernel.org/linux-remoteproc/ah2aVdlsLqy9aeHP@p14s/
>
> That series adds the common WC ioremap carveout callbacks and optional
> ELF resource-table helper used by patch 2.
>
> v6:
> Patch 1, dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based
> rproc
>
> - Corrected Krzysztof Kozlowski's Reviewed-by trailer to match the tag
> provided during the v3 review.
>
> Patch 2, remoteproc: add AMD MicroBlaze/V BRAM-based remote processor
> driver
>
> - Renamed the driver source and object from amd_bram_rproc to
> amd_mbv_bram_rproc.
Applied.
Thanks,
Mathieu
>
> v5:
> Patch 1, dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based
> rproc
>
> - Updated the binding title and patch wording to use MicroBlaze/V.
> - Added Reviewed-by from Krzysztof Kozlowski.
>
> Patch 2, remoteproc: add AMD MicroBlaze/V BRAM-based remote processor
> driver
>
> - Renamed the Kconfig symbol to AMD_MBV_BRAM_REMOTEPROC.
> - Updated the Kconfig prompt to use MicroBlaze/V.
> - Removed the reset GPIO and clock sentence from the Kconfig help text.
> - Updated the driver and module descriptions to use MicroBlaze/V.
>
> v4:
> Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc
>
> - Sorted the SoC-specific compatible enum by name.
>
> Patch 2, remoteproc: add AMD BRAM-based remote processor driver
>
> - Dropped the driver-specific MAINTAINERS entry.
> - Trimmed the Kconfig help text.
> - Reused the common WC ioremap/iounmap carveout callbacks.
> - Reused the common optional ELF resource-table helper.
> - Used resource_size(&res) for the translated memory window size.
> - Kept the coredump segment address as the processor-local device
> address. The coredump path resolves segment addresses through
> rproc_da_to_va() against the registered carveout device address, while
> res.start is the Linux-visible system physical address after DT
> translation and may differ from the processor-local BRAM address.
>
> v3:
> This version updates the binding to use SoC-specific compatibles with
> the fallback form discussed on the thread.
>
> Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc
>
> - Reworked the compatible schema to use SoC-specific compatibles.
> - Added amd,versal2-bram-rproc to the supported compatible list.
> - Used xlnx,zynqmp-bram-rproc as the fallback compatible.
> - Updated the example to match the new compatible scheme.
>
> Patch 2, remoteproc: add AMD BRAM-based remote processor driver
>
> - Updated the driver OF match table to bind via the
> xlnx,zynqmp-bram-rproc fallback compatible.
>
> v2:
> This version pivots the series away from a MicroBlaze-specific binding
> and driver shape and instead models a BRAM-based soft-core processor
> subsystem more generally.
>
> This follows the upstream feedback that amd,microblaze was too tied to
> the processor architecture while also being too generic as a DT
> compatible for the hardware interface being described.
>
> Patch 1, dt-bindings: remoteproc: document AMD BRAM-based rproc
>
> - Renamed the binding away from amd,microblaze and reframed it around a
> BRAM-based soft-core processor subsystem.
> - Dropped the redundant trailing "binding" wording from the patch
> subject.
> - Rewrote the binding text to describe the hardware rather than the Linux
> remoteproc framework.
> - Reworked the example to address the original dt_binding_check
> complaints about the root node and simple-pm-bus example shape.
> - Added a clocks property for the soft-core subsystem.
>
> Patch 2, remoteproc: add AMD BRAM-based remote processor driver
>
> - Renamed the driver away from the MicroBlaze-specific name to match the
> BRAM-based binding.
> - Added clock handling for the soft-core subsystem and the matching
> COMMON_CLK dependency in Kconfig.
> - Cleaned up the reset comments and removed the success dev_dbg() message
> called out in review.
>
> Ben Levinsky (2):
> dt-bindings: remoteproc: document AMD MicroBlaze/V BRAM-based rproc
> remoteproc: add AMD MicroBlaze/V BRAM-based remote processor driver
>
> .../bindings/remoteproc/amd,bram-rproc.yaml | 105 +++++++++
> drivers/remoteproc/Kconfig | 9 +
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/amd_mbv_bram_rproc.c | 213 ++++++++++++++++++
> 4 files changed, 328 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,bram-rproc.yaml
> create mode 100644 drivers/remoteproc/amd_mbv_bram_rproc.c
>
> --
> 2.34.1
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] clk: qcom: gcc-glymur: Tie the CX power domain to controller
From: Bjorn Andersson @ 2026-07-20 17:20 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Taniya Das, Konrad Dybcio, Maulik Shah,
Dmitry Baryshkov, Jyothi Kumar Seerapu, Konrad Dybcio,
Brian Masney, Abel Vesa
Cc: Krzysztof Kozlowski, Sibi Sankar, Pankaj Patil, Akhil P Oommen,
linux-arm-msm, linux-clk, devicetree, linux-kernel,
Jishnu Prakash, Raviteja Laggyshetty, Kamal Wadhwa, Qiang Yu,
Manaf Meethalavalappu Pallikunhi, Abel Vesa
In-Reply-To: <20260715-glymur-fix-gcc-cx-scaling-v3-0-72eb5adad156@oss.qualcomm.com>
On Wed, 15 Jul 2026 16:29:13 +0300, Abel Vesa wrote:
> The suggestion of having the CX power domain tied up to the GCC
> controller started here:
>
> https://lore.kernel.org/lkml/fe210f0b-692b-4c45-afc4-fc2bc5e57854@oss.qualcomm.com/
>
> and then, for Glymur, it has been brought up here as well:
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: glymur: Add CX power domain to GCC
commit: 2edbea82d8edbddb2a235b8f988f17b86f075476
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] Add TRNG support for Glymur SoC
From: Bjorn Andersson @ 2026-07-20 17:21 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Konrad Dybcio, Dmitry Baryshkov,
Harshal Dev
Cc: Kuldeep Singh, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <20260424-glymur_trng_enablement-v2-0-0603cbe68440@oss.qualcomm.com>
On Fri, 24 Apr 2026 14:05:06 +0530, Harshal Dev wrote:
> Document and add the device-tree node to enable TRNG for Glymur SoC.
>
>
Applied, thanks!
[2/2] arm64: dts: qcom: glymur: add TRNG node
commit: 5d7ebb1f36ad8a51f4e60819a8c5bddf04a8d1a2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: enable ETR and CTCU devices
From: Bjorn Andersson @ 2026-07-20 17:21 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tingwei Zhang, Jie Gan
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260714-add-ctcu-etr-for-glymur-v1-1-791de63c0713@oss.qualcomm.com>
On Tue, 14 Jul 2026 14:50:58 +0800, Jie Gan wrote:
> Embedded Trace Router(ETR) is working as a DDR memory sink to collect
> tracing data from source device and the CTCU device serves as the
> control unit for the ETR device.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: glymur: enable ETR and CTCU devices
commit: 394b63a2bbf2d1e98d411ee5ec52d68f66bbf984
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] Glymur DT QoL
From: Bjorn Andersson @ 2026-07-20 17:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260716-topic-smb2370_port2-v1-0-83d02b2ba4b0@oss.qualcomm.com>
On Thu, 16 Jul 2026 19:33:41 +0200, Konrad Dybcio wrote:
> Two tiny no-dependencies changes that have no business waiting for
> other patches to settle.
>
>
Applied, thanks!
[1/2] arm64: dts: qcom: smb2370: Disable SMB2370_2 by default
commit: f922f586c67d2b2c5d476679a4afaebbc4126817
[2/2] arm64: dts: qcom: glymur: Add PCIe port compatibles and ports
commit: e9d928da6f25e2c0d926c15b66fab52602e86f8f
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B
From: Bjorn Andersson @ 2026-07-20 17:21 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260609141608.354186-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 09 Jun 2026 16:16:09 +0200, Krzysztof Kozlowski wrote:
> According to user manual / programming guide there is no separate PCIe
> phy 3A and 3B, but one 8-lane QMP PCIe Gen5 PHY which consists of two
> 4-lane blocks. This is also visible in memory map, where the 0xf00000
> is marked as the main block with additional sub blocks for each 4-lane
> phys.
>
> Describing the sub phys without the rest is not correct from hardware
> description, even if it works.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: glymur: Drop fake PCIe phy 3B
commit: d3ca4252d21ec85ada29689f78d13d4596749e3a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 4/5] riscv: dts: thead: Add IO labels for the IO expansion on I2C1
From: Icenowy Zheng @ 2026-07-20 17:28 UTC (permalink / raw)
To: Drew Fustini
Cc: Guo Ren, Fu Wei, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MoeLeak, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
devicetree, linux-kernel, Emil Renner Berthing
In-Reply-To: <al5TWhx7pLIZguAc@gen8>
在 2026-07-20一的 09:56 -0700，Drew Fustini写道：
> On Fri, Jul 17, 2026 at 12:11:23PM +0800, Icenowy Zheng wrote:
> >
> >
> > 于 2026年7月17日 GMT+08:00 04:52:19，Drew Fustini <fustini@kernel.org>
> > 写道：
> > > On Tue, Jul 14, 2026 at 03:45:14PM +0800, Icenowy Zheng wrote:
> > > > From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> > > >
> > > > Add labels for GPIOs on the IO expansion chip on the I2C1 bus.
> > > >
> > > > Signed-off-by: Emil Renner Berthing
> > > > <emil.renner.berthing@canonical.com>
> > > > [Icenowy: Splitted off the patch adding all 3 IO expansions]
> > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > > ---
> > > > arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts | 8 ++++++++
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > b/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > index 74b120c6b063a..78f5979a56c14 100644
> > > > --- a/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > +++ b/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > @@ -128,6 +128,14 @@ ioexp2: gpio@18 {
> > > > reg = <0x18>;
> > > > gpio-controller;
> > > > #gpio-cells = <2>;
> > > > + gpio-line-names = "",
> > > > + "cam0_reset",
> > > > + "cam1_reset",
> > > > + "cam2_reset",
> > > > + "wl_host_wake",
> > >
> > > I am not sure the line name really matters all that, but it seems
> > > that
> > > pin 4 is also used as a reset gpio:
> >
> > The "host" here is subject, which means "this pins is used by the
> > host to wake the wl".
> >
> > Maybe I should take the schematics name, "wl_host_wake_dev"? Or use
> > another name on the page for Wi-Fi, "wl_reg_on"?
>
> I thnk "wl_host_wake_dev" is slightly better in terms of searching
> the
> PDF [1] and finding the "IO Expansion 2" section. This is minor
> change
> so I can just fix up when applying if you are okay with that.
Of course I am okay with this.
Thanks,
Icenowy
>
> Thanks,
> Drew
>
> [1] https://dl.sipeed.com/shareURL/LICHEE/licheepi4a/02_Schematic
^ permalink raw reply
* Re: [PATCH 3/3] nvmem: mtk-efuse: add mt6572 support
From: Roman Vivchar @ 2026-07-20 17:31 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <LQrjqkJAVzl-TSaOAypAQdfM8rR4F59aSX5yJIw8S3neOhFlPmTeFrW1PBK4JDos7v7VvL8nTblX22lK78U0FlVE_bwuOJYR36CK3eDE5RM=@protonmail.com>
On Monday, July 20th, 2026 at 4:33 PM, Roman Vivchar <rva333@protonmail.com> wrote:
...
> Something like this:
> - mfgcfg
> ^- mfg_pre ('safe' UNIVPLL div or 'unsafe' mfg mux)
> ^- mfg (if you're here and your chip is NOT mt6572w then be prepared
> for crashes)
> ^- whpll (or any other parent, but downstream uses WHPLL as GPU
> clock source)
Oops, WHPLL sits behind the gate, so the clock tree is this:
- mfgcfg
^- mfg_pre ('safe' UNIVPLL div or 'unsafe' mfg mux)
^- mfg (if you're here and your chip is NOT mt6572w then be prepared
for crashes)
^- mfg_pre_whpll_500m (or any other parent, but downstream uses
WHPLL as GPU clock source)
^- whpll
(Using 500m is a bad idea for the PLL which can change frequency, but
I have to revisit clock tree once again to make a better decision before
sending mt6572 clocks to the upstream).
^ permalink raw reply
* [PATCH 0/2] iio: imu: inv_icm42600: add support for icm42630
From: Jorijn van der Graaf @ 2026-07-20 17:34 UTC (permalink / raw)
To: Jonathan Cameron, Jean-Baptiste Maneyrol
Cc: Jorijn van der Graaf, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Luca Weiss, linux-iio, devicetree, linux-kernel
The TDK InvenSense ICM-42630 is a 6-axis IMU of the ICM-42600 family,
used in the Fairphone 6. The existing inv_icm42600 driver drives it
unmodified once its WHOAMI value is known, so this is just the
compatible plus the chip id / WHOAMI table entries.
The part appears to be a mobile SKU and has no public datasheet. The
name comes from the Fairphone 6 schematics and platform documentation;
the WHOAMI value 0x0C was read from the hardware over both SPI and
I2C, and the chip's bank 0 register defaults match the ICM-42600
family layout. Jean-Baptiste, if you are able to confirm the part name
and WHOAMI value from the TDK side, that would be very welcome.
Tested on the Fairphone 6: patch 2 applied to the device's 7.1-based
kernel (with the id-table hunks adjusted to that base's style) drives
the chip over a bit-banged SPI bus with INT1 wired to the SoC - probe,
accelerometer, gyroscope and temperature raw reads, all full-scale
ranges, multiple sampling frequencies, and watermark-paced FIFO reads
through the INT1 interrupt. The accelerometer full scale was cross-checked against
gravity (~2048 LSB/g at the default range, matching +-16g); the
+-2000 dps gyroscope full scale is inferred from family membership,
pending confirmation from TDK.
The series is based on iio/togreg (base-commit below); on that base it
builds (arm64 defconfig with the driver as modules, W=1 clean on the
driver directory) and dt_binding_check passes.
Note: Chris Morgan's in-flight ICM-42607 series [1] adds entries to
the same binding enum; the overlap is context-only (different lines)
and trivial for whichever lands second.
[1] https://lore.kernel.org/all/20260716182637.24310-1-macroalpha82@gmail.com/
The Fairphone 6 board DTS nodes will follow separately via the qcom
tree once this lands.
Jorijn van der Graaf (2):
dt-bindings: iio: imu: icm42600: add icm42630
iio: imu: inv_icm42600: add support for icm42630
.../devicetree/bindings/iio/imu/invensense,icm42600.yaml | 1 +
drivers/iio/imu/inv_icm42600/inv_icm42600.h | 2 ++
drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 5 +++++
drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 4 ++++
drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c | 4 ++++
5 files changed, 16 insertions(+)
base-commit: 036d96ceec6d966339aea34d034420991e24cfac
--
2.55.0
^ permalink raw reply
* [PATCH 1/2] dt-bindings: iio: imu: icm42600: add icm42630
From: Jorijn van der Graaf @ 2026-07-20 17:34 UTC (permalink / raw)
To: Jonathan Cameron, Jean-Baptiste Maneyrol
Cc: Jorijn van der Graaf, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Luca Weiss, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260720173411.82979-1-jorijnvdgraaf@catcrafts.net>
The TDK InvenSense ICM-42630 is a 6-axis IMU of the ICM-42600 family,
found e.g. in the Fairphone 6. Document its compatible.
A fallback compatible to a sibling is not usable: the part reports its
own WHOAMI register value, which software validates against the
compatible.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
.../devicetree/bindings/iio/imu/invensense,icm42600.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
index 119e28a833fd..add3a7fef09d 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
@@ -31,6 +31,7 @@ properties:
- invensense,icm42602
- invensense,icm42605
- invensense,icm42622
+ - invensense,icm42630
- invensense,icm42631
- invensense,icm42686
- invensense,icm42688
--
2.55.0
^ permalink raw reply related
* [PATCH 2/2] iio: imu: inv_icm42600: add support for icm42630
From: Jorijn van der Graaf @ 2026-07-20 17:34 UTC (permalink / raw)
To: Jonathan Cameron, Jean-Baptiste Maneyrol
Cc: Jorijn van der Graaf, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Luca Weiss, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260720173411.82979-1-jorijnvdgraaf@catcrafts.net>
The TDK InvenSense ICM-42630 is a 6-axis IMU of the ICM-42600 family,
found e.g. in the Fairphone 6. It is register-compatible with its
siblings (the existing driver works on it unmodified) and reports
WHOAMI value 0x0C.
The part appears to be a mobile SKU and has no public datasheet: the
identity comes from the Fairphone 6 platform documentation and
schematics naming the part, and the WHOAMI value was read from the
hardware, whose bank 0 register defaults match the ICM-42600 family
layout.
Add the chip id, WHOAMI value and I2C/SPI match entries, using the
family default configuration like the ICM-42631.
Tested on the Fairphone 6 via a backport of this change to the
device's 7.1-based kernel (only the id-table style adjusted to that
base), on a bit-banged SPI bus with INT1 wired to the SoC: probe,
accelerometer, gyroscope and temperature raw reads, all full-scale
ranges, multiple sampling frequencies, and watermark-paced FIFO reads
through the INT1 interrupt.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
---
drivers/iio/imu/inv_icm42600/inv_icm42600.h | 2 ++
drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 5 +++++
drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 4 ++++
drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c | 4 ++++
4 files changed, 15 insertions(+)
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
index b55d993f0264..349de5458581 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
@@ -28,6 +28,7 @@ enum inv_icm42600_chip {
INV_CHIP_ICM42622,
INV_CHIP_ICM42688,
INV_CHIP_ICM42631,
+ INV_CHIP_ICM42630,
INV_CHIP_NB,
};
@@ -386,6 +387,7 @@ struct inv_icm42600_sensor_state {
#define INV_ICM42600_WHOAMI_ICM42622 0x46
#define INV_ICM42600_WHOAMI_ICM42688 0x47
#define INV_ICM42600_WHOAMI_ICM42631 0x5C
+#define INV_ICM42600_WHOAMI_ICM42630 0x0C
/* User bank 1 (MSB 0x10) */
#define INV_ICM42600_REG_SENSOR_CONFIG0 0x1003
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
index dc97d8a274e3..9a31ca3615b3 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
@@ -177,6 +177,11 @@ static const struct inv_icm42600_hw inv_icm42600_hw[INV_CHIP_NB] = {
.name = "icm42631",
.conf = &inv_icm42600_default_conf,
},
+ [INV_CHIP_ICM42630] = {
+ .whoami = INV_ICM42600_WHOAMI_ICM42630,
+ .name = "icm42630",
+ .conf = &inv_icm42600_default_conf,
+ },
};
const struct iio_mount_matrix *
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
index 28552d2db91d..c413904c8680 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
@@ -81,6 +81,7 @@ static const struct i2c_device_id inv_icm42600_id[] = {
{ .name = "icm42622", .driver_data = INV_CHIP_ICM42622 },
{ .name = "icm42688", .driver_data = INV_CHIP_ICM42688 },
{ .name = "icm42631", .driver_data = INV_CHIP_ICM42631 },
+ { .name = "icm42630", .driver_data = INV_CHIP_ICM42630 },
{ }
};
MODULE_DEVICE_TABLE(i2c, inv_icm42600_id);
@@ -107,6 +108,9 @@ static const struct of_device_id inv_icm42600_of_matches[] = {
}, {
.compatible = "invensense,icm42631",
.data = (void *)INV_CHIP_ICM42631,
+ }, {
+ .compatible = "invensense,icm42630",
+ .data = (void *)INV_CHIP_ICM42630,
},
{ }
};
diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c
index faf743bc6444..a1d12ce3bf87 100644
--- a/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c
+++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c
@@ -78,6 +78,7 @@ static const struct spi_device_id inv_icm42600_id[] = {
{ .name = "icm42622", .driver_data = INV_CHIP_ICM42622 },
{ .name = "icm42688", .driver_data = INV_CHIP_ICM42688 },
{ .name = "icm42631", .driver_data = INV_CHIP_ICM42631 },
+ { .name = "icm42630", .driver_data = INV_CHIP_ICM42630 },
{ }
};
MODULE_DEVICE_TABLE(spi, inv_icm42600_id);
@@ -104,6 +105,9 @@ static const struct of_device_id inv_icm42600_of_matches[] = {
}, {
.compatible = "invensense,icm42631",
.data = (void *)INV_CHIP_ICM42631,
+ }, {
+ .compatible = "invensense,icm42630",
+ .data = (void *)INV_CHIP_ICM42630,
},
{ }
};
--
2.55.0
^ permalink raw reply related
* Re: [PATCH 2/2] media: i2c: Add driver for Sony IMX662 sensor
From: Dave Stevenson @ 2026-07-20 17:39 UTC (permalink / raw)
To: Jai Luthra
Cc: Alexander Shiyan, linux-media, devicetree, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sakari Ailus,
Hans Verkuil, Hans de Goede, Tetsuya Nomura,
Manivannan Sadhasivam
In-Reply-To: <178455866124.1426769.18237320419273419942@freya>
Hi Jai
On Mon, 20 Jul 2026 at 15:44, Jai Luthra <jai.luthra@ideasonboard.com> wrote:
>
> Hi Dave, Alexander,
>
> Quoting Dave Stevenson (2026-03-13 01:20:15)
> > Hi Alexander
> >
> > On Thu, 12 Mar 2026 at 15:11, Alexander Shiyan
> > <eagle.alexander923@gmail.com> wrote:
> > >
> > > This patch adds a V4L2 subdevice driver for the Sony IMX662 CMOS image
> > > sensor. The sensor has a native resolution of 1936x1100 (effective
> > > 1920x1080) and can achieve up to 90 frames per second depending on
> > > the configuration. The driver supports:
> > > - MIPI CSI-2 with 2 or 4 data lanes.
> > > - RAW10 and RAW12 formats (both colour and monochrome).
> > > - Controls: exposure, analogue gain, horizontal/vertical blanking,
> > > horizontal/vertical flip, brightness.
> > > - A placeholder V4L2_CID_HDR_SENSOR_MODE control for future Clear HDR
> > > support (the actual HDR modes are not yet implemented).
> > > - Runtime PM.
> > > - Cropping via the selection API.
> > > - Multiple link frequencies selectable via device tree.
> > >
> > > Tested on ARM64 Rockchip RK3568 platform with a 24 MHz external clock
> > > and various link frequencies.
> >
> > Interesting timing as I've been looking at IMX662 too, but on a Raspberry Pi.
> > FWIW my driver is at
> > https://github.com/6by9/linux/blob/rpi-6.12.y-imx662/drivers/media/i2c/imx662.c
> >
>
> I saw libcamera patches for IMX676,
IMX676? I assume that's a typo.
> does the below branch have the latest
> driver you plan to post as v2?
>
> https://github.com/6by9/linux/blob/rpi-6.18.y-imx662-mainline-clean/drivers/media/i2c/imx662.c
That's a downstream Pi tree. My mainline branch is
https://github.com/6by9/linux/tree/mainline_imx662 and is basically
the patches I intend to send.
There is one niggle to resolve first in imx662_ctrls_init. There is
currently a catch-22 in setting up the state vs initialising the
blanking and exposure ranges as they refer to each other. I need to
come back and look at that one.
> > Comments are based on brief testing and reading of the code. This is
> > not a full review.
> >
> > > Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
>
> [...]
>
> > > +static int imx662_set_selection(struct v4l2_subdev *sd,
> > > + struct v4l2_subdev_state *sd_state,
> > > + struct v4l2_subdev_selection *sel)
> > > +{
>
> Can we keep cropping and binning out of the initial driver,
There is no binning currently implemented in this driver, only cropping.
> and implement
> it using the common raw sensor model directly?
>
> I did it for IMX678 [1] on Sakari's suggestion [2]. The two sensors are
> quite similar, so I'm happy to help in whatever way I can on getting this
> working with the new model too :-)
Is this effectively saying that linux-media is closed to sensor
drivers not adopting the common raw sensor model, even though AIUI
that isn't ready yet? I can accept that for a period, but how long is
it reasonable for that to be the case? A year?
With all due respect to those involved, the series has been around so
long in various guises that it's a case of I'll believe it when I see
it merged.
There are already a number of sensor drivers in the tree that support
set_selection (imx296 being the main one I care about). Presumably
there is a plan for how to migrate those to work with the common
sensor model without regression for existing users. Is there a reason
that plan isn't also valid for imx662 and imx678?
I would offer to review the common raw sensor patches, but as so much
of it is core framework stuff and so is outside my area of knowledge.
I guess I can do the same as your imx678 branch and give it a go for a
Tested-by, but that feels fairly limited in scope.
Have you got a libcamera branch that supports the new model for imx678?
Thanks
Dave
> [1]: https://lore.kernel.org/all/20260703-imx678-meta-v1-0-7c4924a0df05@ideasonboard.com/
> [2]: https://lore.kernel.org/all/ag7oq5jO5G0rwvzb@kekkonen.localdomain/
>
> Thanks,
> Jai
>
> > > + struct imx662 *imx662 = to_imx662(sd);
> > > + struct v4l2_rect rect = sel->r;
> > > + struct v4l2_rect *try_crop;
> > > + struct v4l2_mbus_framefmt *try_fmt;
> > > + u32 max_left, max_top;
> > > +
> > > + if (sel->target != V4L2_SEL_TGT_CROP)
> > > + return -EINVAL;
> > > +
> > > + max_left = IMX662_PIXEL_ARRAY_LEFT + IMX662_PIXEL_ARRAY_WIDTH -
> > > + IMX662_MIN_CROP_WIDTH;
> > > + max_top = IMX662_PIXEL_ARRAY_TOP + IMX662_PIXEL_ARRAY_HEIGHT -
> > > + IMX662_MIN_CROP_HEIGHT;
> > > +
> > > + rect.left = clamp_t(u32, rect.left, IMX662_PIXEL_ARRAY_LEFT, max_left);
> > > + rect.top = clamp_t(u32, rect.top, IMX662_PIXEL_ARRAY_TOP, max_top);
> > > +
> > > + rect.width =
> > > + clamp_t(u32,
> > > + round_down(rect.width, IMX662_CROP_WIDTH_STEP),
> > > + IMX662_MIN_CROP_WIDTH, IMX662_PIXEL_ARRAY_WIDTH);
> > > + rect.height =
> > > + clamp_t(u32,
> > > + round_down(rect.height, IMX662_CROP_HEIGHT_STEP),
> > > + IMX662_MIN_CROP_HEIGHT, IMX662_PIXEL_ARRAY_HEIGHT);
> > > +
> > > + if (rect.left + rect.width - 1 >
> > > + IMX662_PIXEL_ARRAY_LEFT + IMX662_PIXEL_ARRAY_WIDTH - 1)
> > > + rect.left =
> > > + IMX662_PIXEL_ARRAY_LEFT + IMX662_PIXEL_ARRAY_WIDTH -
> > > + rect.width;
> > > + if (rect.top + rect.height - 1 >
> > > + IMX662_PIXEL_ARRAY_TOP + IMX662_PIXEL_ARRAY_HEIGHT - 1)
> > > + rect.top =
> > > + IMX662_PIXEL_ARRAY_TOP + IMX662_PIXEL_ARRAY_HEIGHT -
> > > + rect.height;
> > > +
> > > + if (sel->flags & V4L2_SEL_FLAG_GE) {
> > > + if (rect.width < sel->r.width) {
> > > + u32 new_width = rect.width + IMX662_CROP_WIDTH_STEP;
> > > +
> > > + if (new_width <= IMX662_PIXEL_ARRAY_WIDTH)
> > > + rect.width = new_width;
> > > + }
> > > + if (rect.height < sel->r.height) {
> > > + u32 new_height = rect.height + IMX662_CROP_HEIGHT_STEP;
> > > +
> > > + if (new_height <= IMX662_PIXEL_ARRAY_HEIGHT)
> > > + rect.height = new_height;
> > > + }
> > > + }
> > > +
> > > + if (sel->flags & V4L2_SEL_FLAG_LE) {
> > > + if (rect.width > sel->r.width &&
> > > + rect.width >= IMX662_MIN_CROP_WIDTH +
> > > + IMX662_CROP_WIDTH_STEP)
> > > + rect.width -= IMX662_CROP_WIDTH_STEP;
> > > + if (rect.height > sel->r.height &&
> > > + rect.height >= IMX662_MIN_CROP_HEIGHT +
> > > + IMX662_CROP_HEIGHT_STEP)
> > > + rect.height -= IMX662_CROP_HEIGHT_STEP;
> > > + }
> > > +
> > > + if (rect.width < IMX662_MIN_CROP_WIDTH ||
> > > + rect.height < IMX662_MIN_CROP_HEIGHT)
> > > + return -EINVAL;
> > > +
> > > + if (sel->which == V4L2_SUBDEV_FORMAT_TRY) {
> > > + try_crop = v4l2_subdev_state_get_crop(sd_state, sel->pad);
> > > + *try_crop = rect;
> > > +
> > > + try_fmt = v4l2_subdev_state_get_format(sd_state, sel->pad);
> > > + if (try_fmt) {
> > > + try_fmt->width = rect.width;
> > > + try_fmt->height = rect.height;
> > > + }
> > > + } else {
> > > + if (imx662->streaming)
> > > + return -EBUSY;
> > > +
> > > + if (imx662->crop.left == rect.left &&
> > > + imx662->crop.top == rect.top &&
> > > + imx662->crop.width == rect.width &&
> > > + imx662->crop.height == rect.height) {
> > > + sel->r = rect;
> > > + return 0;
> > > + }
> > > +
> > > + imx662->crop = rect;
> > > +
> > > + try_fmt = v4l2_subdev_state_get_format(sd_state, sel->pad);
> > > + if (try_fmt) {
> > > + try_fmt->width = rect.width;
> > > + try_fmt->height = rect.height;
> > > + }
> > > +
> > > + imx662_set_framing_limits(imx662);
> > > + }
> > > +
> > > + sel->r = rect;
> > > +
> > > + return 0;
> > > +}
>
> [...]
^ permalink raw reply
* Re: [PATCH 0/3] SM8450 IPA support
From: Esteban Urrutia @ 2026-07-20 17:41 UTC (permalink / raw)
To: Konrad Dybcio, Alex Elder, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alex Elder
Cc: linux-arm-msm, devicetree, linux-kernel, netdev
In-Reply-To: <9fc68256-6790-4889-b1d3-1802de852d96@oss.qualcomm.com>
On 7/20/26 10:21 AM, Konrad Dybcio wrote:
> OK you meant the qcom,ipa-q6-smem-size property. I can't find what
> it corresponds to, the name of the associated IOMMU stream
> unfortunately doesn't hint at anything useful either..
Perhaps this can help:
https://github.com/LineageOS/android_kernel_qcom_sm8450-modules/blob/lineage-20/qcom/opensource/dataipa/drivers/platform/msm/ipa/ipa_v3/ipa.c#L10950-L11010
Regards,
Esteban
^ permalink raw reply
* [PATCH 1/2] arm64: dts: allwinner: a523: Add missing SPDIF pin
From: Per Larsson @ 2026-07-20 17:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
Cc: Per Larsson
When spdif support was added for the Allwinner A523 family of SoCs, only
two of the three possible pins were added to the dtsi, since the third
would clash with the first ethernet port (emac0)
However, some devices don't use emac0 and instead use emac1 for the only
available ethernet port, leaving the pin free to use for spdif.
Add the missing pin to the dtsi so such devices can (later) use it
Signed-off-by: Per Larsson <per@palvencia.se>
---
arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
index ca6a16807049..7370e8ed24ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
@@ -216,6 +216,13 @@ spdif_out_pb_pin: spdif-pb-pin {
allwinner,pinmux = <2>;
};
+ /omit-if-no-ref/
+ spdif_out_ph_pin: spdif-ph-pin {
+ pins = "PH7";
+ function = "spdif";
+ allwinner,pinmux = <4>;
+ };
+
/omit-if-no-ref/
spdif_out_pi_pin: spdif-pi-pin {
pins = "PI10";
--
2.48.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: allwinner: a523: Add SPDIF to x96qpro+ device
From: Per Larsson @ 2026-07-20 17:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
Cc: Per Larsson
In-Reply-To: <20260720174253.7686-1-per@palvencia.se>
The X96QPro+ TV box uses the PH7 pin for its SPDIF output
Add the relevant bits to the dts now that the dtsi knows about the pin
Signed-off-by: Per Larsson <per@palvencia.se>
---
.../dts/allwinner/sun55i-h728-x96qpro+.dts | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
index a96927fbdadd..b172985583f8 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
@@ -44,6 +44,24 @@ reg_vcc3v3: vcc3v3 {
vin-supply = <®_vcc5v>;
regulator-always-on;
};
+
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "spdif-out";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
};
&ehci0 {
@@ -275,6 +293,12 @@ &r_pio {
vcc-pm-supply = <®_aldo3>;
};
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_out_ph_pin>;
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.48.1
^ permalink raw reply related
* Re: [PATCH 6/8] arm64: dts: freescale: imx8mm-verdin: Add Toradex OV5640 CSI Cameras
From: Frank Li @ 2026-07-20 18:16 UTC (permalink / raw)
To: Ernest Van Hoecke
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Francesco Dolcini,
imx, linux-arm-kernel, devicetree, linux-kernel,
Ernest Van Hoecke
In-Reply-To: <20260713-v1-verdin-imx8mm-dtbos-v1-6-4acd63db4504@toradex.com>
On Mon, Jul 13, 2026 at 05:06:27PM +0200, Ernest Van Hoecke wrote:
> From: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>
> Add device tree overlays for the Toradex OV5640 CSI Camera on Verdin CSI_1.
>
> The default overlay describes the current CSI Camera Set 5MP OV5640 with a
> 27 MHz on-board oscillator. Add a separate 24 MHz overlay for the legacy
> camera module.
>
> Link: https://developer.toradex.com/hardware/accessories/cameras/csi-camera-module-5mp-ov5640-arducam
> Link: https://www.toradex.com/accessories/csi-camera-ov5640
> Link: https://developer.toradex.com/hardware/legacy-products/other/csi-camera-module-5mp-ov5640/
> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 6 ++
> .../dts/freescale/imx8mm-verdin-ov5640-24mhz.dtso | 17 +++++
> .../boot/dts/freescale/imx8mm-verdin-ov5640.dtsi | 78 ++++++++++++++++++++++
> .../boot/dts/freescale/imx8mm-verdin-ov5640.dtso | 18 +++++
> 4 files changed, 119 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index c465aa19e526..ed3d678e7c5e 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -189,6 +189,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-mallow.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-yavia-dsi-to-hdmi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-yavia.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-zinnia.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-ov5640-24mhz.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-ov5640.dtbo
Need not add dtbo here,
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-ov5640-24mhz.dtb can
auto dtbo build dtbo.
check other dtbo.
Frank
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-panel-cap-touch-10inch-dsi.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-panel-cap-touch-7inch-dsi.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dahlia-dsi-to-hdmi.dtb
> @@ -197,6 +199,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dahlia.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-dsi-to-hdmi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-nau8822-btl.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-ov5640-24mhz.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-ov5640.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev-panel-cap-touch-7inch-dsi.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-ivy.dtb
> @@ -217,6 +221,8 @@ imx8mm-verdin-wifi-dev-dsi-to-hdmi-dtbs := imx8mm-verdin-wifi-dev.dtb imx8mm-ver
> imx8mm-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch-dtbs := imx8mm-verdin-wifi-dev.dtb \
> imx8mm-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
> imx8mm-verdin-wifi-dev-nau8822-btl-dtbs := imx8mm-verdin-wifi-dev.dtb imx8mm-verdin-dev-nau8822-btl.dtbo
> +imx8mm-verdin-wifi-dev-ov5640-24mhz-dtbs := imx8mm-verdin-wifi-dev.dtb imx8mm-verdin-ov5640-24mhz.dtbo
> +imx8mm-verdin-wifi-dev-ov5640-dtbs := imx8mm-verdin-wifi-dev.dtb imx8mm-verdin-ov5640.dtbo
> imx8mm-verdin-wifi-dev-panel-cap-touch-7inch-dsi-dtbs := imx8mm-verdin-wifi-dev.dtb \
> imx8mm-verdin-panel-cap-touch-7inch-dsi.dtbo
> imx8mm-verdin-wifi-yavia-dsi-to-hdmi-dtbs := imx8mm-verdin-wifi-yavia.dtb imx8mm-verdin-dsi-to-hdmi.dtbo
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640-24mhz.dtso b/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640-24mhz.dtso
> new file mode 100644
> index 000000000000..f479b709c151
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640-24mhz.dtso
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/*
> + * Copyright (c) Toradex
> + *
> + * Toradex CSI Camera Module 5MP OV5640 on Verdin CSI_1.
> + *
> + * https://developer.toradex.com/hardware/legacy-products/other/csi-camera-module-5mp-ov5640/
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include "imx8mm-verdin-ov5640.dtsi"
> +
> +&clock_camera {
> + clock-frequency = <24000000>;
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640.dtsi
> new file mode 100644
> index 000000000000..0632bdb1b679
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640.dtsi
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/*
> + * Copyright (c) Toradex
> + *
> + * Common device tree include for Toradex OV5640 CSI camera on Verdin CSI_1.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&{/} {
> + clock_camera: clock-camera {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + };
> +
> + regulator_camera: regulator-camera {
> + compatible = "regulator-fixed";
> + /* Verdin GPIO_8_CSI (SODIMM 222) - CSI_1_PWR_EN */
> + gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-name = "V_CSI";
> + startup-delay-us = <5000>;
> + };
> +};
> +
> +&csi {
> + status = "okay";
> +};
> +
> +/* Verdin I2C_4_CSI */
> +&i2c3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "okay";
> +
> + camera@3c {
> + compatible = "ovti,ov5640";
> + reg = <0x3c>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio5>, <&pinctrl_gpio6>;
> + clocks = <&clock_camera>;
> + clock-names = "xclk";
> + AVDD-supply = <®ulator_camera>;
> + DOVDD-supply = <®ulator_camera>;
> + DVDD-supply = <®ulator_camera>;
> + /* Verdin GPIO_6_CSI (SODIMM 218) - CSI_1_PWDN */
> + powerdown-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
> + /* Verdin GPIO_5_CSI (SODIMM 216) - CSI_1_RESET# */
> + reset-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> +
> + port {
> + ov5640_to_mipi_csi2: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <&imx8mm_mipi_csi_in>;
> + };
> + };
> + };
> +};
> +
> +&mipi_csi {
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + imx8mm_mipi_csi_in: endpoint {
> + data-lanes = <1 2>;
> + remote-endpoint = <&ov5640_to_mipi_csi2>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640.dtso b/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640.dtso
> new file mode 100644
> index 000000000000..d56234913b61
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-ov5640.dtso
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/*
> + * Copyright (c) Toradex
> + *
> + * Toradex CSI Camera Set 5MP OV5640 on Verdin CSI_1.
> + *
> + * https://developer.toradex.com/hardware/accessories/cameras/csi-camera-module-5mp-ov5640-arducam
> + * https://www.toradex.com/accessories/csi-camera-ov5640
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include "imx8mm-verdin-ov5640.dtsi"
> +
> +&clock_camera {
> + clock-frequency = <27000000>;
> +};
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 1/5] riscv: dts: thead: th1520: remove pclk for I2C1
From: Drew Fustini @ 2026-07-20 18:25 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Guo Ren, Fu Wei, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MoeLeak, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
devicetree, linux-kernel, Icenowy Zheng
In-Reply-To: <20260714074515.1959352-2-zhengxingda@iscas.ac.cn>
On Tue, Jul 14, 2026 at 03:45:11PM +0800, Icenowy Zheng wrote:
> The I2C1 node added previously to the th1520.dtsi file has two clocks
> set -- one "ref" clock (CLK_I2C1) and one "pclk" (CLK_PERI_APB_PCLK).
>
> However, the CLK_I2C1 clock is just a clock gate with the
> CLK_PERI_APB_PCLK clock as its input. In addition, when it's gated,
> reading registers from the I2C controller returns fixed value (the last
> read value) for all registers. These facts indicate that the CLK_I2C1
> clock is the true APB clock fed into the I2C controller instead of a
> dedicated reference clock.
>
> Leave only the CLK_I2C1 clock as the `clocks` property of the I2C1
> device node and remove `clock-names` property, which represents the I2C
> controller only takes a single clock both as the APB clock and the
> reference clock.
>
> Fixes: 2f60e3516330 ("riscv: dts: thead: Add TH1520 I2C1 controller")
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
> arch/riscv/boot/dts/thead/th1520.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi b/arch/riscv/boot/dts/thead/th1520.dtsi
> index 94932c51b7e39..db23624696b73 100644
> --- a/arch/riscv/boot/dts/thead/th1520.dtsi
> +++ b/arch/riscv/boot/dts/thead/th1520.dtsi
> @@ -415,8 +415,7 @@ i2c1: i2c@ffe7f24000 {
> compatible = "thead,th1520-i2c", "snps,designware-i2c";
> reg = <0xff 0xe7f24000 0x0 0x4000>;
> interrupts = <45 IRQ_TYPE_LEVEL_HIGH>;
> - clocks = <&clk CLK_I2C1>, <&clk CLK_PERI_APB_PCLK>;
> - clock-names = "ref", "pclk";
> + clocks = <&clk CLK_I2C1>;
> #address-cells = <1>;
> #size-cells = <0>;
> status = "disabled";
> --
> 2.52.0
Reviewed-by: Drew Fustini <fustini@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/5] riscv: dts: thead: Add TH1520 I2C nodes
From: Drew Fustini @ 2026-07-20 18:26 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Guo Ren, Fu Wei, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MoeLeak, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
devicetree, linux-kernel, Icenowy Zheng, Thomas Bonnefille,
Drew Fustini
In-Reply-To: <20260714074515.1959352-3-zhengxingda@iscas.ac.cn>
On Tue, Jul 14, 2026 at 03:45:12PM +0800, Icenowy Zheng wrote:
> From: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
>
> Add nodes for the remaining five I2C controllers on the T-Head TH1520
> RISCV SoC.
>
> Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
> Reviewed-by: Drew Fustini <dfustini@tenstorrent.com>
> [Icenowy: rebase and reword commit message to exclude I2C1]
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
> arch/riscv/boot/dts/thead/th1520.dtsi | 50 +++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
Reviewed-by: Drew Fustini <fustini@kernel.org>
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v2 3/5] riscv: dts: thead: lpi4a: sort nodes
From: Drew Fustini @ 2026-07-20 18:26 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Guo Ren, Fu Wei, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MoeLeak, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
devicetree, linux-kernel, Icenowy Zheng
In-Reply-To: <20260714074515.1959352-4-zhengxingda@iscas.ac.cn>
On Tue, Jul 14, 2026 at 03:45:13PM +0800, Icenowy Zheng wrote:
> Although "D", "H" and "I" are earlier in the alphabet than "P", the DPU,
> HDMI and I2C1 nodes were added after PADCTRL nodes in the Lichee Pi 4A
> device tree; in addition the PADCTRL1 node is placed before the
> PADCTRL0 one.
>
> Sort the nodes in this device tree.
>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
> .../boot/dts/thead/th1520-lichee-pi-4a.dts | 72 +++++++++----------
> 1 file changed, 36 insertions(+), 36 deletions(-)
Reviewed-by: Drew Fustini <fustini@kernel.org>
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v2 4/5] riscv: dts: thead: Add IO labels for the IO expansion on I2C1
From: Drew Fustini @ 2026-07-20 18:27 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Guo Ren, Fu Wei, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MoeLeak, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
devicetree, linux-kernel, Emil Renner Berthing
In-Reply-To: <cb14e077de1722d1c36cd0bd877952289dc90abb.camel@icenowy.me>
On Tue, Jul 21, 2026 at 01:28:58AM +0800, Icenowy Zheng wrote:
> 在 2026-07-20一的 09:56 -0700，Drew Fustini写道：
> > On Fri, Jul 17, 2026 at 12:11:23PM +0800, Icenowy Zheng wrote:
> > >
> > >
> > > 于 2026年7月17日 GMT+08:00 04:52:19，Drew Fustini <fustini@kernel.org>
> > > 写道：
> > > > On Tue, Jul 14, 2026 at 03:45:14PM +0800, Icenowy Zheng wrote:
> > > > > From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> > > > >
> > > > > Add labels for GPIOs on the IO expansion chip on the I2C1 bus.
> > > > >
> > > > > Signed-off-by: Emil Renner Berthing
> > > > > <emil.renner.berthing@canonical.com>
> > > > > [Icenowy: Splitted off the patch adding all 3 IO expansions]
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > > > > ---
> > > > > arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts | 8 ++++++++
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > > b/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > > index 74b120c6b063a..78f5979a56c14 100644
> > > > > --- a/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > > +++ b/arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts
> > > > > @@ -128,6 +128,14 @@ ioexp2: gpio@18 {
> > > > > reg = <0x18>;
> > > > > gpio-controller;
> > > > > #gpio-cells = <2>;
> > > > > + gpio-line-names = "",
> > > > > + "cam0_reset",
> > > > > + "cam1_reset",
> > > > > + "cam2_reset",
> > > > > + "wl_host_wake",
> > > >
> > > > I am not sure the line name really matters all that, but it seems
> > > > that
> > > > pin 4 is also used as a reset gpio:
> > >
> > > The "host" here is subject, which means "this pins is used by the
> > > host to wake the wl".
> > >
> > > Maybe I should take the schematics name, "wl_host_wake_dev"? Or use
> > > another name on the page for Wi-Fi, "wl_reg_on"?
> >
> > I thnk "wl_host_wake_dev" is slightly better in terms of searching
> > the
> > PDF [1] and finding the "IO Expansion 2" section. This is minor
> > change
> > so I can just fix up when applying if you are okay with that.
>
> Of course I am okay with this.
>
> Thanks,
> Icenowy
Great, I'll fixup on apply.
Reviewed-by: Drew Fustini <fustini@kernel.org>
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v2 5/5] riscv: dts: thead: Add remaining Lichee Pi 4A IO expansions
From: Drew Fustini @ 2026-07-20 18:28 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Guo Ren, Fu Wei, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MoeLeak, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-riscv,
devicetree, linux-kernel, Icenowy Zheng, Emil Renner Berthing
In-Reply-To: <20260714074515.1959352-6-zhengxingda@iscas.ac.cn>
On Tue, Jul 14, 2026 at 03:45:15PM +0800, Icenowy Zheng wrote:
> From: Emil Renner Berthing <emil.renner.berthing@canonical.com>
>
> Lichee Pi 4A has 3 I2C IO expansion chips onboard, connected to the
> I2C0/1/3 busses. The I2C1 one is already added to the device tree, but
> the I2C0/3 ones are not yet added.
>
> Add device tree nodes for them.
>
> Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
> [Icenowy: added commit description, enable SoC pull-up, remove I2C1 and
> aliases]
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
> .../boot/dts/thead/th1520-lichee-pi-4a.dts | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
Reviewed-by: Drew Fustini <fustini@kernel.org>
Thanks,
Drew
^ permalink raw reply
* [PATCH v3] docs: dt: maintainer: Add Devicetree and OF maintainer profile document
From: Krzysztof Kozlowski @ 2026-07-20 18:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, devicetree, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Saravana Kannan
Document how Devicetree and Open Firmware maintainers handle their
subsystem, especially focusing on two caveats:
Devicetree subsystem handles patches with a minor difference comparing
to other subsystems: while DT maintainers pick up OF code, they only
provide review of DT bindings without applying these.
All three DT bindings maintainers rely currently on Patchwork and due to
enormous amount of emails per day, regardless how much DT maintainers
try, they cannot read all the emails.
Cc: Rob Herring <robh@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Saravana Kannan <saravanak@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I expect patch to be picked up by Rob, after review.
Changes in v3:
1. Add also F: entry
Changes in v2:
1. Correct typos and trailing white spaces.
2. Fix order of P: after C: in maintainers.
---
.../process/maintainer-devicetree.rst | 70 +++++++++++++++++++
MAINTAINERS | 3 +
2 files changed, 73 insertions(+)
create mode 100644 Documentation/process/maintainer-devicetree.rst
diff --git a/Documentation/process/maintainer-devicetree.rst b/Documentation/process/maintainer-devicetree.rst
new file mode 100644
index 000000000000..d8ffe752bf5d
--- /dev/null
+++ b/Documentation/process/maintainer-devicetree.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Devicetree and Open Firmware Subsystem
+======================================
+
+Other Process Documents
+-----------------------
+
+Please see the documents in Documentation/devicetree/bindings/ for information
+on how to write proper Devicetree bindings and how to submit patches.
+
+Patch Review and Handling
+-------------------------
+
+Patches handled by Devicetree maintainers are processed differently depending
+on the patch type:
+
+1. Core OF driver code, e.g. drivers/of/:
+ patches are reviewed and applied by DT maintainers.
+
+2. Devicetree bindings:
+ patches are reviewed by DT maintainers but, except in certain cases, should
+ be applied by subsystem maintainers. See also *For kernel maintainers* in
+ Documentation/devicetree/bindings/submitting-patches.rst.
+
+3. DTS and drivers:
+ DT maintainers might provide comments, but review is generally not expected.
+
+Patchwork
+~~~~~~~~~
+
+Devicetree maintainers review patches using Patchwork, so the current status of
+a patch can be checked there. For typical driver submissions, Patchwork
+receives the entire patch set, but only a few patches are usually Devicetree
+bindings that are reviewed by DT maintainers.
+
+Explanation of Patchwork statuses:
+
+ - **New**: Not yet processed by the automation toolset.
+ - **Needs ACK**: Waiting for review by DT maintainers.
+ - **Handled Elsewhere**: Non-DT patch; not being reviewed here.
+ - **RFC**: Patch was likely ignored because it was an incomplete RFC.
+ - **Changes Requested**: Patch was reviewed and DT maintainers expect changes.
+ - **Accepted**: Patch was reviewed and applied by DT maintainers to their tree.
+ - **Not Applicable**: Patch was reviewed and is likely in good shape, with a
+ *Reviewed-by* or *Acked-by* tag provided, but DT maintainers expect someone
+ else to apply it.
+
+Patch Re-review and Pinging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the high volume of email traffic, Devicetree maintainers do not read
+every email they receive and instead rely on Patchwork during the review
+process. They also often skip patches that have already been reviewed.
+
+As a result, maintainers might miss:
+
+1. Questions about already reviewed patches.
+2. Pings, for example when a patch has been reviewed by DT maintainers but has
+ not been picked up by subsystem maintainers.
+
+Such cases can be addressed by:
+
+1. Pinging DT maintainers on the IRC channel.
+2. Dropping the DT maintainer’s *Acked-by* or *Reviewed-by* tag when sending a new
+ version of the patch set, together with an explanation in the patch
+ changelog describing why the tag was removed and what is expected from DT
+ maintainers.
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 0b6b9e6b3900..be6aa5d174c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20285,6 +20285,7 @@ S: Maintained
Q: http://patchwork.kernel.org/project/devicetree/list/
W: http://www.devicetree.org/
C: irc://irc.libera.chat/devicetree
+P: Documentation/process/maintainer-devicetree.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
F: Documentation/ABI/testing/sysfs-firmware-ofw
F: drivers/of/
@@ -20306,8 +20307,10 @@ L: devicetree@vger.kernel.org
S: Maintained
Q: http://patchwork.kernel.org/project/devicetree/list/
C: irc://irc.libera.chat/devicetree
+P: Documentation/process/maintainer-devicetree.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
F: Documentation/devicetree/
+F: Documentation/process/maintainer-devicetree.rst
F: arch/*/boot/dts/
F: include/dt-bindings/
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller
From: Nikolai Burov @ 2026-07-20 19:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Ulf Hansson, Matthias Brugger,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-pm, Nikolai Burov
In-Reply-To: <20260720-vigorous-groovy-cassowary-9912d9@quoll>
On 7/20/26 8:05 AM, Krzysztof Kozlowski wrote:
> On Wed, Jul 15, 2026 at 04:54:05PM +0300, Nikolai Burov wrote:
>> Add a new compatible and document bindings for the power domain
>> controller of the MT6858 SoC.
>>
>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> To provide review, please open and read the entire file.
>
>> Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
>> ---
>> .../bindings/power/mediatek,power-controller.yaml | 21 +++++++++++++++++++-
>> include/dt-bindings/power/mediatek,mt6858-power.h | 23 ++++++++++++++++++++++
>> 2 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> index 070c6e5666dc..d03e4a925163 100644
>> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> @@ -25,6 +25,7 @@ properties:
>> enum:
>> - mediatek,mt6735-power-controller
>> - mediatek,mt6795-power-controller
>> + - mediatek,mt6858-power-controller
>> - mediatek,mt6893-power-controller
>> - mediatek,mt8167-power-controller
>> - mediatek,mt8173-power-controller
>> @@ -56,7 +57,7 @@ properties:
>> faults while enabling or disabling a power domain.
>> For example, this may hold phandles to INFRACFG and SMI.
>> minItems: 1
>> - maxItems: 3
>> + maxItems: 6
>
> And the rest? Why does this device have flexible number of access
> controllers?
For mt6858, the "items" list I provided already overrides both minItems
and maxItems, so it has a fixed number (6) of access controllers.
The top-level constraints are intentionally broad so that the
SoC-specific constraints below, which all have minItems == maxItems,
don't contradict them. Those are missing for some SoCs, but isn't that
an existing weakness in the bindings?
Looking at the driver, apparently those missing SoCs are the ones that
only need infracfg. That's a single access controller. So they would
never have 3 or 2 items, only 1. This is not specified in the bindings
though.
If you mean that it can't stay like this, I could change the bindings to
add such a constraint for the remaining SoCs, provided that this is
allowed - theoretically it could break some hypothetical device trees
with excess items in access-controllers.
Alternatively, I guess one solution would be to add a minItems: 1 and
maxItems: 3 constraint for the remaining SoCs to keep their bindings
unaffected, even though that seems wrong from a HW point of view. But
I'm not sure if that is what you mean.
--
Best regards,
Nikolai
^ 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