* Re: [PATCH v1 1/8] ASoC: dt-bindings: qcom,apr: Add modem_apps GLINK channel for shikra
From: Krzysztof Kozlowski @ 2026-06-22 13:20 UTC (permalink / raw)
To: Mohammad Rafi Shaik
Cc: Srinivas Kandagatla, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260616201315.2565115-2-mohammad.rafi.shaik@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 01:43:08AM +0530, Mohammad Rafi Shaik wrote:
> Add support for the modem_apps GLINK channel on Shikra, as audio
> processing is handled through the modem DSP.
>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 8/8] arm64: defconfig: Enable Qualcomm QAIF and WSA885X-I2C drivers
From: Krzysztof Kozlowski @ 2026-06-22 13:19 UTC (permalink / raw)
To: Mohammad Rafi Shaik
Cc: Srinivas Kandagatla, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260622-analytic-pigeon-of-force-bd53c6@quoll>
On 22/06/2026 15:18, Krzysztof Kozlowski wrote:
> On Wed, Jun 17, 2026 at 01:43:15AM +0530, Mohammad Rafi Shaik wrote:
>> Enable the QAIF CPU DAI and WSA885X I2C codec as modules in
>> arm64 defconfig.
>>
>> These options are required to exercise the Shikra EVK
>
> Qualcomm Shikra EVK, but anyway the problem is that:
> git grep -i "Shikra EVK"
> gives me zero results.
>
> I already commented about this for some other patches.
>
And SND_SOC_WSA885X_I2C also does not exist in next-20260619.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 8/8] arm64: defconfig: Enable Qualcomm QAIF and WSA885X-I2C drivers
From: Krzysztof Kozlowski @ 2026-06-22 13:18 UTC (permalink / raw)
To: Mohammad Rafi Shaik
Cc: Srinivas Kandagatla, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260616201315.2565115-9-mohammad.rafi.shaik@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 01:43:15AM +0530, Mohammad Rafi Shaik wrote:
> Enable the QAIF CPU DAI and WSA885X I2C codec as modules in
> arm64 defconfig.
>
> These options are required to exercise the Shikra EVK
Qualcomm Shikra EVK, but anyway the problem is that:
git grep -i "Shikra EVK"
gives me zero results.
I already commented about this for some other patches.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: brige: lt9611c: add port-select property for LT9611C
From: Krzysztof Kozlowski @ 2026-06-22 13:16 UTC (permalink / raw)
To: Laurent Pinchart, Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Luca Ceresoli, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, dri-devel,
devicetree, linux-kernel, boss, qc-display-maintainer
In-Reply-To: <20260622120801.GA3899757@killaraus.ideasonboard.com>
On 22/06/2026 14:08, Laurent Pinchart wrote:
> On Mon, Jun 22, 2026 at 05:31:36PM +0530, Mohit Dsor wrote:
>> On Thu, Jun 11, 2026 at 12:40:38PM +0200, Krzysztof Kozlowski wrote:
>>> On Thu, Jun 11, 2026 at 02:44:56AM +0530, Mohit Dsor wrote:
>>>> Add a new optional `lontium,port-select` property to describe the DSI
>>>> input port configuration for the LT9611C variant, which supports
>>>> single-port (A or B) and dual-port (A+B) operation.
>>>>
>>>> This property allows explicitly selecting the active DSI input port(s):
>>>> 0 = port A (default)
>>>> 1 = port B
>>>> 2 = ports A and B (dual-port)
>>>>
>>>> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
>>>> ---
>>>> .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 13 +++++++++++++
>>>> 1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>> index e0821a63d9d7..77220f893bf8 100644
>>>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>> @@ -41,6 +41,17 @@ properties:
>>>> vcc-supply:
>>>> description: Regulator for 3.3V IO power.
>>>>
>>>> + lontium,port-select:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>> + enum: [0, 1, 2]
>>>> + default: 0
>>>> + description: |
>>>> + Selects which DSI input port(s) the bridge uses. Only relevant for
>>>> + the lontium,lt9611c compatible.
>>>> + 0 = PORT_SELECT_A - single DSI port A (default)
>>>> + 1 = PORT_SELECT_B - single DSI port B
>>>> + 2 = PORT_SELECT_AB - dual DSI ports A and B
>>>
>>> Why graph is not enough? Seems exactly duplicating the graph ports.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> Hi Krzysztof,
>>
>> Thanks for the review.
>>
>> The graph describes the physical connectivity between endpoints,
>> however it does not fully capture the internal mode of operation of
>> the LT9611C. This variant supports multiple functional configurations
>> (single-port A, single-port B, or dual-port A+B), which affect how the
>> hardware internally combines or selects DSI inputs.
>>
>> In particular:
>> - The graph can describe connections to both ports, but it does not
>> indicate whether the device should operate in single-port or dual-port
>> aggregation mode.
>> - For single-port use, both ports may be described in DT for board
>> consistency, while the driver still needs to know which port is
>> actively selected.
>> - Dual-port mode requires explicit configuration even when both
>> endpoints are present in the graph.
>
> If both modes of operation are possible on a given board, then it sounds
> like the mode should be selected at runtime, not hardcoded in the device
> tree.
Yeah. Especially "while the driver still needs to know which port is
actively selected" for a case when DT already clearly defines which
ports are available, feels like 100% runtime decision, e.g. based on
what is actually plugged into the connector.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm: dts: xilinx: Add support for MYIR MYS-7Z020-V2 board
From: Michal Simek @ 2026-06-22 13:15 UTC (permalink / raw)
To: Liu Yu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-arm-kernel
In-Reply-To: <SY3PPF19552C60735AFA1041A0183DCA07CC7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On 6/19/26 15:23, Liu Yu wrote:
> Add device tree support for the MYIR MYS-7Z020-V2 board based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> The board supports:
> - UART serial console
> - MicroSD card interface
> - Gigabit Ethernet
> - QSPI NOR flash
> - GPIO-based user LEDs and push-button
>
> Link: https://www.myirtech.com/list.asp?id=708
this is pointing to Z-turn Board V2 and above you are using MYS-7Z020-V2
which is not available on this link.
Why should this be merged? What's so special about this board?
Zynq went to production in 2013. Why should we merge description for "unknown"
board using 13 years old chip?
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: renesas: r9a09g077: Add LCDC and PLL3 clock support for RZ/T2H display pipeline
From: Geert Uytterhoeven @ 2026-06-22 13:13 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260618181949.3036280-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Thu, 18 Jun 2026 at 20:19, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the clock definitions and PLL logic required to supply the LCDC
> (VSPD/FCPVD/DU) blocks on the RZ/T2H (R9A09G077) SoC. The RZ/T2H display
> subsystem depends on a dedicated PLL (PLL3) and a set of new derived
> clocks.
>
> Introduce a new PLL clock type and implement rate recalculation,
> programming and locking sequences for PLL3 using the RZ/T2H specific
> divider and VCO limits. Add the corresponding muxes and divider entries,
> expose the LCDC core clock, and register the LCDC module clock using the
> correct PCLK parent.
>
> This enables the RZ/T2H clock driver to generate the display pipeline
> clocking tree needed by the DU and VSP-based composition engines, allowing
> upcoming display support to be integrated without duplicating CPG logic.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3->v4:
> - Added RB tag from Geert.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.3.
> + rate_millihz = mul_u32_u32(req->rate, MILLI);
The issue pointed out by Sashiko (req->rate is unsigned long, i.e. can
be larger than u32 on 64-bit) is valid, but I believe it can't happen
in practice. Still, would be good to fix it in a subsequent patch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Krzysztof Kozlowski @ 2026-06-22 13:12 UTC (permalink / raw)
To: Frieder Schrempf, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <085262ba-32e5-4011-8df3-5a677575b2db@kontron.de>
On 17/06/2026 13:36, Frieder Schrempf wrote:
> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
>> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>
>>> Some SoCs like the i.MX9 family allow full access to the fuses only
>>> through the secure enclave firmware API. Add a property to reference
>>> the secure enclave node and let the driver use the API.
>>>
>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>>> ---
>>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> index a8076d0e2737..14a6429f4a4c 100644
>>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>> @@ -53,6 +53,10 @@ properties:
>>> reg:
>>> maxItems: 1
>>>
>>> + secure-enclave:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: A phandle to the secure enclave node
>>
>> Two things here:
>> 1. Here you describe what for is that phandle, how it is used by the
>> hardware. Currently the description repeats the property name and type,
>> so not much useful.
>
> Ok, agree.
>
>>
>> 2. If you access OTP via firmware, then this is completely different
>> interface than MMIO, thus:
>> A. reg is not appropriate
>> B. Device is very different thus it has different compatible and I even
>> claim should be in different binding. Devices having completely
>> different SW interface should not be in the same binding, at least
>> usually.
>>
>> If any of above is not accurate, then your commit msg should answer why
>> and give some background.
>
> Thanks for the feedback!
>
> The driver currently uses the limited MMIO (FSB) interface to access the
> OTPs. The intention is to support the firmware interface alongside the
> MMIO interface so the driver can pick the interface that is available
> (firmware might not be loaded) and fallback to MMIO.
>
> Following your argument would mean a driver deciding by itself which
> interface to use at runtime is not something we want to have in general,
> right?
No, the property fits DT, but above information should be in commit msg.
If this SoC has indeed both interfaces - MMIO and firmware calls - then
everything is in general fine. I assumed that is not the case and MMIO
is not really working.
What was confusing is that it feels like you are changing existing
interface, but why wasn't all this documented in the beginning? There is
imx9 in this binding already, so was it working? Was it not working at
all? Commit msg must clarify that.
>
> In turn this would mean we need two drivers, or at least two
> compatibles/bindings for something that is effectively the same hardware.
Driver design is orthogonal choice here.
It can reside in separate binding, if MMIO is still valid, but till
everything is not yet too complex can be also this binding file.
If it stays in this binding, then you need to restrict properties per
variant, so add if:then: block which will disallow the phandle for other
variants.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for calculations
From: Geert Uytterhoeven @ 2026-06-22 13:07 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Prabhakar, conor+dt, wsa+renesas, robh, devicetree
In-Reply-To: <20260618183334.F10DD1F000E9@smtp.kernel.org>
On Fri, 19 Jun 2026 at 14:11, <sashiko-bot@kernel.org> wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Silent 32-bit unsigned integer overflow and zero-extension corrupts PLL calculations when 'p.k' is negative on 32-bit architectures.
> --
>
> commit 68e2983ee9a6e8d870b293872442cdc2bc7b3e74
> Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for calculations
>
> Introduce a per-SoC PLL reference input frequency parameter to avoid
> relying on a hardcoded 24MHz constant during PLL configuration math.
>
> > diff --git a/drivers/clk/renesas/rzv2h-cpg.c b/drivers/clk/renesas/rzv2h-cpg.c
> > index e271c04cee34f..fff89f2bdc0b2 100644
> > --- a/drivers/clk/renesas/rzv2h-cpg.c
> > +++ b/drivers/clk/renesas/rzv2h-cpg.c
>
> [ ... ]
>
> > @@ -335,9 +335,9 @@ bool rzv2h_get_pll_pars(const struct rzv2h_pll_limits *limits,
> > continue;
> >
> > /* PLL_M component of (output * 65536 * PLL_P) */
> > - output = mul_u32_u32(p.m * 65536, RZ_V2H_OSC_CLK_IN_MEGA);
> > + output = mul_u32_u32(p.m * 65536, input_fref);
> > /* PLL_K component of (output * 65536 * PLL_P) */
> > - output += p.k * RZ_V2H_OSC_CLK_IN_MEGA;
> > + output += p.k * input_fref;
> [Severity: High]
> This is a pre-existing issue, but does this multiplication safely handle
> negative values of p.k on 32-bit architectures?
>
> Since p.k is a signed 16-bit integer (with limits->k.min allowed to be -32768)
> and input_fref is a 32-bit unsigned long, C promotion rules on 32-bit builds
> will convert p.k to a 32-bit unsigned integer before the multiplication.
>
> If p.k is negative, the resulting 32-bit unsigned modulo value will be
> zero-extended when added to the 64-bit output variable. This would incorrectly
> add over 4 billion to the output frequency rather than subtracting the
> intended fraction, which could severely break the PLL parameter search.
Good point!
Although this driver is only used on 64-bit platforms, the code might
still be used as an example, and copied for use on a 32-bit platform.
> Could p.k be cast to s64 before the multiplication to prevent this unsigned
> overflow and ensure proper sign-extension into the 64-bit output?
>
> > /* Make it in mHz */
> > output *= MILLI;
> > output = DIV_U64_ROUND_CLOSEST(output, 65536 * p.p * divider);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260618181949.3036280-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
From: Konrad Dybcio @ 2026-06-22 13:03 UTC (permalink / raw)
To: Qiang Yu
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <ajkvV28hEWFfnwa6@hu-qianyu-lv.qualcomm.com>
On 6/22/26 2:49 PM, Qiang Yu wrote:
> On Mon, Jun 22, 2026 at 01:35:45PM +0200, Konrad Dybcio wrote:
>> On 6/22/26 7:11 AM, Qiang Yu wrote:
>>> Mahua is based on Glymur but uses a different QREF topology, requiring
>>> distinct regulator lists and clock descriptors for its PCIe clock
>>> references.
>>>
>>> Add mahua-specific regulator arrays and clk descriptor table, and use
>>> match_data to select the correct descriptor table per compatible string at
>>> probe time.
>>>
>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>> ---
[...]
>> You're also missing PCIe_1_CLKREF_EN (+0x48) (for PCIe5)
>> which goes through CXO1_>TX->RPT0->RPT1->RPT2->RX2
>
> I have removed PCIe_1_CLKREF_EN in dts node because PCIe5 PHY doesn't
> require QREF. So I didn't provide its structure here.
I don't quite get what you mean. I see that it is there in the graph
Konrad
^ permalink raw reply
* Re: [PATCH v4 4/5] clk: renesas: Extract RZ/V2H PLL calculation helpers into shared library
From: Geert Uytterhoeven @ 2026-06-22 13:02 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260618181949.3036280-5-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, 18 Jun 2026 at 20:19, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Move the RZ/V2H PLL and divider parameter calculation helpers from
> rzv2h-cpg.c into a new reusable library.
>
> Introduce the CLK_RZV2H_CPG_LIB Kconfig symbol and add
> rzv2h-cpg-lib.c to host the PLL parameter search algorithms currently
> implemented by rzv2h_get_pll_pars() and rzv2h_get_pll_divs_pars().
> Export the helpers as rzv2h_cpg_get_pll_pars() and
> rzv2h_cpg_get_pll_divs_pars() for use by other drivers.
>
> Update the public clock header to expose the new interfaces and provide
> compatibility aliases for the existing helper names, avoiding build
> breakage for current users while allowing future conversions to the new
> API.
>
> This prepares for reuse of the PLL and divider calculation logic by
> other Renesas clock drivers, including upcoming RZ/T2H and RZ/N2H CPG
> support, without duplicating the implementation.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v3->v4:
> - Added macros for rzv2h_get_pll_pars and rzv2h_get_pll_divs_pars
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 3/5] dt-bindings: clock: renesas,r9a09g077/87: Add LCDC_CLKD clock ID
From: Geert Uytterhoeven @ 2026-06-22 13:01 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar, Conor Dooley
In-Reply-To: <20260618181949.3036280-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, 18 Jun 2026 at 20:19, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the LCDC clockd (LCDC_CLKD) definition for the Renesas RZ/T2H
> (R9A09G077) and RZ/N2H (R9A09G087) SoCs. LCDC_CLKD is used as the
> operating clock for LCDC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3->v4:
> - No change
No need to resend queued patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 2/5] clk: renesas: cpg-mssr: Implement dedicated MSTP delay logic for RZ/T2H LCDC and RTC
From: Geert Uytterhoeven @ 2026-06-22 13:00 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260618181949.3036280-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, 18 Jun 2026 at 20:19, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Introduce a dedicated clock delay mechanism, cpg_rzt2h_mstp_delay(), to
> satisfy the module-stop (MSTP) state release requirements specified in
> the RZ/T2H hardware manual.
>
> Per the hardware manual, while a standard 10 us delay (satisfying 7 dummy
> reads) is sufficient for most IP blocks, the LCDC requires 100 dummy reads
> (142 us) and the RTC requires 300 dummy reads (428 us) to stabilize after
> being released from a module-stop state.
>
> Implement a conditional bitmask filter helper that switches wait
> intervals based on the packaged module clock index. In
> cpg_mstp_clock_endisable(), the clock index and individual target bits are
> known, allowing an exact match. In the resume path cpg_mssr_resume_noirq(),
> where individual bits are not tracked, pass a fallback register index base
> (`reg * 32`) with bit verification masked out to match on the peripheral's
> register group block instead.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3->v4:
> - Added RB tag from Geert.
No need to resend queued patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 1/5] clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for calculations
From: Geert Uytterhoeven @ 2026-06-22 12:59 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260618181949.3036280-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Thu, 18 Jun 2026 at 20:19, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Introduce a per-SoC PLL reference input frequency parameter to avoid
> relying on a hardcoded 24MHz constant during PLL configuration math.
>
> Add an input_fref member to struct rzv2h_pll_limits. In the core
> calculation helper rzv2h_get_pll_pars(), derive the base input clock
> rate from limits->input_fref, utilizing the conditional ternary operator
> to fall back to 24MHz if the struct field is left uninitialized (0),
> and drop the obsolete macro RZ_V2H_OSC_CLK_IN_MEGA.
>
> This abstraction permits the reuse of the common PLL divider logic on
> newer SoC platforms like the RZ/T2H, which feature a 48 MHz PLL reference
> clock input instead of the 24 MHz signal used by RZ/V2H(P), without
> disrupting existing platforms.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v3->v4:
> - Fixed MHz to Hz for input_fref in the doc comment for
> struct rzv2h_pll_limits.
> - Added RB tag from Geert.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: add Axiado AX3000 PWM
From: Krzysztof Kozlowski @ 2026-06-22 12:50 UTC (permalink / raw)
To: Petar Stepanovic, Akhila Kavi, Prasad Bolisetty,
Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-pwm, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-axiado-ax3000-pwm-v1-1-c9797a909414@axiado.com>
On 18/06/2026 14:26, Petar Stepanovic wrote:
> +
> +description:
> + The Axiado PWM controller found on AX3000 and AX3005 SoCs.
> +
> +allOf:
> + - $ref: pwm.yaml#
> +
> +properties:
> + compatible:
> + const: axiado,ax3000-pwm
Description mentions AX3005, but there is no ax3005 compatible here.
This is confusing.
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: pwm
Drop clock-names, not really useful if it has block's name.
> +
> + "#pwm-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> +
> +additionalProperties: false
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-22 12:50 UTC (permalink / raw)
To: Janani Sunil
Cc: Nuno Sá, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <013aba24-c30c-44a8-8511-96278edb3f4a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On Mon, Jun 22, 2026 at 02:39:21PM +0200, Janani Sunil wrote:
>
> On 6/22/26 14:14, Conor Dooley wrote:
> > On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
> > > > > > > Why do you think the microchip devices won't work? Does the spi core
> > > > > > > reject multiple devices with the same chip select being registered or
> > > > > > > something like that?
> > > > > > Not sure how things work atm. But I'm fairly sure it used to be like
> > > > > > that. SPI would reject devices on the same controller and CS. Now that
> > > > > > we support more than one CS per controller, not sure how things work.
> > > > > We always supported more than one per CS per controller. I guess you mean
> > > > > per device.
> > > > Obviously :)
> > > > > > Janani, maybe you can give it a try?
> > > > > I think we'd need to get it to work with shared gpio proxy which maybe
> > > > > will just get set up under the hood. This used to be opt in, but seems
> > > > > that changed fairly recently so maybe some of us are working with out
> > > > > of date knowledge! I haven't played with it yet, so might not be
> > > > > that simple.
> > > > >
> > > > What I meant for Janani was basically testing two devices on the same CS
> > > > as in my pseudo DT. For the GPIO, you mean having a way to select
> > > > between devices on the same CS?
> > > >
> > > > For these devices the pin id numbers get's setted up as part of the spi message
> > > > so my assumption is that all of them will receive the message but only one acks it.
> > > >
> > > > - Nuno Sá
> > > Hi Everyone,
> > >
> > > I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
> > > https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
> >
> > Can you try again, but delete that check and allow the code to continue?
> > Worth knowing if the problem is policy (which makes sense for 99.99% of
> > devices that cannot share a chip select) or actually not supported by
> > the spi core code.
>
> Hi Conor,
>
> The CS conflict check is only a part of the problem. Even after removing it, the second device fails at the sysfs layer.
> The device naming in spi_dev_set_name() produces spi{bus}.{cs}. Both devices register as spi0.0 here, making it a duplicate directory.
That doesn't seem insurmountable, since these devices would really need
to be registered with a flag that notes sharing the cs is okay to solve
the problem in spi_dev_check_cs() which could be re-employed in
spi_dev_set_name() to append something.
Something could very well be the top bits of the address field used for
differentiation for spi{bus}.{cs}.{addr7..6}.
Whatever about this being the correct approach for your devices, there's
existing devices for which this would be needed to fully support, and
that doesn't seem like all that much work to do, if that's all that
prevents it.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
From: Qiang Yu @ 2026-06-22 12:49 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <5f32d4c2-f90d-4f66-96b1-c9c7987ac18e@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 01:35:45PM +0200, Konrad Dybcio wrote:
> On 6/22/26 7:11 AM, Qiang Yu wrote:
> > Mahua is based on Glymur but uses a different QREF topology, requiring
> > distinct regulator lists and clock descriptors for its PCIe clock
> > references.
> >
> > Add mahua-specific regulator arrays and clk descriptor table, and use
> > match_data to select the correct descriptor table per compatible string at
> > probe time.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +static const struct qcom_clk_ref_desc tcsr_cc_mahua_clk_descs[] = {
> > + [TCSR_EDP_CLKREF_EN] = {
> > + .name = "tcsr_edp_clkref_en",
> > + .offset = 0x60,
>
> EDP goes through CXO1->TX->RPT0->RX0
>
> > + },
> > + [TCSR_PCIE_2_CLKREF_EN] = {
> > + .name = "tcsr_pcie_2_clkref_en",
> > + .offset = 0x4c,
> > + .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
> > + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
>
> this is apparently for PCIE4 (the name you used unfortunately actually
> matches the register in TCSR..)
>
> (ok)
>
> > + },
> > + [TCSR_PCIE_3_CLKREF_EN] = {
> > + .name = "tcsr_pcie_3_clkref_en",
> > + .offset = 0x54,
> > + .regulator_names = mahua_tcsr_tx1_rpt012_rx2_regulators,
> > + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt012_rx2_regulators),
>
> This is PCIe3 (actually)
>
> CXO1->TX->RPT0->RPT1->RPT2->RX2 (ok)
>
> > + },
> > + [TCSR_PCIE_4_CLKREF_EN] = {
> > + .name = "tcsr_pcie_4_clkref_en",
> > + .offset = 0x58,
> > + .regulator_names = mahua_tcsr_tx1_rpt01_rx1_regulators,
> > + .num_regulators = ARRAY_SIZE(mahua_tcsr_tx1_rpt01_rx1_regulators),
>
> This is PCIe6
>
> CXO1->TX->RPT0->RPT1->RX1 (ok)
>
> > + },
> > + [TCSR_USB2_1_CLKREF_EN] = {
> > + .name = "tcsr_usb2_1_clkref_en",
> > + .offset = 0x6c,
> > + },
>
> (usb_hs phy)
> CXO1->TX->RPT3->RPT4->RPT5->RX3
>
> > + [TCSR_USB2_2_CLKREF_EN] = {
> > + .name = "tcsr_usb2_2_clkref_en",
> > + .offset = 0x70,
> > + },
>
> (mp0 hsphy)
> CXO1->TX->RPT3->RPT4->RPT5->RX3
>
> > + [TCSR_USB2_3_CLKREF_EN] = {
> > + .name = "tcsr_usb2_3_clkref_en",
> > + .offset = 0x74,
> > + },
>
> (mp1 hsphy)
> CXO1->TX->RPT3->RPT4->RPT5->RX3
>
>
> > + [TCSR_USB2_4_CLKREF_EN] = {
> > + .name = "tcsr_usb2_4_clkref_en",
> > + .offset = 0x88,
> > + },
>
> same as eDP
>
> > + [TCSR_USB3_0_CLKREF_EN] = {
> > + .name = "tcsr_usb3_0_clkref_en",
> > + .offset = 0x64,
> > + },
>
> (mp0 uniphy)
> same as TCSR_USB2_3_CLKREF_EN
>
> > + [TCSR_USB3_1_CLKREF_EN] = {
> > + .name = "tcsr_usb3_1_clkref_en",
> > + .offset = 0x68,
> > + },
>
> (mp1 uniphy)
> same as TCSR_USB2_3_CLKREF_EN
>
> > + [TCSR_USB4_1_CLKREF_EN] = {
> > + .name = "tcsr_usb4_1_clkref_en",
> > + .offset = 0x44,
> > + },
>
> ok
> (although there is a comment suggesting this may be NC..)
I checked ipcatlog, TCSR_USB4_1_CLKREF_EN is not in used. I suspect this
USB PHY uses CXO as refclk. If so, we need to remove this entry.
>
> > + [TCSR_USB4_2_CLKREF_EN] = {
> > + .name = "tcsr_usb4_2_clkref_en",
> > + .offset = 0x5c,
> > + },
>
> CXO1->TX->RPT0->RPT1->RX1
>
>
> You're also missing PCIe_1_CLKREF_EN (+0x48) (for PCIe5)
> which goes through CXO1_>TX->RPT0->RPT1->RPT2->RX2
I have removed PCIe_1_CLKREF_EN in dts node because PCIe5 PHY doesn't
require QREF. So I didn't provide its structure here.
>
> [...]
>
> > static int tcsr_cc_glymur_probe(struct platform_device *pdev)
> > {
> > + const struct tcsrcc_glymur_data *data = device_get_match_data(&pdev->dev);
>
> Please null-check this
>
Okay. Will also add the regulator list for other instance as you suggested
- Qiang Yu
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
From: Krzysztof Kozlowski @ 2026-06-22 12:43 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <20fa15e1-316b-44fa-b59d-99cb7fe78bb0@oss.qualcomm.com>
On 22/06/2026 04:28, Fenglin Wu wrote:
>
> On 6/19/2026 12:18 PM, Krzysztof Kozlowski wrote:
>> On 17/06/2026 13:02, Fenglin Wu wrote:
>>> On 6/17/2026 6:35 PM, Krzysztof Kozlowski wrote:
>>>> On Tue, Jun 16, 2026 at 03:08:24AM -0700, Fenglin Wu wrote:
>>>>> ....
>>>>> +
>>>>> + qcom,lra-period-us:
>>>>> + description:
>>>>> + LRA actuator initial resonance period in microseconds
>>>>> + (1,000,000 / resonant_freq_hz). Used to configure T_LRA-based play
>>>>> + rates and the auto-resonance zero-crossing window.
>>>> This does not feel like static characteristic. Isn't period depending on
>>>> intensity of vibration you want to have? Why would that be fixed per
>>>> board?
>>> This period is specifically used for playbacks that require
>>> auto-resonance to be enabled, which I referred to as "T_LRA-based" and
>>> "auto-resonance zero-crossing window." It plays a key role in the
>>> "DIRECT_PLAY" mode, which produces a constant vibration effect. To
>>> adjust the vibration intensity during this constant effect, the hardware
>>> does it by scaling the peak voltage of the driver signals, rather than
>>> changing the frequency.
>> But maybe changing frequency runtime still would be useful?
> It could be, but the LRA F0 (resonant frequency) still needs to be the
> starting point. You can control vibration intensity by driving the LRA
> slightly off resonance by a given percentage—for example, to reach 50%
> vibration, you could probably drive it 10% off resonant frequency, and
> that mapping also depends on the LRA characteristic. Keep in mind that
> LRA is a spring-mass resonant system, so its output is not linear with
> driving frequency; it is a High_Q system, and its output actually shows
> a sharp peak at the resonance point. By contrast, the relationship
> between driving voltage and its output is much more linear, so scaling
> vibration intensity by adjusting the driving voltage is easier to
> control. Qcom haptics HW scales vibration intensity in DIRECT_PLAY mode
> (for constant vibration effect) by scaling the driving voltage instead.
> That said, the HW can also change the driving waveform frequency by
> updating the T-LRA registers, and this property has to be specified as
> an initial value; otherwise, you won't have a baseline to achieve that.
>
OK, property is fine.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-06-22 12:39 UTC (permalink / raw)
To: Conor Dooley
Cc: Nuno Sá, Jonathan Cameron, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622-overbid-yonder-3fdfee9eda7a@spud>
On 6/22/26 14:14, Conor Dooley wrote:
> On Mon, Jun 22, 2026 at 01:54:25PM +0200, Janani Sunil wrote:
>>>>>> Why do you think the microchip devices won't work? Does the spi core
>>>>>> reject multiple devices with the same chip select being registered or
>>>>>> something like that?
>>>>> Not sure how things work atm. But I'm fairly sure it used to be like
>>>>> that. SPI would reject devices on the same controller and CS. Now that
>>>>> we support more than one CS per controller, not sure how things work.
>>>> We always supported more than one per CS per controller. I guess you mean
>>>> per device.
>>> Obviously :)
>>>>> Janani, maybe you can give it a try?
>>>> I think we'd need to get it to work with shared gpio proxy which maybe
>>>> will just get set up under the hood. This used to be opt in, but seems
>>>> that changed fairly recently so maybe some of us are working with out
>>>> of date knowledge! I haven't played with it yet, so might not be
>>>> that simple.
>>>>
>>> What I meant for Janani was basically testing two devices on the same CS
>>> as in my pseudo DT. For the GPIO, you mean having a way to select
>>> between devices on the same CS?
>>>
>>> For these devices the pin id numbers get's setted up as part of the spi message
>>> so my assumption is that all of them will receive the message but only one acks it.
>>>
>>> - Nuno Sá
>> Hi Everyone,
>>
>> I tested the case where there are two devices on the same CS. The SPI core does reject it at spi_dev_check_cs():
>> https://github.com/torvalds/linux/blob/master/drivers/spi/spi.c#L631
>
> Can you try again, but delete that check and allow the code to continue?
> Worth knowing if the problem is policy (which makes sense for 99.99% of
> devices that cannot share a chip select) or actually not supported by
> the spi core code.
Hi Conor,
The CS conflict check is only a part of the problem. Even after removing it, the second device fails at the sysfs layer.
The device naming in spi_dev_set_name() produces spi{bus}.{cs}. Both devices register as spi0.0 here, making it a duplicate directory.
- Janani Sunil
^ permalink raw reply
* Re: [PATCH v6 3/8] clk: qcom: Add generic clkref_en support
From: Qiang Yu @ 2026-06-22 12:36 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <032d6002-2205-431a-abc7-7c0a010c9897@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 02:13:22PM +0200, Konrad Dybcio wrote:
> On 6/22/26 7:11 AM, Qiang Yu wrote:
> > Before XO refclk is distributed to PCIe/USB/eDP PHYs, it passes through
> > a QREF block. QREF is powered by dedicated LDO rails, and the clkref_en
> > register controls whether refclk is gated through to the PHY side.
> >
> > These clkref controls are different from typical GCC branch clocks:
> > - only a single enable bit is present, without branch-style config bits
> > - regulators must be voted before enable and unvoted after disable
> >
> > Model this as a dedicated clk_ref clock type with custom clk_ops instead
> > of reusing struct clk_branch semantics.
> >
> > Also provide a common registration/probe API so the same clkref model
> > can be reused regardless of where clkref_en registers are placed, e.g.
> > TCSR on glymur and TLMM on SM8750.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + for (clk_idx = 0; clk_idx < num_clk_refs; clk_idx++) {
> > + clk_ref = &clk_refs[clk_idx];
> > + desc = &descs[clk_idx];
> > +
> > + if (!desc->name)
> > + continue;
>
> Carrying over from the previous discussion:
>
> > // this allows "holes" in dt-bindings for $reasons
> > if (!desc)
> > continue;
> >
> > // this makes sure the programmer did not omit something important
> > // while not taking the entire system down
> > if (WARN_ON(!desc->name)
> > continue;
> >
> The NULL name check is intentional - the descriptor array is indexed by
> clock ID, and mahua has fewer clocks than glymur, leaving holes at
> certain indices. So this is expected at runtime. WARN_ON would be noise
> log here.
>
>
> ->
>
> Your worry is captured by nullchecking `desc` (i.e. descs[clk_idx])
>
> because in the mahua case we've got (ephemeral indices)
>
> tcsr_cc_mahua_clk_descs[] = {
> [0] = { foo },
> // [1] is unassigned - OK
> [2] = { bar },
> };
>
> while (!desc->name) checks for:
>
> tcsr_cc_mahua_clk_descs[] = {
> [0] = { .name = "foo", .offset = 0x10 },
> // name is NULL by virtue of partial struct initialization
> [1] = { .offset = 0x20 },
> };
>
> however I overlooked that we actually just have a normal array of
> structs.. if we turn it into a struct pointer array with assigmnents
> like:
>
> [TCSR_EDP_CLKREF_EN] = &(const struct qcom_clk_ref_desc) {
> .name = "foo",
> ...
> };
>
> we can achieve that
Okay, I got you. I'll switch to a pointer array in v7 so that we can check
!desc and !desc->name for different purpose.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: sashiko-bot @ 2026-06-22 12:32 UTC (permalink / raw)
To: Flaviu Nistor; +Cc: robh, conor+dt, devicetree, linux-hwmon
In-Reply-To: <20260622122200.14245-1-flaviu.nistor@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The 'label' property description incorrectly refers to 'this channel', but the property is applied to the top-level device node.
Pre-existing issues:
- [High] Threaded interrupt handlers modify shared state without holding any locks, violating hwmon subsystem guidelines and causing potential loss of alarm events.
--
commit 6b42d122bc193119c40ff5ee9be18fcec09fc567
Author: Flaviu Nistor <flaviu.nistor@gmail.com>
dt-bindings: hwmon: chipcap2: Add label property
Add support for an optional label property similar to other hwmon devices.
This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
distinct names to each instance.
> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> index 17351fdbefce6..f00b5a4b14ddd 100644
> --- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> @@ -33,6 +33,10 @@ properties:
> reg:
> maxItems: 1
>
> + label:
> + description:
> + A descriptive name for this channel, like "ambient" or "psu".
[Severity: Low]
Is this description accurate? The label property is being added to the
root node, so it applies to the entire device/instance rather than a single
channel.
The chipcap2 sensor provides multiple channels via a single device
node. Could the description be updated to clarify it names the entire sensor
rather than a single channel?
> +
> interrupts:
> items:
> - description: measurement ready indicator
[Severity: High]
This is a pre-existing issue, but does drivers/hwmon/chipcap2.c lack
locking between the threaded interrupt handlers and the sysfs paths, which
could lead to lost alarm events?
The threaded interrupt handlers modify shared state without holding any
locks, which violates hwmon subsystem guidelines.
If an interrupt fires between the sysfs read and write:
CPU1 in drivers/hwmon/chipcap2.c:cc2_humidity_min_alarm_status() {
...
if (data->rh_alarm.low_alarm) {
*val = (measurement < min_hyst) ? 1 : 0;
CPU2 in drivers/hwmon/chipcap2.c:cc2_low_interrupt() {
cc2->rh_alarm.low_alarm = true;
}
CPU1 continues:
data->rh_alarm.low_alarm = *val;
} else {
*val = 0;
}
...
}
The interrupt's update will be overwritten with 0 and permanently lost. The
hwmon subsystem guidelines require drivers to implement locking for interrupt
handling and sysfs attributes, recommending the use of hwmon_lock() and
hwmon_unlock().
Could this concurrent access to data->rh_alarm.low_alarm be protected?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622122200.14245-1-flaviu.nistor@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/2] hwmon: (chipcap2) Add support for label
From: sashiko-bot @ 2026-06-22 12:30 UTC (permalink / raw)
To: Flaviu Nistor; +Cc: linux-hwmon, robh, conor+dt, devicetree
In-Reply-To: <20260622122200.14245-2-flaviu.nistor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Data race on shared state between threaded interrupt handlers and sysfs context, violating hwmon subsystem guidelines.
--
commit a4752e881c74f908f48e460d6cd5322c3eb88341
Author: Flaviu Nistor <flaviu.nistor@gmail.com>
hwmon: (chipcap2) Add support for label
This commit adds support for the label sysfs attribute to the chipcap2 hwmon
device. This allows for easier identification of individual sensors via the
device tree.
> diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
> index 4aecf463180fd..086571d556b7e 100644
> --- a/drivers/hwmon/chipcap2.c
> +++ b/drivers/hwmon/chipcap2.c
[ ... ]
> @@ -552,6 +559,16 @@ static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
> return 0;
> }
>
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this driver I
noticed a potential data race. Does the driver access and modify shared
variables (rh_alarm.low_alarm) concurrently from both sysfs read paths and
threaded interrupt handlers without locking?
In the sysfs process context, the flag is evaluated and cleared without locks:
drivers/hwmon/chipcap2.c:cc2_humidity_min_alarm_status() {
...
if (data->rh_alarm.low_alarm) {
*val = (measurement < min_hyst) ? 1 : 0;
data->rh_alarm.low_alarm = *val;
} else {
*val = 0;
}
...
}
Concurrently, the threaded interrupt handler sets the flag:
drivers/hwmon/chipcap2.c:cc2_low_interrupt() {
...
if (cc2->process_irqs) {
hwmon_notify_event(cc2->hwmon, hwmon_humidity,
hwmon_humidity_min_alarm, CC2_CHAN_HUMIDITY);
cc2->rh_alarm.low_alarm = true;
}
...
}
The hwmon subsystem guidelines mandate that drivers must implement locking
required for interrupt handling, specifically recommending the use of
hwmon_lock() and hwmon_unlock() to serialize operations. Can these paths
race and cause state corruption or lost alarm events?
> +static int cc2_read_string(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, const char **str)
> +{
> + struct cc2_data *data = dev_get_drvdata(dev);
> +
> + *str = data->label;
> +
> + return 0;
> +}
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622122200.14245-1-flaviu.nistor@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: limits: Describe Qualcomm SPEL hardware
From: Krzysztof Kozlowski @ 2026-06-22 12:28 UTC (permalink / raw)
To: Manaf Meethalavalappu Pallikunhi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio, Daniel Lezcano, Gaurav Kohli,
linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <20260620-qcom_spel_driver_upstream-v2-1-a3ee6837c18f@oss.qualcomm.com>
On Sat, Jun 20, 2026 at 02:09:08AM +0530, Manaf Meethalavalappu Pallikunhi wrote:
> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
> based power monitoring and limiting capabilities for various domains.
>
> Add a DeviceTree binding to describe the SPEL block on Qualcomm's SoC.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
> ---
> .../bindings/power/limits/qcom,spel.yaml | 47 ++++++++++++++++++++++
> MAINTAINERS | 6 +++
> 2 files changed, 53 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
What is "limits" directory for? What sort of class of devices fit there?
> new file mode 100644
> index 000000000000..4c6e6cbfbfe4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
Filename should match the compatible, so qcom,glymur-spel.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/limits/qcom,spel.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SoC Power and Electrical Limits (SPEL)
> +
> +maintainers:
> + - Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
> +
> +description:
> + The Qualcomm SPEL (SoC Power and Electrical Limits) provides hardware-based
> + power monitoring and limiting capabilities for various power domains in
> + Qualcomm SoCs.
Please describe here more what is this limiting capabilities.
> +
> +properties:
> + compatible:
> + const: qcom,glymur-spel
> +
> + reg:
> + maxItems: 3
> +
> + reg-names:
> + items:
> + - const: config
> + - const: constraints
> + - const: nodes
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: soc: xilinx: Add MYIR MYS-7Z020-V2 board
From: Krzysztof Kozlowski @ 2026-06-22 12:25 UTC (permalink / raw)
To: Liu Yu
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-arm-kernel
In-Reply-To: <SY3PPF19552C607716AE1AA440C85D348B6C7E22@SY3PPF19552C607.AUSP300.PROD.OUTLOOK.COM>
On Fri, Jun 19, 2026 at 09:23:54PM +0800, Liu Yu wrote:
> Add compatible string for the MYIR MYS-7Z020-V2 board, based on
> the Xilinx Zynq-7000 XC7Z020 SoC.
>
> Signed-off-by: Liu Yu <f78fk@live.com>
You should not use outlook to send messages. That platform really sucks,
meaning:
1. You might not receive answer for me, because outlook/M$ treats kernel
maintainers as spam and does not care to change it,
2. outlook rewrites message ids making threading often broken.
Recommended is to use b4 relay in such case. You have been warned...
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: media: i2c: Add imx576 sensor
From: Krzysztof Kozlowski @ 2026-06-22 12:22 UTC (permalink / raw)
To: Himanshu Bhavani
Cc: sakari.ailus, luca.weiss, Hardevsinh Palaniya,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Hans Verkuil,
Hans de Goede, Vladimir Zapolskiy, Elgin Perumbilly, Xiaolei Wang,
Laurent Pinchart, Walter Werner Schneider, Kate Hsuan,
Svyatoslav Ryhel, linux-media, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <20260619125439.55311-2-himanshu.bhavani@siliconsignals.io>
On Fri, Jun 19, 2026 at 06:24:31PM +0530, Himanshu Bhavani wrote:
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + data-lanes:
> + oneOf:
> + - items:
> + - const: 1
> + - const: 2
> + - const: 3
> + - const: 4
> + - items:
> + - const: 1
> + - const: 2
> + required:
> + - data-lanes
> + - link-frequencies
You should require endpoint here.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] hwmon: (chipcap2) Add support for label
From: Flaviu Nistor @ 2026-06-22 12:22 UTC (permalink / raw)
To: Guenter Roeck, Javier Carrasco, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: Flaviu Nistor, linux-hwmon, linux-kernel, devicetree, linux-doc
In-Reply-To: <20260622122200.14245-1-flaviu.nistor@gmail.com>
Add support for label sysfs attribute similar to other hwmon devices.
This is particularly useful for systems with multiple sensors on the
same board, where identifying individual sensors is much easier since
labels can be defined via device tree.
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
---
Documentation/hwmon/chipcap2.rst | 2 ++
drivers/hwmon/chipcap2.c | 25 +++++++++++++++++++++++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/hwmon/chipcap2.rst b/Documentation/hwmon/chipcap2.rst
index dc165becc64c..c38d87b91b69 100644
--- a/Documentation/hwmon/chipcap2.rst
+++ b/Documentation/hwmon/chipcap2.rst
@@ -70,4 +70,6 @@ humidity1_min_hyst: RW humidity low hystersis
humidity1_max_hyst: RW humidity high hystersis
humidity1_min_alarm: RO humidity low alarm indicator
humidity1_max_alarm: RO humidity high alarm indicator
+humidity1_label: RO descriptive name for the sensor
+temp1_label: RO descriptive name for the sensor
=============================== ======= ========================================
diff --git a/drivers/hwmon/chipcap2.c b/drivers/hwmon/chipcap2.c
index 4aecf463180f..086571d556b7 100644
--- a/drivers/hwmon/chipcap2.c
+++ b/drivers/hwmon/chipcap2.c
@@ -22,6 +22,8 @@
#include <linux/irq.h>
#include <linux/module.h>
#include <linux/regulator/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/property.h>
#define CC2_START_CM 0xA0
#define CC2_START_NOM 0x80
@@ -83,6 +85,7 @@ struct cc2_data {
struct i2c_client *client;
struct regulator *regulator;
const char *name;
+ const char *label;
int irq_ready;
int irq_low;
int irq_high;
@@ -449,6 +452,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
switch (attr) {
case hwmon_humidity_input:
return 0444;
+ case hwmon_humidity_label:
+ return cc2->label ? 0444 : 0;
case hwmon_humidity_min_alarm:
return cc2->rh_alarm.low_alarm_visible ? 0444 : 0;
case hwmon_humidity_max_alarm:
@@ -466,6 +471,8 @@ static umode_t cc2_is_visible(const void *data, enum hwmon_sensor_types type,
switch (attr) {
case hwmon_temp_input:
return 0444;
+ case hwmon_temp_label:
+ return cc2->label ? 0444 : 0;
default:
return 0;
}
@@ -552,6 +559,16 @@ static int cc2_humidity_max_alarm_status(struct cc2_data *data, long *val)
return 0;
}
+static int cc2_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ struct cc2_data *data = dev_get_drvdata(dev);
+
+ *str = data->label;
+
+ return 0;
+}
+
static int cc2_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
@@ -670,8 +687,9 @@ static int cc2_request_alarm_irqs(struct cc2_data *data, struct device *dev)
}
static const struct hwmon_channel_info *cc2_info[] = {
- HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT),
- HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_MIN | HWMON_H_MAX |
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(humidity, HWMON_H_INPUT | HWMON_H_LABEL |
+ HWMON_H_MIN | HWMON_H_MAX |
HWMON_H_MIN_HYST | HWMON_H_MAX_HYST |
HWMON_H_MIN_ALARM | HWMON_H_MAX_ALARM),
NULL
@@ -680,6 +698,7 @@ static const struct hwmon_channel_info *cc2_info[] = {
static const struct hwmon_ops cc2_hwmon_ops = {
.is_visible = cc2_is_visible,
.read = cc2_read,
+ .read_string = cc2_read_string,
.write = cc2_write,
};
@@ -710,6 +729,8 @@ static int cc2_probe(struct i2c_client *client)
return dev_err_probe(dev, PTR_ERR(data->regulator),
"Failed to get regulator\n");
+ device_property_read_string(dev, "label", &data->label);
+
ret = cc2_request_ready_irq(data, dev);
if (ret)
return dev_err_probe(dev, ret, "Failed to request ready irq\n");
--
2.34.1
^ permalink raw reply related
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