* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-13 10:46 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, smangipudi, wsa+renesas, treding, jonathanh
In-Reply-To: <3d199d1c-066f-4947-8956-c135fb9ba24e@kernel.org>
On Mon, 13 Apr 2026 09:12:18 +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 08:57, Akhil R wrote:
>>>> Isn't I3C needed for SPD5118. Otherwise I understand even less from this
>>>> rationale - why I3C is being enabled here?
>>>>
>>>> And before author asks what do I want to here: no, it is author's job to
>>>> convince me to accept I3C in defconfig. Not mine.
>>>
>>> BTW, all this was asked at v1 and author did not improve the commit msg
>>> beside giving quite broad/unspecific "Vera".
>>
>> If I am not wrong, the ask in v1 was to specify the product which this is
>> getting used - 'Vera' it is. I do not know why you would think it is
>> unspecific.
>
> I already said why. Because I Googled it and Google told me it can be
> "architecture". And no, you do not use SPD5118 on architecture.
Vera is the CPU and it uses SOCAMM LPDDR5, which has an SPD5118 within.
I will write this down in the next version.
>
>>
>> As Thierry and Guenter mentioned, the lack of policy and 'mix of both' in
>> the defconfig makes it quite difficult to understand what could genuinely
>> be convincing other than putting down every little detail or do a trial
>> and error.
>
> I think the main problem is that people forgot that commits must answer
> WHY you are doing this. Now my assumption is that people sending
> defconfigs do not understand why they are doing it, therefore they
> cannot explain "why" in commit msg.
>
> Look, find me in following nvidia patches any answers to why this change
> is needed:
>
> https://lore.kernel.org/all/20260409131340.168556-7-pshete@nvidia.com/
> https://lore.kernel.org/all/20240829134252.49661-1-jonathanh@nvidia.com/
> https://lore.kernel.org/all/20240509215808.126217-1-bwicaksono@nvidia.com/
>
> I understand that I can clarify what sort of answers to "why?" I expect.
> but lack of such clarification is not excuse to not provide ANY
> explanation in commit msg.
>
> Basically it is logic like:
> "Uh, I don't how to explain this change, why do we need it, why is it
> good, why am I doing that...anyway, let's send it!"
>
> Why doing something in the first place if one does not know the reason
> behind?
The answer I wrote to "why" is that "it is required to support the
SOCAMM in Vera". But I may have overlooked the ambiguity of the
details of Vera available online. I will make it more descriptive.
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-13 10:39 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260412-abiding-silver-turkey-1623cc@quoll>
Hello Krzysztof, thank you for this feedback.
On 4/12/26 11:58 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 10, 2026 at 06:48:02PM +0200, Ronald Claveau wrote:
>> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>>
>> Unlike existing variants which use a phandle to the ao-secure syscon,
>> the T7 relies on a secure monitor interface described by a phandle and
>> a sensor index argument.
>>
>> Introduce the amlogic,secure-monitor property as a phandle-array and
>> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
>> depending on the compatible.
>>
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> ---
>> .../bindings/thermal/amlogic,thermal.yaml | 40 +++++++++++++++++++++-
>> 1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> index 70b273271754b..85ee73c6e1161 100644
>> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
>> @@ -22,6 +22,7 @@ properties:
>> - amlogic,g12a-ddr-thermal
>> - const: amlogic,g12a-thermal
>> - const: amlogic,a1-cpu-thermal
>> + - const: amlogic,t7-thermal
>
> So these two entries are enum.
>
I will change to enum.
>>
>> reg:
>> maxItems: 1
>> @@ -42,12 +43,40 @@ properties:
>> '#thermal-sensor-cells':
>> const: 0
>>
>> + amlogic,secure-monitor:
>> + description: phandle to the secure monitor
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - items:
>> + - description: phandle to the secure monitor
>> + - description: sensor index
>
> For what exactly this sensor index is needed? commit msg explained me
> nothing, instead repeated what you did. That's pointless, explain why
> you did it.
>
Thanks I will add the explanation in the commit message and in the
description here.
>> +
>> required:
>> - compatible
>> - reg
>> - interrupts
>> - clocks
>> - - amlogic,ao-secure
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - amlogic,g12a-cpu-thermal
>> + - amlogic,g12a-ddr-thermal
>
> Drop both, you need only fallback.
>
I hesitated between the two methods. I will change to fallback only.
>> + - amlogic,a1-cpu-thermal
>
> And list is sorted alphabetically.
>
Thanks for the reminder.
>> + then:
>> + required:
>> + - amlogic,ao-secure
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau @ 2026-04-13 10:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
In-Reply-To: <6200b372-149f-48f7-ae91-a5364562058c@kernel.org>
On 4/12/26 12:47 PM, Krzysztof Kozlowski wrote:
> On 10/04/2026 18:48, Ronald Claveau wrote:
>> @@ -245,6 +246,14 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
>> }
>> EXPORT_SYMBOL_GPL(meson_sm_get);
>>
>> +int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
>
> Exported functions should have kerneldoc.
>
Thanks for your feedback, I will add it.
>> + u32 tsensor_id)
>> +{
>> + return meson_sm_call(fw, SM_THERMAL_CALIB_READ, trim_info, tsensor_id,
>> + 0, 0, 0, 0);
>
> Best regards,
> Krzysztof
--
Best regards,
Ronald
^ permalink raw reply
* Re: Phandles
From: Herve Codina @ 2026-04-13 10:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Kyle Bonnici, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <72dc4a71-1a3d-4e36-9bcc-d9a4de3de6cc@kernel.org>
Hi Krzysztof
On Mon, 13 Apr 2026 08:33:49 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 12/04/2026 17:40, Herve Codina wrote:
> > Hi Kyle,
> >
> > +Cc Kernel device-tree maintainers
> >
> > On Sun, 12 Apr 2026 13:51:35 +0000
> > Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >
> >>> On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
> >>>
> >>> Hi Kyle,
> >>>
> >>> On Sat, 11 Apr 2026 18:33:33 +0000
> >>> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
> >>>>
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
> >>>> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");
> >>>
> >>> All of those properties are defined as phandles.
> >>>
> >>> For instance, the 'pwms' property available in a node means the the node is
> >>> a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
> >>> is involved.
> >>>
> >>> This phandle can have arguments and the number of argument is defined by the
> >>> #pwm-cells property set in the pwm provider node [2], [3].
> >>>
> >>> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
> >>> [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
> >>> [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
> >>>
> >>>>
> >>>>
> >>>> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066
> >>>
> >>> Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
> >>>
> >>> Case 1:
> >>> / {
> >>> node1 {
> >>> pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
> >>>
> >>> Here the first cell '1' is not a phandle.
> >>
> >> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
> >
> > I think the purpose of 'select: true' is to have the binding always applied:
> > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
> >
> > If this is confirmed, DTC performs correct checks as this binding must always
> > be applied and so the 'pwms' property must be a phandle-array property.
> >
> > Device-tree maintainers, can you confirm the purpose of 'select: true' set
> > in a DT binding ?
>
> The quoted parts were mentioning Zephyr. Here you mentioned DTC, but ask
> about "select: true", so dtschema. I don't get the context... dtschema
> has nothing to do with DTC and Zephyr.
I wanted be sure about checks done by DTC itself.
My feeling was that if a binding defined in dtschema has to be always applied
(i.e. select: true) it is a legit case to have DTC performing some checks
according to this binding.
Kyle seems to define the 'pwms' property to be something other than a phandle.
IMHO, this is wrong but the 'pwms' property is only defined in dtschema.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset
From: Konrad Dybcio @ 2026-04-13 10:28 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: David Heidelberg, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Ulf Hansson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <cm7cowdic42qziuwpe22b2yuakg2k5lqcdnfs3mspvbvprnbto@6kxucxrbnsc6>
On 4/12/26 2:41 AM, Dmitry Baryshkov wrote:
> On Fri, Apr 10, 2026 at 10:55:53AM +0200, Konrad Dybcio wrote:
>> On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
>>> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>>>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>>>
>>>>>>
>>>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>> From: David Heidelberg <david@ixit.cz>
>>>>>>>>>>>
>>>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>>>
>>>>>>>>>> This is not the relevant reset
>>>>>>>>>>
>>>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>>>
>>>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>>>
>>>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
>>>>>>>>
>>>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>>>> place
>>>>>>>
>>>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>>>
>>>>>> Back when I replied, David had a patch that removed the current RSCC
>>>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>>>> specific commits when making comments, note to self :P
>>>>>
>>>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>>>> work.
>>>>
>>>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>>>
>>>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>>>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>>>> arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0xc88
>>>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
>>>
>>> [...]
>>>
>>>>
>>>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>>>> linux-next kernels for some time, but pretty harmless.
>>>>
>>>> LLM suggested multiple fixes, but when presenting possibility of
>>>> implementing mdss reset it found it as most preferable [1].
>>>>
>>>> Adding MDSS reset would most likely solve it. It's not critical, but not
>>>> nice to see many red lines in the dmesg.
>>>>
>>>> Is there something I could experiment with to get closer to have proper MDSS reset?
>>>
>>> I don't have a sensible solution at this point. We tried using the MDSS
>>> reset on several SDM845 devices, but they just reset. So... I don't have
>>> any possible solution.
>>
>> The older context talks about altering the existing dt-bindings values
>> and now we're at hardware (mis)behaving? What is the issue here?
>
> The HDK and DB845c reset if I try touching MDSS core reset.
And David, does that also happen on your other boards?
Konrad
^ permalink raw reply
* Re: [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Konrad Dybcio @ 2026-04-13 10:28 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <63630053AE2A689C+fc86c1c4-8daa-4af8-bf64-b432fc8dc1c0@radxa.com>
On 4/12/26 5:14 AM, Xilin Wu wrote:
> On 4/8/2026 5:03 PM, Konrad Dybcio wrote:
>> On 4/7/26 5:19 PM, Xilin Wu wrote:
>>> This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
>>
>> I guess the receptacle on board is power-only?
>
> Yes. The Type-C port is power only.
[...]
>>> +&mdss_dp {
>>> + sound-name-prefix = "Display Port0";
>>
>> Hmmmmm.. other platforms call it "DisplayPort0" (without a space)..
>> But I suppose this name needs to match UCM..
>>
>> We'd also normally push this property to the SoC DTSI
>
> Actually I don't think the name is used in UCM. I can rename it and push the property to SoC DTSI if necessary.
Let's do that
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: usb: qcom,dwc3: Correct MSM8994 interrupts
From: Konrad Dybcio @ 2026-04-13 10:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng, Krishna Kurapati,
Bjorn Andersson, linux-arm-msm, linux-usb, devicetree,
linux-kernel, Dmitry Baryshkov
In-Reply-To: <20260106185012.19551-4-krzysztof.kozlowski@oss.qualcomm.com>
On 1/6/26 7:50 PM, Krzysztof Kozlowski wrote:
> According to the reference manual, MSM8994 does have QUSB2 PHY and does
> not have DP/DM IRQs interrupts. It is also logical it has the same
> constraints as similar device: MSM8996.
It may be that the following mapping is true:
USB0 (DWC3)
DP -> MPM 49
DM -> MPM 58
hsphy -> GIC 133
otg (dwc3_irq?) -> 179
power_event -> 180
ee1 -> GIC 131
ee2 -> GIC 246 (for IPA?)
hs_phy_qgic_irq (qusb2?) -> GIC 311
phy_id -> MPM 48
USB1 (CHIPIDEA)
DP -> MPM 55
DM -> MPM 54
hsphy -> GIC 134
async wakeup -> GIC 140
qusb2_phy -> GIC 312
Do with that what you will.. I can add looking into this more properly
to my ever-growing TODO list (or maybe +Dmitry has a 8994 SBC?)
Konrad
^ permalink raw reply
* Re: [PATCH v2 0/4] Add QST QMC5883P magnetometer driver
From: Andy Shevchenko @ 2026-04-13 10:21 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <DHR3SE5ACRQ9.2T8T819298YGI@pm.me>
On Sun, Apr 12, 2026 at 10:27:36AM +0000, Hardik Phalet wrote:
> On Fri Apr 10, 2026 at 10:06 AM IST, Andy Shevchenko wrote:
> > On Thu, Apr 09, 2026 at 09:07:11PM +0000, Hardik Phalet wrote:
...
> > - the investigation is rather poor about existence of the driver — make sure
> > there is no compatible (by register layout) driver in IIO or even outside it
> > (for ADCs it might appear as HWMON [drivers/hwmon] or INPUT [drivers/input]
> > in some cases)
> I will dig a bit deeper into this. But I could not find any thing
> realted to the device I am working on (qmc5883p).
It might be that there is a driver with smaller amount of registers available
(or bigger) or some features missing...
> There is a device hmc5843_core.c that already handles HMC5883L. But the
> register layout is different, field ranges, gain encoding etc. are
> different and I think warrants a separate driver. Other than that I
> could not find something related to device I am working on.
This paragraph is a particular case, something like this should be put in the
summary in your case if the brand new driver is needed.
> I will carefully go through HWMON and INPUT too, but do you have a
> strategy to help me find somehting similar? It will be very useful.
> Would `grep`-ing for 5883 and QST be a right starting point?
Grep for words that are case insensitive values of the registers offsets.
This can be done recursively, then you need to apply some heuristics on
the definition names to see if they are about the same thing (or similar)
or not at all.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: phucduc.bui @ 2026-04-13 10:07 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
The FSI on r8a7740 requires the SPU bus/bridge clock to be enabled before
accessing its registers. Without this clock, any register access leads to
a system hang as the FSI block sits behind the SPU bus.
Update the binding to support a flexible positional clock list to properly
describe the hardware clock tree, including:
- SPU bus/bridge clock (spu) for register access.
- CPG DIV6 clocks (icka/b) as functional clock parents.
- FSI internal dividers (diva/b) for audio clock generation.
- External clock inputs (xcka/b) provided by the board.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Rename FSI module clock to "own" to match driver.
- Add "spu", "icka/b", "diva/b", "xcka/b" clock names.
- Use YAML anchors to constrain clock-names properly.
- Add "if" rule to require "spu" clock for r8a7740.
- Update example with full clock configuration.
- Clean up schema by moving allOf location.
.../bindings/sound/renesas,fsi.yaml | 61 +++++++++++++++++--
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
index df91991699a7..d0ae54f3d321 100644
--- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
+++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
@@ -9,9 +9,6 @@ title: Renesas FIFO-buffered Serial Interface (FSI)
maintainers:
- Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
-allOf:
- - $ref: dai-common.yaml#
-
properties:
$nodename:
pattern: "^sound@.*"
@@ -38,7 +35,36 @@ properties:
maxItems: 1
clocks:
- maxItems: 1
+ description: |
+ Clock driving the FSI Controller. The first clock must be
+ the module clock ("own").
+ minItems: 1
+ maxItems: 8
+
+ clock-names:
+ description: |
+ Names of clocks corresponding to entries in "clocks":
+ - "own": Main FSI module clock (must be first and always present)
+ - "spu": SPU bus/bridge clock. On R8A7740, this clock must be
+ enabled to allow register access as the FSI block is connected
+ behind the SPU bus.
+ - "icka" / "ickb": CPG DIV6 functional clocks for FSI port A/B
+ - "diva"/"divb": Internal FSI dividers for port A/B used for
+ audio clock generation
+ - "xcka"/"xckb": External clock inputs for FSI port A/B
+ provided by the board
+ minItems: 1
+ items:
+ - const: own
+ - &fsi_all_clks
+ enum: [spu, icka, ickb, diva, divb, xcka, xckb]
+ - &fsi_no_spu_clks
+ enum: [icka, ickb, diva, divb, xcka, xckb]
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
power-domains:
maxItems: 1
@@ -69,6 +95,27 @@ required:
unevaluatedProperties: false
+allOf:
+ - $ref: dai-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,fsi2-r8a7740
+ then:
+ properties:
+ clock-names:
+ minItems: 2
+ items:
+ - const: own
+ - const: spu
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+ - *fsi_no_spu_clks
+
examples:
- |
#include <dt-bindings/clock/r8a7740-clock.h>
@@ -77,7 +124,11 @@ examples:
compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
reg = <0xfe1f0000 0x400>;
interrupts = <GIC_SPI 9 0x4>;
- clocks = <&mstp3_clks R8A7740_CLK_FSI>;
+ clocks = <&mstp3_clks R8A7740_CLK_FSI>, <&spu_clk>,
+ <&fsia_clk>, <&fsib_clk>, <&fsidiva_clk>,
+ <&fsidivb_clk>,<&fsiack_clk>,<&fsibck_clk>;
+ clock-names = "own", "spu", "icka", "ickb",
+ "diva", "divb", "xcka", "xckb";
power-domains = <&pd_a4mp>;
#sound-dai-cells = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/6] arm: dts: renesas: r8a7740: Add clocks for FSI
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Add the SPU clock to the FSI node to ensure it is enabled before register
access, preventing potential system hangs.
Also complete the FSI clock tree by adding:
- CPG DIV6 clocks (icka/b) as functional parents
- External clocks (xcka/b) from the board
Define fsib nodes to support the clock hierarchy.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Rename "fsi" clock to "own" to match driver implementation.
- Add missing clock names: "icka", "ickb", "xcka", "xckb".
arch/arm/boot/dts/renesas/r8a7740.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7740.dtsi b/arch/arm/boot/dts/renesas/r8a7740.dtsi
index d13ab86c3ab4..b8d903b711be 100644
--- a/arch/arm/boot/dts/renesas/r8a7740.dtsi
+++ b/arch/arm/boot/dts/renesas/r8a7740.dtsi
@@ -393,7 +393,11 @@ sh_fsi2: sound@fe1f0000 {
compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
reg = <0xfe1f0000 0x400>;
interrupts = <GIC_SPI 9 0x4>;
- clocks = <&mstp3_clks R8A7740_CLK_FSI>;
+ clocks = <&mstp3_clks R8A7740_CLK_FSI>, <&spu_clk>,
+ <&fsia_clk>, <&fsib_clk>, <&fsiack_clk>,
+ <&fsibck_clk>;
+ clock-names = "own", "spu", "icka", "ickb", "xcka",
+ "xckb";
power-domains = <&pd_a4mp>;
status = "disabled";
};
@@ -614,6 +618,12 @@ vou_clk: vou@e6150088 {
<0>;
#clock-cells = <0>;
};
+ fsib_clk: fsib@e6150090 {
+ compatible = "renesas,r8a7740-div6-clock", "renesas,cpg-div6-clock";
+ reg = <0xe6150090 4>;
+ clocks = <&pllc1_div2_clk>, <&fsibck_clk>, <0>, <0>;
+ #clock-cells = <0>;
+ };
stpro_clk: stpro@e615009c {
compatible = "renesas,r8a7740-div6-clock", "renesas,cpg-div6-clock";
reg = <0xe615009c 4>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/6] ASoC: renesas: fsi: refactor clock initialization
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Move fsi_clk_init() out of set_fmt() and handle clock master logic
internally. This simplifies the flow and aligns with probe-time
initialization.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Note: Due to hardware limitations, only slave mode has been verified.
Testing master mode requires resoldering board resistors or
developing an HDMI driver, so master mode logic is currently
compile-tested only. Full support for fsidiv requires additional
DT bindings and a corresponding driver.
sound/soc/renesas/fsi.c | 157 +++++++++++++++++++++-------------------
1 file changed, 81 insertions(+), 76 deletions(-)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 9df3e91ac79c..db4ddc30f44f 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -709,73 +709,6 @@ static void fsi_spdif_clk_ctrl(struct fsi_priv *fsi, int enable)
fsi_core_mask_set(master, b_mclk, mask, val);
}
-/*
- * clock function
- */
-static int fsi_clk_init(struct device *dev,
- struct fsi_priv *fsi,
- int xck,
- int ick,
- int div,
- int (*set_rate)(struct device *dev,
- struct fsi_priv *fsi))
-{
- struct fsi_clk *clock = &fsi->clock;
- int is_porta = fsi_is_port_a(fsi);
-
- clock->xck = NULL;
- clock->ick = NULL;
- clock->div = NULL;
- clock->rate = 0;
- clock->count = 0;
- clock->set_rate = set_rate;
-
- clock->own = devm_clk_get(dev, NULL);
- if (IS_ERR(clock->own))
- return -EINVAL;
-
- /* external clock */
- if (xck) {
- clock->xck = devm_clk_get(dev, is_porta ? "xcka" : "xckb");
- if (IS_ERR(clock->xck)) {
- dev_err(dev, "can't get xck clock\n");
- return -EINVAL;
- }
- if (clock->xck == clock->own) {
- dev_err(dev, "cpu doesn't support xck clock\n");
- return -EINVAL;
- }
- }
-
- /* FSIACLK/FSIBCLK */
- if (ick) {
- clock->ick = devm_clk_get(dev, is_porta ? "icka" : "ickb");
- if (IS_ERR(clock->ick)) {
- dev_err(dev, "can't get ick clock\n");
- return -EINVAL;
- }
- if (clock->ick == clock->own) {
- dev_err(dev, "cpu doesn't support ick clock\n");
- return -EINVAL;
- }
- }
-
- /* FSI-DIV */
- if (div) {
- clock->div = devm_clk_get(dev, is_porta ? "diva" : "divb");
- if (IS_ERR(clock->div)) {
- dev_err(dev, "can't get div clock\n");
- return -EINVAL;
- }
- if (clock->div == clock->own) {
- dev_err(dev, "cpu doesn't support div clock\n");
- return -EINVAL;
- }
- }
-
- return 0;
-}
-
#define fsi_clk_invalid(fsi) fsi_clk_valid(fsi, 0)
static void fsi_clk_valid(struct fsi_priv *fsi, unsigned long rate)
{
@@ -921,6 +854,10 @@ static int fsi_clk_set_rate_external(struct device *dev,
int ackmd, bpfmd;
int ret = 0;
+ if (!xck || !ick) {
+ dev_err(dev, "External (xck) or Internal (ick) clock is missing\n");
+ return -EINVAL;
+ }
/* check clock rate */
xrate = clk_get_rate(xck);
if (xrate % rate) {
@@ -957,6 +894,11 @@ static int fsi_clk_set_rate_cpg(struct device *dev,
int ackmd, bpfmd;
int ret = -EINVAL;
+ if (!ick || !div) {
+ dev_err(dev, "Internal (ick) or Divider (div) clock is missing\n");
+ return -EINVAL;
+ }
+
if (!(12288000 % rate))
target = 12288000;
if (!(11289600 % rate))
@@ -1029,6 +971,76 @@ static int fsi_clk_set_rate_cpg(struct device *dev,
return ret;
}
+/*
+ * clock function
+ */
+static int fsi_clk_init(struct device *dev, struct fsi_priv *fsi, int is_cpg)
+{
+ struct fsi_clk *clock = &fsi->clock;
+ struct fsi_master *master = fsi->master;
+ int is_porta = fsi_is_port_a(fsi);
+ int xck, ick, div;
+
+ if (is_cpg) {
+ xck = 0; ick = 1; div = 1;
+ clock->set_rate = fsi_clk_set_rate_cpg;
+ } else {
+ xck = 1; ick = 1; div = 0;
+ clock->set_rate = fsi_clk_set_rate_external;
+ }
+
+ clock->xck = NULL;
+ clock->ick = NULL;
+ clock->div = NULL;
+ clock->rate = 0;
+ clock->count = 0;
+
+ clock->own = devm_clk_get(dev, NULL);
+ if (IS_ERR(clock->own))
+ return -EINVAL;
+
+ if (!master->clk_spu) {
+ master->clk_spu = devm_clk_get_optional(dev, "spu");
+ if (IS_ERR(master->clk_spu))
+ return PTR_ERR(master->clk_spu);
+ }
+
+ /* external clock */
+ if (xck) {
+ clock->xck = devm_clk_get_optional(dev, is_porta ? "xcka" : "xckb");
+ if (IS_ERR(clock->xck))
+ return dev_err_probe(dev, PTR_ERR(clock->xck), "Can't get xck clock\n");
+ if (clock->xck == clock->own) {
+ dev_err(dev, "cpu doesn't support xck clock\n");
+ return -EINVAL;
+ }
+ }
+
+ /* FSIACLK/FSIBCLK */
+ if (ick) {
+ clock->ick = devm_clk_get_optional(dev, is_porta ? "icka" : "ickb");
+ if (IS_ERR(clock->ick))
+ return dev_err_probe(dev, PTR_ERR(clock->ick), "Can't get ick clock\n");
+ if (clock->ick == clock->own) {
+ dev_err(dev, "cpu doesn't support ick clock\n");
+ return -EINVAL;
+ }
+ }
+
+ /* FSI-DIV */
+ if (div) {
+ clock->div = devm_clk_get_optional(dev, is_porta ? "diva" : "divb");
+ if (IS_ERR(clock->div))
+ return dev_err_probe(dev, PTR_ERR(clock->div), "Can't get div clock\n");
+ if (clock->div == clock->own) {
+ dev_err(dev, "cpu doesn't support div clock\n");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static void fsi_pointer_update(struct fsi_stream *io, int size)
{
io->buff_sample_pos += size;
@@ -1684,15 +1696,6 @@ static int fsi_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
break;
}
- if (fsi_is_clk_master(fsi)) {
- if (fsi->clk_cpg)
- fsi_clk_init(dai->dev, fsi, 0, 1, 1,
- fsi_clk_set_rate_cpg);
- else
- fsi_clk_init(dai->dev, fsi, 1, 1, 0,
- fsi_clk_set_rate_external);
- }
-
/* set format */
if (fsi_is_spdif(fsi))
ret = fsi_set_fmt_spdif(fsi);
@@ -1992,6 +1995,7 @@ static int fsi_probe(struct platform_device *pdev)
fsi->master = master;
fsi_port_info_init(fsi, &info.port_a);
fsi_handler_init(fsi, &info.port_a);
+ fsi_clk_init(&pdev->dev, fsi, !!(info.port_a.flags & SH_FSI_CLK_CPG));
ret = fsi_stream_probe(fsi, &pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "FSIA stream probe failed\n");
@@ -2005,6 +2009,7 @@ static int fsi_probe(struct platform_device *pdev)
fsi->master = master;
fsi_port_info_init(fsi, &info.port_b);
fsi_handler_init(fsi, &info.port_b);
+ fsi_clk_init(&pdev->dev, fsi, !!(info.port_b.flags & SH_FSI_CLK_CPG));
ret = fsi_stream_probe(fsi, &pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "FSIB stream probe failed\n");
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/6] ASoC: renesas: fsi: Fix trigger stop ordering
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Reorder calls to execute fsi_stream_stop() before fsi_hw_shutdown().
This ensures that all register accesses are completed before the clock is
disabled, preventing the system hang observed on r8a7740.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/renesas/fsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 109e06b5f32d..9df3e91ac79c 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -1606,9 +1606,9 @@ static int fsi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
ret = fsi_stream_transfer(io);
break;
case SNDRV_PCM_TRIGGER_STOP:
+ fsi_stream_stop(fsi, io);
if (!ret)
ret = fsi_hw_shutdown(fsi, dai->dev);
- fsi_stream_stop(fsi, io);
fsi_stream_quit(fsi, io);
break;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/6] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Enable/disable the shared SPU clock in hw startup/shutdown. Without this,
accessing FSI registers may hang the system.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Move SPU clock enable/disable handling from fsi_dai_startup/shutdown
to fsi_hw_startup/shutdown
sound/soc/renesas/fsi.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 196ec7bac33d..109e06b5f32d 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -1492,6 +1492,18 @@ static int fsi_hw_startup(struct fsi_priv *fsi,
struct device *dev)
{
u32 data = 0;
+ int ret = 0;
+ /* enable spu clock */
+ mutex_lock(&fsi->master->clk_lock);
+ if (fsi->master->clk_spu && fsi->master->spu_count++ == 0) {
+ ret = clk_prepare_enable(fsi->master->clk_spu);
+ if (ret < 0) {
+ fsi->master->spu_count--;
+ mutex_unlock(&fsi->master->clk_lock);
+ return ret;
+ }
+ }
+ mutex_unlock(&fsi->master->clk_lock);
/* clock setting */
if (fsi_is_clk_master(fsi))
@@ -1549,6 +1561,11 @@ static int fsi_hw_shutdown(struct fsi_priv *fsi,
/* stop master clock */
if (fsi_is_clk_master(fsi))
return fsi_clk_disable(dev, fsi);
+ /* stop spu clock */
+ mutex_lock(&fsi->master->clk_lock);
+ if (fsi->master->clk_spu && --fsi->master->spu_count == 0)
+ clk_disable_unprepare(fsi->master->clk_spu);
+ mutex_unlock(&fsi->master->clk_lock);
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/6] ASoC: renesas: fsi: Add shared SPU clock support
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
In-Reply-To: <20260413100700.30995-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Add SPU clock pointer, reference counter, and locking in fsi_master for
shared FSIA/FSIB usage, and initialize them in fsi_probe().
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Changes in v2:
- Add spu_count to track active users of the SPU clock.
- Add clk_lock mutex to prevent race conditions during SPU clock
enable/disable operations.
- Initialize spu_count and clk_lock during driver probe.
sound/soc/renesas/fsi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
index 1491c2f2cc96..196ec7bac33d 100644
--- a/sound/soc/renesas/fsi.c
+++ b/sound/soc/renesas/fsi.c
@@ -292,8 +292,11 @@ struct fsi_master {
void __iomem *base;
struct fsi_priv fsia;
struct fsi_priv fsib;
+ struct clk *clk_spu;
const struct fsi_core *core;
+ int spu_count;
spinlock_t lock;
+ struct mutex clk_lock;
};
static inline int fsi_stream_is_play(struct fsi_priv *fsi,
@@ -1961,7 +1964,9 @@ static int fsi_probe(struct platform_device *pdev)
/* master setting */
master->core = core;
+ master->spu_count = 0;
spin_lock_init(&master->lock);
+ mutex_init(&master->clk_lock);
/* FSI A setting */
fsi = &master->fsia;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/6] ASoC: renesas: fsi: Fix system hang by adding SPU clock
From: phucduc.bui @ 2026-04-13 10:06 UTC (permalink / raw)
To: kuninori.morimoto.gx, broonie
Cc: lgirdwood, robh, krzk+dt, conor+dt, geert+renesas, magnus.damm,
perex, tiwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
The FSI on r8a7740 requires the SPU clock to be enabled before accessing
its internal registers. Without this clock, register access can lead to a
system hang, even when the FSI functional clock is properly enabled.
This series adds the missing clocks and aligns their names with those
used in the driver.
Following feedback from Morimoto-san, the driver is refactored to improve
stability. Clock initialization is moved from the runtime path to the probe
function to simplify the flow and avoid redundant setups. Additionally, the
shutdown sequence is reordered to ensure the stream is properly stopped
before the hardware is shut down.
Changes in v2:
- DT Bindings:
Define "own" clock and add "spu", "icka/b", "diva/b", "xcka/b" to the
clock tree.
Use YAML anchors and "if" rules to enforce clock-names and r8a7740
requirements.
Relocate allOf block and update example with full 8-clock configuration.
- DTS:
Rename "fsi" clock to "own" to match driver implementation.
Add missing clock names: "icka", "ickb", "xcka", "xckb".
- In the driver:
Refactor clock initialization.
Reorder shutdown: stop stream before hardware shutdown.
Move SPU clock enable/disable handling to fsi_hw_startup/shutdown.
v1 links :
https://lore.kernel.org/all/20260403112655.167593-1-phucduc.bui@gmail.com/
Testing:
- Verified on r8a7740 (Armadillo-800EVA): FSI slave / Codec master mode.
- FSI master mode is currently compile-tested only. Full verification
requires a dedicated HDMI driver (FSIB) or hardware modifications
(resoldering board resistors) (FSIA).Full support for fsidiv requires
additional DT bindings and a corresponding driver.
bui duc phuc (6):
ASoC: renesas: fsi: Add shared SPU clock support
ASoC: renesas: fsi: Fix hang by enabling SPU clock
ASoC: renesas: fsi: Fix trigger stop ordering
ASoC: renesas: fsi: refactor clock initialization
arm: dts: renesas: r8a7740: Add clocks for FSI
ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
.../bindings/sound/renesas,fsi.yaml | 61 +++++-
arch/arm/boot/dts/renesas/r8a7740.dtsi | 12 +-
sound/soc/renesas/fsi.c | 181 ++++++++++--------
3 files changed, 171 insertions(+), 83 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Krzysztof Kozlowski @ 2026-04-13 10:02 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-3-shengchao.guo@oss.qualcomm.com>
On 13/04/2026 11:16, Shawn Guo wrote:
> Qualcomm Oryon 1-5 is found on Nord SoC. Add compatible for it.
>
> $ cat /proc/cpuinfo
> ...
> CPU implementer : 0x51
> CPU architecture: 8
> CPU variant : 0x5
> CPU part : 0x001
> CPU revision : 4
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
> 1 file changed, 1 insertion(+)
No. I said many times. Bindings come with the user. We don't care what
is in cpuinfo of some non-upstream board (and lack of user means it is
non-upstream currently).
Please organize your patchset correctly.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
From: Krzysztof Kozlowski @ 2026-04-13 10:01 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-2-shengchao.guo@oss.qualcomm.com>
On 13/04/2026 11:16, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
Don't reference commits which will never make to Linux kernel.
> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Well, I said that merge will be difficult but Mark was sure merge is
trivial, so here we are.
Anyway, this cannot be applied. How do you exactly see it? Which tree?
Try yourself...
> ---
> Documentation/devicetree/bindings/arm/cpus.yaml | 1 +
> 1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Konrad Dybcio @ 2026-04-13 9:58 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-3-shengchao.guo@oss.qualcomm.com>
On 4/13/26 11:16 AM, Shawn Guo wrote:
> Qualcomm Oryon 1-5 is found on Nord SoC. Add compatible for it.
>
> $ cat /proc/cpuinfo
> ...
> CPU implementer : 0x51
> CPU architecture: 8
> CPU variant : 0x5
> CPU part : 0x001
> CPU revision : 4
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: Phandles
From: Krzysztof Kozlowski @ 2026-04-13 9:57 UTC (permalink / raw)
To: Kyle Bonnici
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <DB5F7CA0-08E8-4CF5-9815-598002AF471F@hotmail.com>
On 13/04/2026 11:50, Kyle Bonnici wrote:
>
>> You cannot have random values. I quoted the DT spec.
>
> Where in the DTS 0.4 spec are property names such as pwms, clocks
> etc… mandated to be of format <phandle cell …>?
Ah, true, this is not expressed but DT spec defines types for only a few
cases.
>
>> Well, we don't use discord but IRC... but that github issue also uses
>> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>>
>> So again - what is "1"?
>>
>> I am asking because if you use incorrect value as phandle value, then
>> DTC warning is obviously expected and nothing to fix here.
>
> The warning is only valid if ‘1’ is expected to be a phandle which is what I am
> Arguing the spec does not mandate this.
The "&foo" used in the property defines that it is phandle, no?
>
>> You asked why phandle has to be the first entry in phandle-value type? I
>> responded that DT spec makes it.
>
> Which section in DTS 0.4 spec?
2.2.4.2. Property Values
"That number is used for the value of properties with a phandle value type.
The properties having phandle value must have proper, well, value :)
>
>> We discuss DTC here, yes? Whether it has or has not a bug? Please help
>> me to understand the topic. Why would we care about Zephyr's
>> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
>> am not saying that it is not important, just saying that I am not the
>> audience to discuss it.
>
> I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
> “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”,
> “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”,
> “clocks”, “sound_dai” and “thermal_sensors”
> must follow <phandle cell …>.
>
> This is only mandated by the dt-schema as far as I understand, that is a used by
> Linux, but not Zephyr and the DTC Making the assumption that this is true for
> all systems
No, dtschema is irrelevant here and DTC was validating it since 2017, so
years before dtschema.
DT spec indeed does not mandate it as pwms, but replacing that check in
DTC with something only validating phandles would not solve your
problem. Your 'pwm' is a phandle-value type, because you use phandle
there, and still is has wrong value.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: cpus: Restore qcom,oryon-1-4 compatible
From: Konrad Dybcio @ 2026-04-13 9:57 UTC (permalink / raw)
To: Shawn Guo, Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260413091625.607976-2-shengchao.guo@oss.qualcomm.com>
On 4/13/26 11:16 AM, Shawn Guo wrote:
> It seems that compatible qcom,oryon-1-4 was accidentally dropped during
> the conflict resolution in commit f6935ae6147b ("Merge branch 'for-next'
> of https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git").
> Restore it.
>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: Phandles
From: Kyle Bonnici @ 2026-04-13 9:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <c0983f3d-5025-4933-ac22-bfbc1adc6c31@kernel.org>
> You cannot have random values. I quoted the DT spec.
Where in the DTS 0.4 spec are property names such as pwms, clocks
etc… mandated to be of format <phandle cell …>?
> Well, we don't use discord but IRC... but that github issue also uses
> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>
> So again - what is "1"?
>
> I am asking because if you use incorrect value as phandle value, then
> DTC warning is obviously expected and nothing to fix here.
The warning is only valid if ‘1’ is expected to be a phandle which is what I am
Arguing the spec does not mandate this.
> You asked why phandle has to be the first entry in phandle-value type? I
> responded that DT spec makes it.
Which section in DTS 0.4 spec?
> We discuss DTC here, yes? Whether it has or has not a bug? Please help
> me to understand the topic. Why would we care about Zephyr's
> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
> am not saying that it is not important, just saying that I am not the
> audience to discuss it.
I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
“cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”,
“msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”,
“clocks”, “sound_dai” and “thermal_sensors”
must follow <phandle cell …>.
This is only mandated by the dt-schema as far as I understand, that is a used by
Linux, but not Zephyr and the DTC Making the assumption that this is true for
all systems
Regards
Kyle
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Jon Hunter @ 2026-04-13 9:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <097f71e0-cbc8-44e3-ba60-8bac79cf5217@nvidia.com>
On 10/04/2026 09:25, Jon Hunter wrote:
>
>
> On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
>> On 09/04/2026 15:13, pshete@nvidia.com wrote:
>>> From: Prathamesh Shete <pshete@nvidia.com>
>>>
>>> Building the Pinctrl driver into the kernel image increases its size.
>>
>> That's obvious.
>>
>>> These drivers are not required during early boot, build them as a
>>> loadable
>>> module instead to reduce the kernel image size.
>>
>> So you replace built-in into module?
>>>
>>> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
>>> ---
>>> arch/arm64/configs/defconfig | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>>> index dd1ac01ee29b..f525670d3b84 100644
>>> --- a/arch/arm64/configs/defconfig
>>> +++ b/arch/arm64/configs/defconfig
>>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>>> +CONFIG_PINCTRL_TEGRA238=m
>>> +CONFIG_PINCTRL_TEGRA264=m
>>
>> No, you just added as module. Why do we want them in upstream defconfig?
>>
>> Standard question, already asked Nvidia more than once.
>
> Yes :-)
>
> Prathamesh, what we need to do is ...
>
> 1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
> 2. In this patch, only enable pinctrl for Tegra264 because we are
> lacking an upstream board for Tegra238 for that moment. In the commit
> message we should add a comment to indicate with Tegra264 platform is
> using this.
Thinking about this some more, I think I would prefer that we skip the
defconfig patch and just add ...
default m if ARCH_TEGRA_238_SOC
default m if ARCH_TEGRA_264_SOC
... in the respective Kconfig files for the drivers.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v21 2/6] pwm: driver for qualcomm ipq6018 pwm block
From: Uwe Kleine-König @ 2026-04-13 9:35 UTC (permalink / raw)
To: george.moussalem
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pwm, devicetree, linux-kernel,
Devi Priya
In-Reply-To: <20260406-ipq-pwm-v21-2-6ed1e868e4c2@outlook.com>
[-- Attachment #1: Type: text/plain, Size: 5061 bytes --]
Hello,
On Mon, Apr 06, 2026 at 10:24:39PM +0200, George Moussalem via B4 Relay wrote:
> From: Devi Priya <quic_devipriy@quicinc.com>
>
> Driver for the PWM block in Qualcomm IPQ6018 line of SoCs. Based on
> driver from downstream Codeaurora kernel tree. Removed support for older
> (V1) variants because I have no access to that hardware.
>
> Tested on IPQ5018 and IPQ6010 based hardware.
>
> Co-developed-by: Baruch Siach <baruch.siach@siklu.com>
> Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
I have a few remaining nitpicks. If you're ok I'll squash the following
diff into this patch and apply it:
diff --git a/drivers/pwm/pwm-ipq.c b/drivers/pwm/pwm-ipq.c
index b79e5e457d1a..65af19ded72c 100644
--- a/drivers/pwm/pwm-ipq.c
+++ b/drivers/pwm/pwm-ipq.c
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2016-2017, 2020 The Linux Foundation. All rights reserved.
*
- * Hardware notes / Limitations:
+ * Limitations:
* - The PWM controller has no publicly available datasheet.
* - Each of the four channels is programmed via two 32-bit registers
* (REG0 and REG1 at 8-byte stride).
This is to make
sed -rn '/Limitations:/,/\*\/?$/p' drivers/pwm/*.c
do the right thing. I know "Limitations" isn't a good subject for this,
but until I come around to pick a better marker, doing the same in all
drivers is good.
@@ -44,13 +44,6 @@
#define IPQ_PWM_REG1 4
#define IPQ_PWM_REG1_PRE_DIV GENMASK(15, 0)
-
-/*
- * The max value specified for each field is based on the number of bits
- * in the pwm control register for that field (16-bit)
- */
-#define IPQ_PWM_MAX_DIV FIELD_MAX(IPQ_PWM_REG0_PWM_DIV)
-
/*
* Enable bit is set to enable output toggling in pwm device.
* Update bit is set to trigger the change and is unset automatically
@@ -59,6 +52,12 @@
#define IPQ_PWM_REG1_UPDATE BIT(30)
#define IPQ_PWM_REG1_ENABLE BIT(31)
+/*
+ * The max value specified for each field is based on the number of bits
+ * in the pwm control register for that field (16-bit)
+ */
+#define IPQ_PWM_MAX_DIV FIELD_MAX(IPQ_PWM_REG0_PWM_DIV)
+
struct ipq_pwm_chip {
void __iomem *mem;
unsigned long clk_rate;
This is just about ordering definitions taken 1:1 from the manual before
driver specific stuff.
@@ -95,6 +94,12 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long val = 0;
unsigned long hi_dur;
+ if (!state->enabled) {
+ /* clear IPQ_PWM_REG1_ENABLE */
+ ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, IPQ_PWM_REG1_UPDATE);
+ return 0;
+ }
+
if (state->polarity != PWM_POLARITY_NORMAL)
return -EINVAL;
This ensures that the PWM can be disabled even if state->polarity is
bogus or period and duty_cycle are out of range.
@@ -102,7 +107,8 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
* Check the upper and lower bounds for the period as per
* hardware limits
*/
- period_ns = max(state->period, IPQ_PWM_MIN_PERIOD_NS);
+ if (state->period < IPQ_PWM_MIN_PERIOD_NS)
+ return -ERANGE;
period_ns = min(state->period, IPQ_PWM_MAX_PERIOD_NS);
duty_ns = min(state->duty_cycle, period_ns);
This is about correctness. A driver is expected to never configure a
higher value than requested. (And otherwise I would have converted that
to clamp().)
@@ -134,7 +140,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
/* pwm duty = HI_DUR * (PRE_DIV + 1) / clk_rate */
hi_dur = mul_u64_u64_div_u64(duty_ns, ipq_chip->clk_rate,
- (u64)(pre_div + 1) * NSEC_PER_SEC);
+ (u64)NSEC_PER_SEC * (pre_div + 1));
val = FIELD_PREP(IPQ_PWM_REG0_HI_DURATION, hi_dur) |
FIELD_PREP(IPQ_PWM_REG0_PWM_DIV, pwm_div);
Just consistency with the period calculation
@@ -144,9 +150,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, val);
/* PWM enable toggle needs a separate write to REG1 */
- val |= IPQ_PWM_REG1_UPDATE;
- if (state->enabled)
- val |= IPQ_PWM_REG1_ENABLE;
+ val |= IPQ_PWM_REG1_UPDATE | IPQ_PWM_REG1_ENABLE;
ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, val);
return 0;
Simplification that is possible after checking for state->enabled early.
@@ -174,7 +178,7 @@ static int ipq_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
hi_dur = FIELD_GET(IPQ_PWM_REG0_HI_DURATION, reg0);
pre_div = FIELD_GET(IPQ_PWM_REG1_PRE_DIV, reg1);
- effective_div = (u64)(pre_div + 1) * (pwm_div + 1);
+ effective_div = (u64)(pwm_div + 1) * (pre_div + 1)
/*
* effective_div <= 0x100000000, so the multiplication doesn't overflow.
Again consistency.
A nice followup for this patch would be the conversion to the waveform
API; just in case you're still motivated to work on this driver :-)
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms
From: Ernest Van Hoecke @ 2026-04-13 9:32 UTC (permalink / raw)
To: Baochen Qiang
Cc: Manivannan Sadhasivam, Jeff Johnson, Jeff Johnson, Johannes Berg,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-wireless,
linux-kernel, ath10k, ath11k, devicetree, ath12k, Miaoqing Pan
In-Reply-To: <ff11954f-345f-4865-a86e-759aa167768d@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 02:06:00PM +0800, Baochen Qiang wrote:
>
>
> On 11/25/2025 5:57 PM, Ernest Van Hoecke wrote:
> > On Tue, Nov 18, 2025 at 12:23:20PM +0530, Manivannan Sadhasivam wrote:
> >>
> >> ath12k doesn't seem to require a calibration variant. But even if the user
> >> replaces ath11k chipset with ath10k one, the calibration variant should be the
> >> same as it is platform specific except for WSI.
> >>
> >> - Mani
> >>
> >> --
> >> மணிவண்ணன் சதாசிவம்
> >>
> >
> > Hi all,
> >
> > Jumping in on this thread to ask about how we should handle variants.
> >
> > We are using the WCN7850 device with the ath12k driver and received three
> > board files for this from Silex, signed by Qualcomm. All three support the
> > same board (SX-PCEBE), where one is the board file to be used for the
> > US/EU/JP and the other two are one for higher emissions in the UK/CA and
> > one for lower emissions in the UK/CA.
> >
> > Since these are needed for regulatory differences but support the same
> > board, we were wondering about your views on how to handle that in
> > mainline. I see that there is no support for the board file selection in
> > the device tree for ath12k, and that there is some discussion on how to
> > handle variants in general. We are using a device tree-based setup and no
> > ACPI.
>
> does your machine has different 'model' property for different BDFs ?
> does the existing ath11k 'calibration' property based mechanism satisfy your requirement?
>
We have a SoM with always the same WiFi SoC on board. These SoMs are
then mated with a carrier board, in our case often a development board,
and together they form a whole machine for which we have a specific
device tree with a specific model and compatible name.
Customers that create their own carrier board would have their own
device tree with their own model string. These carrier board device
trees include the base SoM dtsi.
When these devices are sold in multiple markets, the model string is
thus not specific to it. For example, the same model string can be sold
in Japan and in Canada, with different regulatory requirements and thus
a different board file that needs to be used.
In short: no, the machine does not have a different model property for
different BDFs.
Similarly, the WCN7850 would also not have a different PCI ID in
different regions since the hardware sold is the same.
The existing ath11k calibration property did provide a way to specify in
the DT which BDF should be used, so in that way it can provide a
solution yes. Of course, with the drawback that the PCI device has to be
specified in the DT.
This would allow customers to ship their device with a different DT
based on the the target market and its regulatory requirements. Another
mechanism that allows them to specify which variant to use in SW/HW
in- or outside the device tree would also work.
Thanks for looking at this and kind regards,
Ernest
^ permalink raw reply
* Re: [PATCH v7 0/2] i2c: Add Loongson-2K0300 I2C controller support
From: Binbin Zhou @ 2026-04-13 9:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Wolfram Sang, Andy Shevchenko,
linux-i2c, Huacai Chen, Xuerui Wang, loongarch, devicetree
In-Reply-To: <CAHp75Veymi3z2atMuSeDyrhyx-HLHgCMzJF5EgpJZzTGgpcD3Q@mail.gmail.com>
On Mon, Apr 13, 2026 at 4:18 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Apr 13, 2026 at 11:08 AM Binbin Zhou <zhoubb.aaron@gmail.com> wrote:
> > On Mon, Apr 13, 2026 at 3:52 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Sat, Apr 11, 2026 at 12:58 PM Binbin Zhou <zhoubinbin@loongson.cn> wrote:
>
> ...
>
> > > > - parent_rate_MHz -> parent_rate_mhz to avoid CamelCase.
> > >
> > > Was it a special requirement from maintainers?
> >
> > I’m actually a bit confused, because when I submitted the v6 patchset,
> > checkpatch didn’t issue this warning.
> > But now, it produces the following output:
> >
> > scripts/checkpatch.pl --strict i2c-ls2k0300-v6/v6-0002*
> > CHECK: Avoid CamelCase: <parent_rate_MHz>
>
> It's a false positive of the checkpatch.
OK, I will revert this change.
>
> > #512: FILE: drivers/i2c/busses/i2c-ls2x-v2.c:437:
> > + priv->parent_rate_MHz = clk_get_rate(priv->clk);
> >
> > total: 0 errors, 0 warnings, 1 checks, 574 lines checked
> >
> > NOTE: For some of the reported defects, checkpatch may be able to
> > mechanically convert to the typical style using --fix or --fix-inplace
> >
> > > Note, the physical units are special. The m and M have quite a
> > > different multiplier value. So, even if asked by somebody I think it's
> > > still arguably should be kept as MHz.
>
> See above why.
I see, thanks.
>
> --
> With Best Regards,
> Andy Shevchenko
--
Thanks.
Binbin
^ 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