* Re: [PATCH RFC v4 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:11 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-2-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]
On Tue, Jun 16, 2026 at 11:26:22PM +0300, Stefan Dösinger wrote:
> I split matrixclk into its own controller again because syscon/regmap
> deals poorly with device nodes that have more than one memory region. As
> a consequence I am passing all PLL outputs generated on Topclk down to
> Matrixclk.
This type of commentary FWIW can go below the --- line and instead just
write a normal commit message.
I do appreciate though that you put the information in the individual
patch.
> The syscon is used to generate the regmap shared between the clock and
> auxiliary reset drivers. The register space also contains at least one
> extra block of functionality, hardware spinlocks, that I expect will be
> necessary to communicate correctly with the LTE DSP firmware blob.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + topclk: clock-controller@13b000 {
> + compatible = "zte,zx297520v3-topclk", "syscon";
> + reg = <0x0013b000 0x400>;
> + clocks = <&osc26m>, <&osc32k>;
> + clock-names = "osc26m", "osc32k";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
This should be removed from here, the tooling will satisfy the topclk
references, just as it has done for osc26m and osc32k. The example
should just contain the node the binding documents (and its children).
pw-bot: changes-requested
Looks fine otherwise.
Cheers,
Conor.
> +
> + clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:12 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-3-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]
On Tue, Jun 16, 2026 at 11:26:23PM +0300, Stefan Dösinger wrote:
> +
> + matrixclk: clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + clock-controller@1400000 {
> + compatible = "zte,zx297520v3-lspclk";
> + reg = <0x01400000 0x100>;
> + clocks = <&matrixclk ZX297520V3_LSP_MPLL_D5_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D4_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D6_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D8_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D12_WCLK>,
> + <&matrixclk ZX297520V3_LSP_OSC26M_WCLK>,
> + <&matrixclk ZX297520V3_LSP_OSC32K_WCLK>,
> + <&matrixclk ZX297520V3_LSP_PCLK>,
> + <&matrixclk ZX297520V3_LSP_TDM_WCLK>,
> + <&matrixclk ZX297520V3_LSP_DPLL_D4_WCLK>;
> + clock-names = "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8", "mpll_d12",
> + "osc26m", "osc32k", "pclk", "tdm_wclk", "dpll_d4";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
Same comment here on what's in scope.
pw-bot: changes-requested
Otherwise, once again, looks okay.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v9 3/3] riscv: clocksource: Add p8700-gcru driver
From: Julian Braha @ 2026-06-17 16:17 UTC (permalink / raw)
To: aleksa.paunovic, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Paul Walmsley, John Stultz,
Stephen Boyd, Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Chao-ying Fu
In-Reply-To: <20260616-riscv-time-mmio-v9-3-03af7bc8f2d8@htecgroup.com>
Hi Aleksa,
On 6/16/26 17:03, Aleksa Paunovic via B4 Relay wrote:
> +config P8700_TIMER
> + bool "MIPS P8700 timer driver"
> + depends on GENERIC_SCHED_CLOCK && RISCV && RISCV_SBI && 64BIT
> + select CLKSRC_MMIO
> + select TIMER_PROBE
> + select TIMER_OF
You don't need to select TIMER_OF here, it's already enabled by
TIMER_PROBE. You could consider using a comment there, if you'd like.
- Julian Braha
^ permalink raw reply
* Re: [PATCH v12 1/7] i3c: master: Add APIs for I3C hub support
From: Frank Li @ 2026-06-17 16:18 UTC (permalink / raw)
To: sashiko-reviews
Cc: Lakshay Piplani, Frank.Li, linux-i3c, conor+dt, devicetree, robh
In-Reply-To: <20260617112035.86E7E1F000E9@smtp.kernel.org>
On Wed, Jun 17, 2026 at 11:20:35AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Bypassing core state tracking in `direct_attach` / `direct_detach` causes Use-After-Free, NULL pointer dereferences, and Memory Leaks.
> - [High] Bypassing address slot reservation in `direct_attach` leads to unrecoverable I3C bus address collisions.
> --
>
> commit ce08f4a6bc0d82c966d4e3337e6b4d082a9d09d2
> Author: Aman Kumar Pandey <aman.kumarpandey@nxp.com>
>
> i3c: master: Add APIs for I3C hub support
>
> This commit introduces helper functions for attaching and detaching I3C
> devices, alongside CCC command helpers. These additions prepare the core
> framework for handling I3C hubs.
>
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
> > @@ -1775,6 +1775,70 @@ static int i3c_master_attach_i3c_dev(struct i3c_master_controller *master,
>
> [ ... ]
>
> > +int i3c_master_direct_attach_i3c_dev_locked(struct i3c_master_controller *master,
> > + struct i3c_dev_desc *dev)
> > +{
> > + int ret = 0;
> > +
> > + /*
> > + * We don't attach devices to the controller until they are
> > + * addressable on the bus.
> > + */
> > +
> > + if (!dev->info.static_addr && !dev->info.dyn_addr)
> > + return 0;
> > +
> > + /* Do not attach the master device itself. */
> > + if (master->this != dev && master->ops->attach_i3c_dev)
> > + ret = master->ops->attach_i3c_dev(dev);
>
> [Severity: High]
> Does bypassing address slot reservation here lead to I3C bus collisions?
>
> In the standard attachment flow, i3c_master_get_i3c_addrs() is called to
> reserve the address slot in the controller's bus.addrslots bitmap. Because
> this direct helper skips that reservation, the parent controller's address
> map is never updated to reflect the newly occupied address.
>
> Since the parent controller and the virtual hub share the physical I3C bus,
> the parent might still believe the downstream device's address is free. If
> a new device hot-joins, could the parent controller allocate the exact same
> address, resulting in an unrecoverable address collision?
Should check address before attached.
>
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_direct_attach_i3c_dev_locked);
> > +
> > +/**
> > + * i3c_master_direct_detach_i3c_dev_locked() - Detach an I3C device from its
> > + * master controller.
>
> [ ... ]
>
> > +void i3c_master_direct_detach_i3c_dev_locked(struct i3c_dev_desc *dev)
> > +{
> > + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> > +
> > + /*
> > + * We don't attach devices to the controller until they are
> > + * addressable on the bus, so skip detach for unaddressed devices.
> > + */
> > + if (!dev->info.static_addr && !dev->info.dyn_addr)
> > + return;
> > +
> > + /* Do not detach the master device itself. */
> > + if (master->this != dev && master->ops->detach_i3c_dev)
> > + master->ops->detach_i3c_dev(dev);
>
> [Severity: Critical]
> Can this lead to a use-after-free or a NULL pointer dereference by bypassing
> the core state tracking?
>
> When i3c_master_direct_detach_i3c_dev_locked() invokes the controller's
> detach callback, master drivers typically free the master_priv data. However,
> the dev->common.master_priv pointer is never cleared here.
It'd better clean it and free dyn_addr.
Frank
>
> If i3c_hub_free_ibi() calls this detach helper, and later a transfer is sent
> via i3c_hub_master_priv_xfers():
>
> drivers/i3c/hub.c:i3c_hub_master_priv_xfers() {
> ...
> xfer_ret = i3c_master_priv_xfers(dev, xfers, nxfers, mode);
> ...
> }
>
> Will the parent controller end up dereferencing the freed master_priv
> pointer?
>
> Additionally, if a device is never explicitly attached via the direct helper
> (leaving master_priv NULL), would a standard transfer immediately cause a
> NULL pointer dereference when forwarded to the parent driver?
>
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_direct_detach_i3c_dev_locked);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260617110355.1591844-1-lakshay.piplani@nxp.com?part=1
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-17 16:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260617-deviate-sulk-c57104ef939f@spud>
Hi Conor,
Am 17.06.2026 um 17:51 schrieb Conor Dooley:
> On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote:
>> Add support for the optional rockchip,clk-lane-phase device tree property
>> to allow board-specific tuning of the clock lane sampling phase for
>> improved signal integrity across supported data rates.
>>
>> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
>> ---
>> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> index 03950b3cad08c..0d824d1511bc0 100644
>> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> @@ -56,6 +56,13 @@ properties:
>> description:
>> Some additional phy settings are access through GRF regs.
>>
>> + rockchip,clk-lane-phase:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 7
>> + description:
>> + Clock lane sampling phase in 40 ps steps. The hardware default is 3.
>
> Can this instead become rockchip,clk-lane-phase-ps and be listed in the
> actual unit?
> With the -ps suffix, you can then drop the $ref.
> The default should be listed as "default: 3" (or default: 120)
>
> pw-bot: changes-requested
>
Thanks for the suggestion.
The phase setting is a hardware tap index (0–7) selecting a delay line
position. The datasheet mentions “about 40 ps” per step, but this is not
a calibrated or guaranteed value and may vary with PVT.
Because of that, I’d prefer to keep the property as an index and
document the approximate delay in the description:
Clock lane sampling phase selection (hardware tap index 0–7). Each step
corresponds to an approximately 40 ps delay as described in the hardware
specification.
This matches the hardware model more closely. Happy to adjust if needed.
>> +
>> required:
>> - compatible
>> - reg
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: qcom: kodiak: Add GEM_NOC interconnect for adreno SMMU
From: Bibek Kumar Patro @ 2026-06-17 16:20 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <zhdacu4upv5kyvyqx5hcm6im4p7r3z5bsnup7hqu2okxyxmeib@snpseurpvhtc>
On 6/16/2026 5:49 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 08, 2026 at 08:07:07PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:27 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:04PM +0530, Bibek Kumar Patro wrote:
>>>> On Kodiak platforms, the Adreno SMMU requires a bandwidth vote on
>>>> the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers
>>>> are accessible. Without this vote, the SMMU may become unreachable,
>>>> leading to intermittent probe failures and runtime issues.
>>>>
>>>> Add the required interconnect to ensure reliable register access.
>>>
>>> Does it only concern the GPU SMMU? What about the APPS SMMU? Should it
>>> be voting on other interconnects too? I guess so, because currently I
>>> see that TBUs vote for various interconnects. BTW: should apps_smmu also
>>> vote on the power domains?
>>>
>>
>> This race mainly occurs in GPU SMMU, where the GDSC can have an
>> independent vote on the Adreno SMMU. However, the GEM_NOC vote may
>> already have been removed by the GPU (or any consumer of adreno_smmu,
>> e.g gmu), unless it is explicitly voted by the GPU SMMU (which acts as a
>> supplier for the GPU). This mismatch can lead to SHUB timeouts or NoC
>> errors.
>>
>> Mostly this race reported in suspend/resume cycle (when gpu/gmu devices
>> moves to slumber/suspend state before adreno_smmu powers down
>> and the later doesn't have explicit interconnect voting).
>>
>> In the case of APPS SMMU, such a race is not expected for any known
>> use case. APPS SMMU is part of a shared infrastructure block, and its
>> power is typically kept enabled as long as attached master devices are
>> active. Therefore, explicit power-domain voting from APPS SMMU may not
>> be required.
>
> This looks like a good part of the commit message. Please add it where
> it belongs.
>
Ack, thanks for this suggestion. It seems like i haven't explained this
specific info in any of the patches in this series.
Will take care of this in the next revision.
Thanks & regards,
Bibek
>>
>> Thanks,
>> Bibek
>>
>>
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index fa540d8c2615dc02d941eb16bc7253204c2750bd..eefa4b836a81374ff437ab4bbcbc3fecc1590ab6 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -3386,6 +3386,8 @@ adreno_smmu: iommu@3da0000 {
>>>> power-domains = <&gpucc GPU_CC_CX_GDSC>;
>>>> dma-coherent;
>>>> + interconnects = <&gem_noc MASTER_GPU_TCU QCOM_ICC_TAG_ALWAYS
>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>>>> };
>>>> gfx_0_tbu: tbu@3dd9000 {
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v8 2/5] iio: adc: add Versal SysMon driver
From: Erim, Salih @ 2026-06-17 16:23 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajK0phP9-pt9njrb@ashevche-desk.local>
Hi Andy,
On 17/06/2026 15:52, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:56PM +0100, Salih Erim wrote:
>> Add the core driver and MMIO platform driver for the AMD/Xilinx Versal
>> System Monitor (SysMon) block.
>>
>> The SysMon block resides in the platform management controller (PMC) and
>> provides on-chip voltage and temperature monitoring through a 10-bit,
>> 200 kSPS ADC. It can monitor up to 160 voltage channels and 64
>> temperature satellites distributed across the SoC, with a consistent
>> sample rate of 8 kSPS per channel regardless of how many channels are
>> enabled.
>>
>> The hardware also provides four aggregate temperature registers that
>> are always present regardless of the device tree configuration: the
>> current max and min across all active satellites, and the peak and
>> trough values recorded since the last hardware reset.
>>
>> The driver is split into two compilation units:
>> - versal-sysmon-core: Channel parsing, IIO registration, read_raw
>> - versal-sysmon: MMIO platform driver with custom regmap accessors
>>
>> Voltage results are stored in a 19-bit modified floating-point format
>> and converted to millivolts. Temperature results are stored in Q8.7
>> signed fixed-point Celsius format and converted to millicelsius.
>>
>> The MMIO regmap backend uses a custom reg_write accessor that
>> automatically unlocks the NPI (NoC programming interface) lock
>> register before each write, as required by the hardware. The regmap
>> is configured with fast_io since the underlying MMIO accessors are
>> safe to call from atomic context.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> with a caveat of using namespaced exports (see below).
Thank you for the review!
>
> ...
>
>> +EXPORT_SYMBOL_GPL(devm_versal_sysmon_core_probe);
>
> Please, also use symbol namespace.
Will use EXPORT_SYMBOL_NS_GPL(devm_versal_sysmon_core_probe,
"VERSAL_SYSMON") and add MODULE_IMPORT_NS("VERSAL_SYSMON") to both
platform and I2C drivers.
>
> ...
>
>> +static int sysmon_mmio_reg_read(void *context, unsigned int reg,
>> + unsigned int *val)
>
> Make it a single line. It will be more readable.
>
> static int sysmon_mmio_reg_read(void *context, unsigned int reg, unsigned int *val)
Done.
>
> ...
>
>> +static int sysmon_mmio_reg_write(void *context, unsigned int reg,
>> + unsigned int val)
>
> In the similar way.
>
> static int sysmon_mmio_reg_write(void *context, unsigned int reg, unsigned int val)
Done.
Thanks,
Salih
>
> In both cases it's only 83 characters.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v8 3/5] iio: adc: versal-sysmon: add I2C driver
From: Erim, Salih @ 2026-06-17 16:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajK0-KmjxDPW_g4M@ashevche-desk.local>
Hi,
On 17/06/2026 15:53, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:57PM +0100, Salih Erim wrote:
>> Add an I2C transport driver for the Versal SysMon block. The SysMon
>> provides an I2C slave interface that allows an external master to
>> read voltage and temperature measurements through the same register
>> map used by the MMIO path.
>>
>> The I2C command frame is an 8-byte structure containing a 4-byte data
>> payload, a 2-byte register offset, and a 1-byte instruction field.
>> Read operations send the frame with a read instruction, then receive
>> a 4-byte response containing the register value.
>>
>> Events are not supported on the I2C path because there is no
>> interrupt line and the I2C regmap backend cannot be called from
>> atomic context.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Thank you!
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v3 4/5] iio: adc: ltc2378: Enable high-speed data capture
From: Julian Braha @ 2026-06-17 16:26 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, dlechner, andy, robh, krzk+dt,
conor+dt, pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <9f173c47928446aa3e900cf0becb6130dd76846b.1781661028.git.marcelo.schmitt@analog.com>
Hi Marcelo,
On 6/17/26 03:04, Marcelo Schmitt wrote:
> + select LTC2378_LIB_OFFLOAD_BUFFER if SPI_OFFLOAD && PWM && SPI_OFFLOAD_TRIGGER_PWM && IIO_BUFFER && IIO_BUFFER_DMAENGINE
The PWM in this expression is unnecessary since you're && it with
SPI_OFFLOAD_TRIGGER_PWM.
- Julian Braha
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-17 16:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <2i6yzwu2yk5bngq723g75yeqzeg4ihvtbuydzunceltl526tjp@vnt6nmxxkfut>
On 6/16/2026 5:52 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 15, 2026 at 06:55:45PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>> On some SoCs the SMMU registers require an active interconnect
>>>> bandwidth vote to be accessible. While other clients typically
>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>> vote, causing intermittent register access failures.
>>>>
>>>> Add support for an optional interconnect path to the arm-smmu
>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>> is acquired from DT if present and ignored otherwise.
>>>>
>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>> during probe and runtime resume, and released during runtime
>>>> suspend and on error paths.
>>>>
>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>> expected to have an active vote whenever the adreno_smmu block is
>>>> powered on. In most common use cases, this requirement is implicitly
>>>> satisfied because other GPU-related clients (for example, the GMU
>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>
>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>> vote is missing, it can lead to the observed failures. Because of the
>>>> precise ordering involved, this scenario is difficult to reproduce
>>>> consistently.
>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> @@ -53,6 +53,11 @@
>>>> #define MSI_IOVA_BASE 0x8000000
>>>> #define MSI_IOVA_LENGTH 0x100000
>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>
>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>
>>>> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
>>>> +
>>>> static int force_stage;
>>>> module_param(force_stage, int, S_IRUGO);
>>>> MODULE_PARM_DESC(force_stage,
>>>> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>>>> }
>>>> }
>>>> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
>>>> +{
>>>> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
>>>
>>> Is there always only one bus / path in question?
>>>
>>
>> <Apologies, missed to respond to this query>
>> Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
>> while accessing the DDR in downstream path (client->TCU->DDR), which we are
>> addressing here.
>> Hence it's only one icc path in question here.
>
> Again, you are describing Qualcomm platform, while the code part is
> generic.
>
ah yes, single icc path is specific to Qualcomm platforms as of now.
As per my assumption, it's possible for other vendors/ARM-SMMU users to
have one or more than one icc path to reach DDR in downstream flow
(similar to clocks).
I will revisit the logic for icc_voting to check for possibility on
additional icc path as well, so the generic code can cater to other arm-
smmu users.
Thanks & regards,
Bibek
>
^ permalink raw reply
* Re: [PATCH v2 3/3] irqchip/qcom-pdc: Add puwra compatible for PDC secondary mode
From: Thomas Gleixner @ 2026-06-17 16:32 UTC (permalink / raw)
To: Maulik Shah, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
Maulik Shah
In-Reply-To: <20260616-purwa-pdc-v2-3-8dda7ef25ce5@oss.qualcomm.com>
On Tue, Jun 16 2026 at 15:57, Maulik Shah wrote:
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -704,7 +704,10 @@ static int qcom_pdc_probe(struct platform_device *pdev, struct device_node *pare
> }
>
> pdc->x1e_quirk = true;
> + }
>
> + if (of_device_is_compatible(node, "qcom,x1e80100-pdc") ||
> + of_device_is_compatible(node, "qcom,x1p42100-pdc")) {
> if (!qcom_scm_is_available())
> return -EPROBE_DEFER;
Bah. Can you please prominently tell in the cover letter that the series
has dependencies on some other series instead of hiding that information
in a lump of sha1 references which do not exist for me?
^ permalink raw reply
* Re: [PATCH v8 4/5] iio: adc: versal-sysmon: add threshold event support
From: Erim, Salih @ 2026-06-17 16:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajK_kmZMfdLaVyIj@ashevche-desk.local>
Hi Andy,
All accepted, all will be fixed in v9.
On 17/06/2026 16:38, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:58PM +0100, Salih Erim wrote:
>> Add threshold event support for temperature and supply voltage
>> channels.
>>
>> Temperature events:
>> - Rising threshold with configurable value on the device
>> temperature channel (current max across all satellites)
>> - Per-channel hysteresis as a millicelsius value
>> - Event direction is IIO_EV_DIR_RISING (hysteresis mode)
>>
>> Supply voltage events:
>> - Rising/falling threshold per supply channel
>> - Per-channel alarm enable via alarm configuration registers
>>
>> The hardware supports both window and hysteresis alarm modes for
>> temperature. This driver uses hysteresis mode, where the upper
>> threshold triggers the alarm and the lower threshold clears it
>> (re-arm point). The hardware has a single ISR bit per temperature
>> channel with no indication of which threshold was crossed, so
>> hysteresis mode is the natural fit. The lower threshold register
>> is computed internally as (upper - hysteresis).
>>
>> Hysteresis is stored in the driver as a millicelsius value,
>> initialized from the hardware registers at probe. Writing the
>> rising threshold or hysteresis recomputes the lower register.
>> ALARM_CONFIG is hard-coded to hysteresis mode during init.
>>
>> The hardware also provides a separate over-temperature (OT)
>> threshold, but it is not exposed through IIO as it serves as a
>> hardware safety mechanism for platform shutdown. OT will be
>> exposed through the thermal framework in a follow-up series.
>>
>> The interrupt handler masks active threshold interrupts (which are
>> level-sensitive) and schedules a delayed worker to poll for condition
>> clear before unmasking. When no hardware IRQ is available, event
>> specs are not attached and interrupt init is skipped, since the
>> I2C regmap backend cannot be called from atomic context.
>>
>> When disabling a supply channel alarm, the group interrupt remains
>> active if any other channel in the same alarm group still has an
>> alarm enabled.
>>
>> A devm cleanup action masks all interrupts on driver unbind to
>> prevent unhandled interrupt storms after the IRQ handler is freed.
>
> ...
>
>> +static void sysmon_supply_processedtoraw(int val, u32 reg_val, u32 *raw_data)
>> +{
>> + int exponent = FIELD_GET(SYSMON_MODE_MASK, reg_val);
>> + int format = FIELD_GET(SYSMON_FMT_MASK, reg_val);
>> + int scale, tmp;
>> +
>> + scale = BIT(SYSMON_SUPPLY_MANTISSA_BITS - exponent);
>> + tmp = (val * scale) / (int)MILLI;
>> +
>> + if (format)
>> + tmp = clamp(tmp, S16_MIN, S16_MAX);
>> + else
>> + tmp = clamp(tmp, 0, U16_MAX);
>
> Double check that minmax.h is included.
Accepted. Will add <linux/minmax.h>
>
>> + *raw_data = (u16)tmp;
>> +}
>
> ...
>
>> +static int sysmon_supply_thresh_offset(int address,
>> + enum iio_event_direction dir)
>
> Make it a single line. OTOH why is 'address' signed? Perhaps u32?
> Or for some reason unsigned long as per _alarm_config()?
Accepted. Will Join to one line. Changed to unsigned long for
consistency with sysmon_read_alarm_config() and sysmon_write_alarm_config().
>
>> +{
>> + if (dir == IIO_EV_DIR_RISING)
>> + return (address * SYSMON_REG_STRIDE) + SYSMON_SUPPLY_TH_UP;
>> + if (dir == IIO_EV_DIR_FALLING)
>> + return (address * SYSMON_REG_STRIDE) + SYSMON_SUPPLY_TH_LOW;
>> +
>> + return -EINVAL;
>> +}
>
> ...
>
>> +static int sysmon_read_event_config(struct iio_dev *indio_dev,
>> + const struct iio_chan_spec *chan,
>> + enum iio_event_type type,
>> + enum iio_event_direction dir)
>> +{
>> + struct sysmon *sysmon = iio_priv(indio_dev);
>> + unsigned int imr;
>> + int config_value;
>
>> + u32 mask;
>> + int ret;
>> +
>> + mask = sysmon_get_event_mask(chan);
>
> Just make it together, as we don't validate the value of 'mask'.
Accepted.
>
> struct sysmon *sysmon = iio_priv(indio_dev);
> u32 mask = sysmon_get_event_mask(chan);
> ...
> int ret;
>
>> + ret = regmap_read(sysmon->regmap, SYSMON_IMR, &imr);
>> + if (ret)
>> + return ret;
>> +
>> + /* IMR bits are 1=masked, invert to get 1=enabled */
>> + imr = ~imr;
>> +
>> + switch (chan->type) {
>> + case IIO_VOLTAGE:
>> + config_value = sysmon_read_alarm_config(sysmon, chan->address);
>> + if (config_value < 0)
>> + return config_value;
>> + return config_value && (imr & mask);
>> +
>> + case IIO_TEMP:
>> + /*
>> + * Return the administrative state, not the hardware IMR.
>> + * The IRQ handler temporarily masks the interrupt during
>> + * the polling window; reading IMR would show it as disabled.
>> + * temp_mask bit is set when administratively disabled.
>> + */
>> + return !(sysmon->temp_mask & mask);
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>
> ...
>
>> +static int sysmon_write_event_config(struct iio_dev *indio_dev,
>> + const struct iio_chan_spec *chan,
>> + enum iio_event_type type,
>> + enum iio_event_direction dir,
>> + bool state)
>> +{
>> + u32 offset = SYSMON_ALARM_OFFSET(chan->address);
>> + struct sysmon *sysmon = iio_priv(indio_dev);
>> + u32 ier = sysmon_get_event_mask(chan);
>
> Here you call the variable 'ier'. Please, make this consistent in the related
> APIs (see above).
Accepted. Will rename to 'mask' in write_event_config to match
read_event_config
>
>> + unsigned int alarm_config;
>> + int ret;
>> +
>> + guard(mutex)(&sysmon->lock);
>> +
>> + switch (chan->type) {
>> + case IIO_VOLTAGE:
>> + ret = sysmon_write_alarm_config(sysmon, chan->address, state);
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_read(sysmon->regmap, offset, &alarm_config);
>> + if (ret)
>> + return ret;
>> +
>> + if (alarm_config)
>> + return regmap_write(sysmon->regmap, SYSMON_IER, ier);
>> +
>> + return regmap_write(sysmon->regmap, SYSMON_IDR, ier);
>> +
>> + case IIO_TEMP:
>> + if (state) {
>> + ret = regmap_write(sysmon->regmap, SYSMON_IER, ier);
>> + if (ret)
>> + return ret;
>> +
>> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
>> + sysmon->temp_mask &= ~ier;
>> + } else {
>> + ret = regmap_write(sysmon->regmap, SYSMON_IDR, ier);
>> + if (ret)
>> + return ret;
>> +
>> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
>> + sysmon->temp_mask |= ier;
>> + }
>> + return 0;
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>
> ...
>
>> +static int sysmon_update_temp_lower(struct sysmon *sysmon)
>> +{
>> + unsigned int upper_reg;
>> + int upper_mc, lower_mc;
>> + u32 raw_val;
>> + int ret;
>> +
>> + ret = regmap_read(sysmon->regmap, SYSMON_TEMP_TH_UP, &upper_reg);
>> + if (ret)
>> + return ret;
>> +
>> + sysmon_q8p7_to_millicelsius(upper_reg, &upper_mc);
>
>> +
>
> ^^^
>
>> + lower_mc = upper_mc - sysmon->temp_hysteresis;
>
> Either add a blank line here, or remove the one above as these three is kinda
> semantically coupled.
Accepted. Will removed the blank line, the three lines are a single
conversion sequence.
>
>> + sysmon_millicelsius_to_q8p7(&raw_val, lower_mc);
>> +
>> + return regmap_write(sysmon->regmap, SYSMON_TEMP_TH_LOW, raw_val);
>> +}
>
> ...
>
>> +static void sysmon_unmask_temp(struct sysmon *sysmon, unsigned int isr)
>> +{
>> + unsigned int unmask, status;
>
> As per above perhaps name 'unmask' as 'u32 ier'? Or did I miss the use case?
Accepted. Will rename to 'u32 ier', this is the value written to the IER
register, so the name fits.
>
>> + status = isr & SYSMON_TEMP_INTR_MASK;
>> +
>> + unmask = ~status & sysmon->masked_temp;
>> + sysmon->masked_temp &= status;
>> +
>> + /* Only unmask if not administratively disabled by userspace */
>> + unmask &= ~sysmon->temp_mask;
>> +
>> + regmap_write(sysmon->regmap, SYSMON_IER, unmask);
>> +}
>
> Also looking at all this, please double check variable names in all functions
> and make types and names consistent across the whole driver code.
Accepted. Will audited. To be consistent: 'mask' for the event interrupt
bitmask in read/write_event_config, 'ier' for values written to the IER
register in sysmon_unmask_temp.
>
>> + }
>
> ...
>
>> - num_chan = size_add(num_temp, size_add(ARRAY_SIZE(temp_channels), num_supply));
>> + num_static = ARRAY_SIZE(temp_channels);
>> + num_chan = size_add(num_temp, size_add(num_static, num_supply));
>
> At glance I don't see any additional arguments, can we introduce num_static in
> the previous patch to reduce a churn here?
Accepted. Will move num_static introduction to P2.
Thanks,
Salih
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v8 5/5] iio: adc: versal-sysmon: add oversampling support
From: Erim, Salih @ 2026-06-17 16:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajLAUJPpdaf8lJqG@ashevche-desk.local>
Hi Andy,
On 17/06/2026 16:42, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:59PM +0100, Salih Erim wrote:
>> Add support for reading and writing the oversampling ratio through
>> the IIO oversampling_ratio attribute. The hardware supports averaging
>> 2, 4, 8, or 16 samples, plus a ratio of 1 (no averaging).
>>
>> Temperature and supply channels share oversampling configuration at
>> the type level (all temperature channels share one ratio, all supply
>> channels share another), exposed through info_mask_shared_by_type.
>>
>> The hardware encoding uses sample_count / 2 in a 4-bit field within
>> the CONFIG register. Per-channel averaging enable registers must also
>> be updated to activate or deactivate averaging.
>
> This one LGTM now,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Thank you!
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
From: Heiner Kallweit @ 2026-06-17 16:43 UTC (permalink / raw)
To: ricardo, nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-1-2bd38922d129@pardini.net>
On 17.06.2026 14:58, Ricardo Pardini via B4 Relay wrote:
> From: Ricardo Pardini <ricardo@pardini.net>
>
> Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
> controller.
>
> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
> compatibles documented in their own bindings (e.g. microchip,lan95xx)
> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
> these PCI function nodes can be validated.
>
> Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
> ---
> .../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 44 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> new file mode 100644
> index 0000000000000..eee13fbc1e6a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/realtek,rtl8125.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek RTL8125 2.5 Gigabit PCIe Ethernet Controller
> +
> +maintainers:
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + The Realtek RTL8125 is a 2.5GBASE-T Ethernet controller with a PCIe host
> + interface.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + const: pci10ec,8125
IIRC we came to the conclusion that the compatible string isn't used in the
relevant code path. Then why add it here? Is there an alignment on this?
If it should be added here, then an explaining comment would be helpful.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet@0,0 {
> + compatible = "pci10ec,8125";
> + reg = <0x10000 0 0 0 0>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c8d4b913f26c1..e5fbd82946aec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
> M: nic_swsd@realtek.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> F: drivers/net/ethernet/realtek/r8169*
>
> 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
>
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Alexandre Belloni @ 2026-06-17 16:55 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-8-prabhakar.mahadev-lad.rj@bp.renesas.com>
On 15/06/2026 16:48:00+0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> alarm and farest were declared as unsigned long, but
> rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> unsigned long is 32 bits, the assignment silently truncates the upper
> 32 bits of the timestamp.
>
> Fix by declaring alarm and farest as time64_t and replacing
> time_after() with a direct signed comparison, which is correct for
> time64_t values that will never realistically overflow.
>
I'd argue that this is never going to overflow ever as unsigned long
gets you to 2106 which is way past the usable range of the RTC so there
is a trade off between the size you are going to take on the stack and
the actual usefulness of the fix.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v22 00/13] Implement PSCI reboot mode driver for PSCI resets
From: Shivendra Pratap @ 2026-06-17 17:00 UTC (permalink / raw)
To: Lorenzo Pieralisi, Arnd Bergmann
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Bartosz Golaszewski, Song Xue, Sebastian Reichel, Mark Rutland,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer,
Bartosz Golaszewski, Sudeep Holla
In-Reply-To: <0c6636b0-f6c7-49dc-b335-2b4fac16b848@oss.qualcomm.com>
On 29-05-2026 19:00, Shivendra Pratap wrote:
>
>
> On 14-05-2026 19:55, Shivendra Pratap wrote:
>> Userspace should be able to initiate device reboots using the various
>> PSCI SYSTEM_RESET and SYSTEM_RESET2 types defined by PSCI spec. This
>> patch series introduces psci-reboot-mode driver that will induce
>> command-based resets to psci driver for executing the device reset.
>>
>> The PSCI system reset calls takes two arguments: reset_type and cookie.
>> It defines predefined reset types, such as warm and cold reset, and
>> vendor-specific reset types which are SoC vendor specific. To support
>> these requirements, the reboot-mode framework is enhanced in two key
>> ways:
>
> Hi Lorenzo,
>
> Can you please review the if its aligning towards the suggestion in v20?
>
Hi Lorenzo,
Was planning to address the mfd, and other comments, for re-post. Any
feedbacks, that we should take care in next post?
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: qcom: Document Hawi SoC and its reference boards
From: Konrad Dybcio @ 2026-06-17 17:04 UTC (permalink / raw)
To: Mukesh Ojha, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260617151602.2018579-1-mukesh.ojha@oss.qualcomm.com>
On 6/17/26 5:16 PM, Mukesh Ojha wrote:
> Add Hawi SoC and its reference boards to the Qualcomm binding.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Changes in v2: https://lore.kernel.org/lkml/20260617080147.1657632-1-mukesh.ojha@oss.qualcomm.com/
> - Fixed the position of the Documentation.
> - Corrected the commit text.
>
> Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 50cc18a6ec5e..e229c0097e6f 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -303,6 +303,11 @@ properties:
> - xiaomi,sagit
> - const: qcom,msm8998
>
> + - items:
> + - enum:
> + - qcom,hawi-mtp
> + - const: qcom,hawi
Someone did us a dirty and put all the router socs out of alphabetical order
(ipq after msm)
I'll fix that up later to not bother you more
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: iio: adc: Add ltc2378
From: Marcelo Schmitt @ 2026-06-17 17:14 UTC (permalink / raw)
To: Conor Dooley
Cc: Marcelo Schmitt, linux-iio, devicetree, linux-kernel, jic23,
nuno.sa, Michael.Hennerich, dlechner, andy, robh, krzk+dt,
conor+dt, pop.ioan-daniel
In-Reply-To: <20260617-bok-gains-9a1af41cf0de@spud>
On 06/17, Conor Dooley wrote:
> On Tue, Jun 16, 2026 at 11:03:11PM -0300, Marcelo Schmitt wrote:
> > Document how to describe LTC2378-20 and similar ADCs in device tree.
> >
> > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > ---
> > Change log v2 -> v3:
> > - Re-added device tree fallback compatibles for LTC2378 chips, now with options
> > to provide a single compatible string or a pair of single compatible string
> > plus a fallback string to a slower sample rate spec in case a driver for the
> > specific part is not found.
> >
> > .../bindings/iio/adc/adi,ltc2378.yaml | 160 ++++++++++++++++++
> > MAINTAINERS | 7 +
> > 2 files changed, 167 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> > new file mode 100644
> > index 000000000000..7d30a2cade8f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> > @@ -0,0 +1,160 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/adc/adi,ltc2378.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices LTC2378 and similar Analog to Digital Converters
> > +
> > +maintainers:
> > + - Marcelo Schmitt <marcelo.schmitt@analog.com>
> > +
> > +description: |
> > + Analog Devices LTC2378 series of ADCs.
> > + Specifications can be found at:
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/233818fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236416fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236418f.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236716fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236718f.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236816f.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236818f.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/236918fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237016fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237616fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237618fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237620fb.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237716fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237718fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237720fb.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237816fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237818fa.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237820fb.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/237918fb.pdf
> > + https://www.analog.com/media/en/technical-documentation/data-sheets/238016fb.pdf
> > +
> > +$ref: /schemas/spi/spi-peripheral-props.yaml#
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + # Single compatible string match.
> > + - enum:
> > + - adi,ltc2338-18
> > + - adi,ltc2364-16
> > + - adi,ltc2364-18
> > + - adi,ltc2367-16
> > + - adi,ltc2367-18
> > + - adi,ltc2368-16
> > + - adi,ltc2368-18
> > + - adi,ltc2369-18
> > + - adi,ltc2370-16
> > + - adi,ltc2376-16
> > + - adi,ltc2376-18
> > + - adi,ltc2376-20
> > + - adi,ltc2377-16
> > + - adi,ltc2377-18
> > + - adi,ltc2377-20
> > + - adi,ltc2378-16
> > + - adi,ltc2378-18
> > + - adi,ltc2378-20
> > + - adi,ltc2379-18
> > + - adi,ltc2380-16
> > +
> > + # Low sample rate fallback for 16-bit unipolar sensors.
> > + - items:
> > + - enum:
> > + - adi,ltc2370-16 # 2 MSPS
> > + - adi,ltc2368-16 # 1 MSPS
> > + - adi,ltc2367-16 # 500 kSPS
> > + - const: adi,ltc2364-16 # fallback (250 kSPS)
>
> Your driver still matches on ltc2370-16, which makes me question the
> value of these fallbacks. That said, the chip info struct contains no
> information about sampling rate.
The info about sample rate is added in patch 4.
> What actually is the impact of the sample rate on the programming model?
If the user tries to set a sample rate beyond the maximum supported, software
can throw an error to indicate that.
> Is there actually a benefit to matching on ltc2370-16, or can you just
> match on the fallback?
The benefit is telling software that it is safe to go up to 2 MSPS. It is also
okay to match on the fallback, but software may restrain operation to a slower
sample rate.
With the code being proposed in this patch set, there is no benefit in matching
the ltc2364-16 fallback if there is a faster ltc2370-16 device connected because
device driver supports that. Though, other operating systems and/or platforms
might not support all device variants and so the fallback might be useful.
> +static const struct ltc2378_chip_info ltc2370_16_chip_info = {
> + .name = "ltc2370-16",
> + .resolution = 16,
In a later patch ...
+ .max_sample_rate_hz = 2 * HZ_PER_MHZ,
+ .tconv_ns = 322,
> + .bipolar = false,
> +};
>
> +static const struct ltc2378_chip_info ltc2368_16_chip_info = {
> + .name = "ltc2368-16",
> + .resolution = 16,
+ .max_sample_rate_hz = HZ_PER_MHZ,
+ .tconv_ns = 527
> + .bipolar = false,
> +};
>
> +static const struct ltc2378_chip_info ltc2367_16_chip_info = {
> + .name = "ltc2367-16",
> + .resolution = 16,
+ .max_sample_rate_hz = 500 * HZ_PER_KHZ,
+ .tconv_ns = 1500,
> + .bipolar = false,
> +};
>
> +static const struct ltc2378_chip_info ltc2364_16_chip_info = {
> + .name = "ltc2364-16",
> + .resolution = 16,
+ .max_sample_rate_hz = 250 * HZ_PER_KHZ,
+ .tconv_ns = 3000,
> + .bipolar = false,
> +};
>
...
> > + # Low sample rate fallback for 20-bit bipolar sensors.
> > + - items:
> > + - enum:
> > + - adi,ltc2378-20 # 1 MSPS
> > + - adi,ltc2377-20 # 500 kSPS
> > + - const: adi,ltc2376-20 # fallback (250 kSPS)
>
> I didn't check these, but I assume they are the same.
Yes, except for small variations on input (unipolar/bipolar) and precision bits,
these devices are pretty much equal.
^ permalink raw reply
* Re: [PATCH v6 07/10] ACPI: APEI: introduce GHES helper
From: Julian Braha @ 2026-06-17 17:17 UTC (permalink / raw)
To: Ahmed Tiba, Rafael J. Wysocki, Tony Luck, Borislav Petkov,
Hanjun Guo, Mauro Carvalho Chehab, Shuai Xue, Len Brown,
Saket Dumbre, Davidlohr Bueso, Jonathan Cameron, Dave Jiang,
Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, linux-acpi, acpica-devel, linux-cxl, devicetree,
linux-edac, linux-doc, Dmitry.Lamerov
In-Reply-To: <20260617-topics-ahmtib01-ras_ffh_arm_internal_review-v6-7-91f725174aa0@arm.com>
Hi Ahmed,
On 6/17/26 14:54, Ahmed Tiba wrote:
> +config GHES_CPER_HELPERS
> + bool
> + select UEFI_CPER
This config option should probably also depend on ACPI (could just move
it into the if ACPI..endif block), or at least have a comment that
selector options ensure ACPI is enabled.
- Julian Braha
^ permalink raw reply
* [PATCH v4 0/3] Add support for the REFGEN in the IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-06-17 17:38 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy,
stable, Konrad Dybcio, Krzysztof Kozlowski
IPQ9650 SoC has 2 REFGEN blocks providing the reference current to
the PCIe and USB, UNIPHY PHYs. For the other SoCs, clocks for this block
is enabled on power up but that's not the case for IPQ9650 and we have
to explicitly enable those clocks.
Document the same and add support for it.
Correct the regulator type to REGULATOR_CURRENT, as the REFGEN block
supplies the reference current to PHYs in the SoC, per the REFGEN IP
team, aligning it with the hardware behavior.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Changes in v4:
- reverted back to the logic for is_enabled() as in V1.
- Added the get_status() to report the regulator status to user space
- Dropped the Dmitry's R-b tag due to above changes
- Picked up the R-b tag for binding patch
- Link to v3: https://patch.msgid.link/20260615-ipq9650_refgen-v3-0-5f611623629c@oss.qualcomm.com
Changes in v3:
- Pick up the R-b tags
- Use the lower case hex number in patch 2
- Document the IPQ9650 compatible as separate one not as a fallback and
move the allOf block after the 'required:' section
- Link to v2: https://patch.msgid.link/20260611-ipq9650_refgen-v2-0-d96a91d5b99e@oss.qualcomm.com
Changes in v2:
- New patch 1/3 - change the regulator type to align with HW behavior
- Add the constraints for clock and clock-names property in the binding
- Read the REFGEN_STATUS register to find out the regulator is enabled
- Dropped the unused slab.h
- Link to v1: https://patch.msgid.link/20260602-ipq9650_refgen-v1-0-55e2afa5ff64@oss.qualcomm.com
To: Liam Girdwood <lgirdwood@gmail.com>
To: Mark Brown <broonie@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Kathiravan Thirumoorthy (3):
regulator: qcom-refgen: correct the regulator type to CURRENT
regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
regulator: qcom-refgen: add support for the IPQ9650 SoC
.../regulator/qcom,sdm845-refgen-regulator.yaml | 31 +++++-
drivers/regulator/qcom-refgen-regulator.c | 113 +++++++++++++++++++--
2 files changed, 135 insertions(+), 9 deletions(-)
---
base-commit: 4fa3f5fabb30bf00d7475d5a33459ea83d639bf9
change-id: 20260520-ipq9650_refgen-196b570d8bc0
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 1/3] regulator: qcom-refgen: correct the regulator type to CURRENT
From: Kathiravan Thirumoorthy @ 2026-06-17 17:38 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy,
stable, Konrad Dybcio
In-Reply-To: <20260617-ipq9650_refgen-v4-0-c505ea6c6661@oss.qualcomm.com>
As per the REFGEN IP team, this block supplies the reference current to
the PHYs in the SoC. So, correct the regulator type to REGULATOR_CURRENT
to match with the HW behavior.
Fixes: 7cbfbe237960 ("regulator: Introduce Qualcomm REFGEN regulator driver")
Cc: stable@vger.kernel.org
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/regulator/qcom-refgen-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/qcom-refgen-regulator.c b/drivers/regulator/qcom-refgen-regulator.c
index 299ac3c8c3bc..6a3795469927 100644
--- a/drivers/regulator/qcom-refgen-regulator.c
+++ b/drivers/regulator/qcom-refgen-regulator.c
@@ -66,7 +66,7 @@ static const struct regulator_desc sdm845_refgen_desc = {
.enable_time = 5,
.name = "refgen",
.owner = THIS_MODULE,
- .type = REGULATOR_VOLTAGE,
+ .type = REGULATOR_CURRENT,
.ops = &(const struct regulator_ops) {
.enable = qcom_sdm845_refgen_enable,
.disable = qcom_sdm845_refgen_disable,
@@ -82,7 +82,7 @@ static const struct regulator_desc sm8250_refgen_desc = {
.enable_time = 5,
.name = "refgen",
.owner = THIS_MODULE,
- .type = REGULATOR_VOLTAGE,
+ .type = REGULATOR_CURRENT,
.ops = &(const struct regulator_ops) {
.enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/3] regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-17 17:38 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy,
Krzysztof Kozlowski
In-Reply-To: <20260617-ipq9650_refgen-v4-0-c505ea6c6661@oss.qualcomm.com>
IPQ9650 has two REFGEN blocks which provide reference current to the PCIe,
USB and UNIPHY PHYs. Unlike other supported platforms, IPQ9650 requires the
REFGEN clocks to be enabled explicitly.
Document the IPQ9650 compatible and the required clocks for it.
While at it, move the allOf block after the 'required' property section.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
.../regulator/qcom,sdm845-refgen-regulator.yaml | 31 +++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
index 40f9223d4c27..0bbf7c806fbc 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
@@ -13,9 +13,6 @@ description:
The REFGEN (reference voltage generator) regulator provides reference
voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
-allOf:
- - $ref: regulator.yaml#
-
properties:
compatible:
oneOf:
@@ -39,16 +36,44 @@ properties:
- const: qcom,sm8250-refgen-regulator
- enum:
+ - qcom,ipq9650-refgen-regulator
- qcom,sdm845-refgen-regulator
- qcom,sm8250-refgen-regulator
reg:
maxItems: 1
+ clocks:
+ items:
+ - description: Core reference clock
+ - description: AHB interface clock
+
+ clock-names:
+ items:
+ - const: core
+ - const: hclk
+
required:
- compatible
- reg
+allOf:
+ - $ref: regulator.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,ipq9650-refgen-regulator
+ then:
+ required:
+ - clocks
+ - clock-names
+ else:
+ properties:
+ clocks: false
+ clock-names: false
+
unevaluatedProperties: false
examples:
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/3] regulator: qcom-refgen: add support for the IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-06-17 17:38 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Kathiravan Thirumoorthy
In-Reply-To: <20260617-ipq9650_refgen-v4-0-c505ea6c6661@oss.qualcomm.com>
IPQ9650 SoC has 2 REFGEN blocks providing the reference current to the
PCIe and USB, UNIPHY PHYs. For the other SoCs, clock for this block is
enabled on power up but that's not the case for IPQ9650 and we have to
enable those clocks explicitly to bring up the PHYs properly.
Also, add the get_status() callback to report the regulator status to
the userspace.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
drivers/regulator/qcom-refgen-regulator.c | 109 ++++++++++++++++++++++++++++--
1 file changed, 105 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/qcom-refgen-regulator.c b/drivers/regulator/qcom-refgen-regulator.c
index 6a3795469927..cc72e5a43ba6 100644
--- a/drivers/regulator/qcom-refgen-regulator.c
+++ b/drivers/regulator/qcom-refgen-regulator.c
@@ -3,6 +3,7 @@
// Copyright (c) 2023, Linaro Limited
#include <linux/bitfield.h>
+#include <linux/clk.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -16,6 +17,9 @@
#define REFGEN_BIAS_EN_ENABLE 0x7
#define REFGEN_BIAS_EN_DISABLE 0x6
+#define REFGEN_REG_REFGEN_STATUS 0xc
+#define REFGEN_STATUS_OUT_MASK BIT(3)
+
#define REFGEN_REG_BG_CTRL 0x14
#define REFGEN_BG_CTRL_MASK GENMASK(2, 1)
#define REFGEN_BG_CTRL_ENABLE 0x3
@@ -25,6 +29,17 @@
#define REFGEN_PWRDWN_CTRL5_MASK BIT(0)
#define REFGEN_PWRDWN_CTRL5_ENABLE 0x1
+struct qcom_refgen_regulator_data {
+ const struct regulator_desc *rdesc;
+ bool has_clocks;
+};
+
+struct qcom_refgen_drvdata {
+ struct clk_bulk_data *clks;
+ int num_clks;
+ bool is_enabled;
+};
+
static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
{
regmap_update_bits(rdev->regmap, REFGEN_REG_BG_CTRL, REFGEN_BG_CTRL_MASK,
@@ -62,6 +77,62 @@ static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
return 1;
}
+static int qcom_ipq9650_refgen_enable(struct regulator_dev *rdev)
+{
+ struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
+ int ret;
+
+ ret = clk_bulk_prepare_enable(drvdata->num_clks, drvdata->clks);
+ if (ret)
+ return ret;
+
+ drvdata->is_enabled = true;
+
+ return 0;
+}
+
+static int qcom_ipq9650_refgen_disable(struct regulator_dev *rdev)
+{
+ struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
+
+ clk_bulk_disable_unprepare(drvdata->num_clks, drvdata->clks);
+
+ drvdata->is_enabled = false;
+
+ return 0;
+}
+
+static int qcom_ipq9650_refgen_is_enabled(struct regulator_dev *rdev)
+{
+ struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
+
+ return drvdata->is_enabled;
+}
+
+static int qcom_ipq9650_refgen_get_status(struct regulator_dev *rdev)
+{
+ u32 val;
+
+ regmap_read(rdev->regmap, REFGEN_REG_REFGEN_STATUS, &val);
+ if (FIELD_GET(REFGEN_STATUS_OUT_MASK, val))
+ return REGULATOR_STATUS_ON;
+
+ return REGULATOR_STATUS_OFF;
+}
+
+static const struct regulator_desc ipq9650_refgen_desc = {
+ .enable_time = 5,
+ .name = "refgen",
+ .owner = THIS_MODULE,
+ .type = REGULATOR_CURRENT,
+ .ops = &(const struct regulator_ops) {
+ .enable = qcom_ipq9650_refgen_enable,
+ .disable = qcom_ipq9650_refgen_disable,
+ .is_enabled = qcom_ipq9650_refgen_is_enabled,
+ .get_status = qcom_ipq9650_refgen_get_status,
+ },
+};
+
static const struct regulator_desc sdm845_refgen_desc = {
.enable_time = 5,
.name = "refgen",
@@ -90,6 +161,19 @@ static const struct regulator_desc sm8250_refgen_desc = {
},
};
+static const struct qcom_refgen_regulator_data ipq9650_data = {
+ .rdesc = &ipq9650_refgen_desc,
+ .has_clocks = true,
+};
+
+static const struct qcom_refgen_regulator_data sdm845_data = {
+ .rdesc = &sdm845_refgen_desc,
+};
+
+static const struct qcom_refgen_regulator_data sm8250_data = {
+ .rdesc = &sm8250_refgen_desc,
+};
+
static const struct regmap_config qcom_refgen_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -98,6 +182,8 @@ static const struct regmap_config qcom_refgen_regmap_config = {
static int qcom_refgen_probe(struct platform_device *pdev)
{
+ const struct qcom_refgen_regulator_data *data;
+ struct qcom_refgen_drvdata *drvdata = NULL;
struct regulator_init_data *init_data;
struct regulator_config config = {};
const struct regulator_desc *rdesc;
@@ -106,10 +192,23 @@ static int qcom_refgen_probe(struct platform_device *pdev)
struct regmap *regmap;
void __iomem *base;
- rdesc = of_device_get_match_data(dev);
- if (!rdesc)
+ data = of_device_get_match_data(dev);
+ if (!data)
return -ENODATA;
+ if (data->has_clocks) {
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->num_clks = devm_clk_bulk_get_all(dev, &drvdata->clks);
+ if (drvdata->num_clks < 0)
+ return dev_err_probe(dev, drvdata->num_clks,
+ "failed to get clocks\n");
+ }
+
+ rdesc = data->rdesc;
+
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -126,6 +225,7 @@ static int qcom_refgen_probe(struct platform_device *pdev)
config.init_data = init_data;
config.of_node = dev->of_node;
config.regmap = regmap;
+ config.driver_data = drvdata;
rdev = devm_regulator_register(dev, rdesc, &config);
if (IS_ERR(rdev))
@@ -135,8 +235,9 @@ static int qcom_refgen_probe(struct platform_device *pdev)
}
static const struct of_device_id qcom_refgen_match_table[] = {
- { .compatible = "qcom,sdm845-refgen-regulator", .data = &sdm845_refgen_desc },
- { .compatible = "qcom,sm8250-refgen-regulator", .data = &sm8250_refgen_desc },
+ { .compatible = "qcom,ipq9650-refgen-regulator", .data = &ipq9650_data },
+ { .compatible = "qcom,sdm845-refgen-regulator", .data = &sdm845_data },
+ { .compatible = "qcom,sm8250-refgen-regulator", .data = &sm8250_data },
{ }
};
MODULE_DEVICE_TABLE(of, qcom_refgen_match_table);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 10/10] RAS: add firmware-first CPER provider
From: Julian Braha @ 2026-06-17 17:40 UTC (permalink / raw)
To: Ahmed Tiba, Rafael J. Wysocki, Tony Luck, Borislav Petkov,
Hanjun Guo, Mauro Carvalho Chehab, Shuai Xue, Len Brown,
Saket Dumbre, Davidlohr Bueso, Jonathan Cameron, Dave Jiang,
Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, linux-acpi, acpica-devel, linux-cxl, devicetree,
linux-edac, linux-doc, Dmitry.Lamerov
In-Reply-To: <20260617-topics-ahmtib01-ras_ffh_arm_internal_review-v6-10-91f725174aa0@arm.com>
Hi again Ahmed,
On 6/17/26 14:54, Ahmed Tiba wrote:
> +config RAS_CPER_ESOURCE
> + bool "Firmware-first CPER error source block provider"
> + select GHES_CPER_HELPERS
> + help
> + Enable support for firmware-first Common Platform Error Record
> + (CPER) error source block providers. The current in-tree user is
> + described by the arm,ras-cper DeviceTree binding. The driver
> + reuses the existing GHES CPER helpers so the error processing
> + matches the ACPI code paths, but it can be built even when ACPI is
> + disabled.
Yep, sure enough, this patch causes a build error when you enable
RAS_CPER_ESOURCE without enabling ACPI:
drivers/firmware/efi/cper-x86.c: In function ‘cper_print_proc_ia’:
drivers/firmware/efi/cper-x86.c:352:21: error: implicit declaration of
function ‘arch_apei_report_x86_error’ [-Wimplicit-function-declaration]
352 | arch_apei_report_x86_error(ctx_info,
proc->lapic_id)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
- Julian Braha
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-06-17 17:41 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260409122110.214680-1-ayushi.makhija@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 05:51:09PM +0530, Ayushi Makhija wrote:
Here's a link to "v1":
https://lore.kernel.org/all/20260323102229.1546504-1-quic_amakhija@quicinc.com/
Which makes this v2.
You also ignored my feedback.
Thank you,
Bjorn
> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>
> Fixes: 4fca6849864d ("drm/panel: Add Novatek NT37801 panel driver")
> Signed-off-by: Ayushi Makhija <ayushi.makhija@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> index 3837f6785320..6ba4e69bf377 100644
> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
>
> vreg_l12b_1p8: ldo12 {
> regulator-name = "vreg_l12b_1p8";
> - regulator-min-microvolt = <1200000>;
> + regulator-min-microvolt = <1650000>;
> regulator-max-microvolt = <1800000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> regulator-allow-set-load;
> --
> 2.34.1
>
^ 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