* Re: [PATCH v5 3/3] arm64,ppc64le/kdump: pass dm-crypt keys to kdump kernel
From: Rob Herring @ 2026-03-30 11:44 UTC (permalink / raw)
To: Coiby Xu
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree,
Arnaud Lefebvre, Baoquan he, Dave Young, Kairui Song, Pingfan Liu,
Andrew Morton, Krzysztof Kozlowski, Thomas Staudt, Sourabh Jain,
Will Deacon, Christophe Leroy (CS GROUP), Catalin Marinas,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Saravana Kannan, open list
In-Reply-To: <20260225060347.718905-4-coxu@redhat.com>
On Wed, Feb 25, 2026 at 12:04 AM Coiby Xu <coxu@redhat.com> wrote:
>
> CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
> device dump target by addressing two challenges [1],
> - Kdump kernel may not be able to decrypt the LUKS partition. For some
> machines, a system administrator may not have a chance to enter the
> password to decrypt the device in kdump initramfs after the 1st kernel
> crashes
>
> - LUKS2 by default use the memory-hard Argon2 key derivation function
> which is quite memory-consuming compared to the limited memory reserved
> for kdump.
>
> To also enable this feature for ARM64 and PowerPC, the missing piece is
> to let the kdump kernel know where to find the dm-crypt keys which are
> randomly stored in memory reserved for kdump. Introduce a new device
> tree property dmcryptkeys [2] as similar to elfcorehdr to pass the
> memory address of the stored info of dm-crypt keys to the kdump kernel.
> Since this property is only needed by the kdump kernel, it won't be
> exposed to user space.
>
> [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
> [2] https://github.com/devicetree-org/dt-schema/pull/181
>
> Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
> Cc: Baoquan he <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Kairui Song <ryncsn@gmail.com>
> Cc: Pingfan Liu <kernelfans@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Thomas Staudt <tstaudt@de.ibm.com>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> arch/arm64/kernel/machine_kexec_file.c | 4 ++++
> arch/powerpc/kexec/elf_64.c | 4 ++++
> drivers/of/fdt.c | 21 +++++++++++++++++++++
> drivers/of/kexec.c | 19 +++++++++++++++++++
> 4 files changed, 48 insertions(+)
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Dmitry Baryshkov @ 2026-03-30 11:49 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bryan O'Donoghue, Neil Armstrong, Bryan O'Donoghue,
Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vladimir Zapolskiy,
linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <6d5ebab6-3c4e-4a1c-9578-6e926cbd96de@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 01:34:57PM +0200, Konrad Dybcio wrote:
> On 3/30/26 11:25 AM, Bryan O'Donoghue wrote:
> > On 30/03/2026 10:17, Neil Armstrong wrote:
> >> On 3/30/26 11:02, Bryan O'Donoghue wrote:
> >>> On 30/03/2026 08:49, Neil Armstrong wrote:
> >>>> On 3/27/26 18:42, Bryan O'Donoghue wrote:
> >>>>> On 27/03/2026 15:28, Neil Armstrong wrote:
> >>>>>>> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
> >>>>>>
> >>>>>> This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
> >>>>>
> >>>>> I'm not sure what point it is you are trying to make here. Are you trying to say drivers/phy is OK with you but you want an endpoint ? If so, please just say so.
> >>>>
> >>>> I'm against using the "phys = <>" property in the CAMSS to reference the PHYs, a "PHY" in the classic terminology is tied to a single consumer, and if it can be shared to multiple consumer you must model a mux or whatever in the middle.
> >>>
> >>> The CSIPHY-to-CSID routing is runtime-configurable and is already managed by the media controller framework.
> >>
> >> This is not compatible with the PHY bindings if you don't have a defined MUX device in the middle, it's wrong. You're hiding the muxing details in the CAMSS blob node.
> >>
> >>>
> >>> DT describes static hardware connections. The dynamic mux is a software concern, not a hardware description concern.
> >>
> >> DT must describe the possible interconnections between the nodes, if a PHY can be used by multiple hardware components, it must be described.
> >
> > But right now the CAMSS block is described as a single block. There is no CSID device in the kernel _yet_.
> >
> > When we break CSID into its own block then fine, lets have a debate about a mux then but right now the "nodes" are CAMSS[MONOLITH] <=> CSIPHY there is no DT CSID device to model this to.
>
> Let's take a step back - since any CSIPHY can feed into any CSID (at runtime),
> the resulting nodes would either look like:
>
> // hardcoded, m may != n
> csid_n: csid@1000000 {
> phys = <&csiphy_m>;
> };
>
> or
>
> // determined at runtime
> csid_n: csid@1000000 {
> phys = <&csiphy_0>,
> [...]
> <&csiphy_n-1>;
> };
I think the bigger problem is:
&csid_L: {
phys = <&csiphy_M>;
};
&csid_N: {
phys = <&csiphy_M>;
};
aka split mode.
>
> or we could store them once, centrally, in the "CAMSS_TOP" node and
> pass handles around as necessary:
>
> // camss "catalog/manager" driver/library provides CSIDn with PHYm
> camss: camss@10000000 {
> phys = <&csiphy_0>,
> [...]
> <&csiphy_n-1>;
>
> csid_n: csid@1000 {
> // no PHY references
> };
> };
>
> Konrad
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: Rob Herring (Arm) @ 2026-03-30 11:51 UTC (permalink / raw)
To: ASHISH YADAV
Cc: Krzysztof Kozlowski, Ashish Yadav, Guenter Roeck, linux-hwmon,
devicetree, Conor Dooley, linux-kernel
In-Reply-To: <20260330102345.37065-2-Ashish.Yadav@infineon.com>
On Mon, 30 Mar 2026 15:53:44 +0530, ASHISH YADAV wrote:
> From: Ashish Yadav <ashish.yadav@infineon.com>
>
> Add documentation for the device tree binding of the XDP720 eFuse.
>
> Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> ---
>
> This patch introduces a YAML schema describing the required and optional
> properties for the XDP720 eFuse device node. It includes details on the
> compatible string, register mapping, and rimon-micro-ohms(RIMON).
>
> The RIMON resistance is installed between the Imon pin and the ground
> reference.
> ---
> .../bindings/hwmon/pmbus/infineon,xdp720.yaml | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml: properties:infineon,rimon-micro-ohms: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref
from schema $id: http://devicetree.org/meta-schemas/core.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml: properties:infineon,rimon-micro-ohms: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref
from schema $id: http://devicetree.org/meta-schemas/core.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.example.dtb: hwmon@11 (infineon,xdp720): infineon,rimon-micro-ohms: 1098000000 is not of type 'array'
from schema $id: http://devicetree.org/schemas/property-units.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.example.dtb: hwmon@11 (infineon,xdp720): infineon,rimon-micro-ohms: 1098000000 is not of type 'array'
from schema $id: http://devicetree.org/schemas/property-units.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260330102345.37065-2-Ashish.Yadav@infineon.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 00/10] Synopsys DisplayPort Controller improvements for Rockchip platforms
From: Sebastian Reichel @ 2026-03-30 11:50 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Damon Ding,
Dmitry Baryshkov, Alexey Charkov, dri-devel, linux-rockchip,
linux-kernel, devicetree, kernel
In-Reply-To: <FE1BFB774BE13241+54b8a8ce-5a8c-495d-a53f-65a2440924fb@airkyi.com>
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
Hello Chaoyi,
On Mon, Mar 30, 2026 at 09:34:15AM +0800, Chaoyi Chen wrote:
> > There are two parts, which possibly need some discussion:
> >
> > 1. I added a dedicated bridge callback for out-of-band hotplug events,
> > which is separate from the hotplug_notify. I have a feeling, that
> > there might be a better solution, but haven't found it.
>
> Could you explain what an out-of-band hotplug event is?
>
> Can't the drivers/usb/typec/altmodes/displayport.c respond to these
> hot-plug events? Thank you.
That is what generates the out-of-band hotplug event in the first
place via drm_connector_oob_hotplug_event(). The oob in that call
means out of band.
If you look at that function it calls oob_hotplug_event() callback
on the DRM connector, which is then implemented by
drm_bridge_connector_oob_hotplug_event(). This function calls uses
the normal hpd handling (shared by in-band and out-of-band) and I'm
patching it, so that the bridges are aware of hpd explicitly being
provided out-of-band.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: qcom: kaanapali-mtp: Enable bluetooth and Wifi
From: Dmitry Baryshkov @ 2026-03-30 11:53 UTC (permalink / raw)
To: Zijun Hu
Cc: Jingyi Wang, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, aiqun.yu, tingwei.zhang,
trilok.soni, yijie.yang, linux-arm-msm, devicetree, linux-kernel,
20260224-knp-dts-misc-v6-0-79d20dab8a60
In-Reply-To: <ed5a18f8-04f9-4c4f-b4a8-9fc2a277ac40@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 01:15:44PM +0800, Zijun Hu wrote:
> On 3/26/2026 12:10 PM, Dmitry Baryshkov wrote:
> >> 3/25/2026 7:40 PM, Dmitry Baryshkov wrote:
> >>>> On 3/25/2026 3:08 PM, Dmitry Baryshkov wrote:
> >>>>> On Wed, Mar 25, 2026 at 02:40:19PM +0800, Zijun Hu wrote:
> >>>>>> On 3/24/2026 9:16 AM, Dmitry Baryshkov wrote:
> >>>>>>>> +
> >>>>>>>> + wcn7850-pmu {
> >>>>>>>> + compatible = "qcom,wcn7850-pmu";
> >>>>>>>> +
> >>>>>>>> + pinctrl-0 = <&bt_default>, <&sw_ctrl_default>, <&wlan_en>;
> >>>>>>>> + pinctrl-names = "default";
> >>>>>>>> +
> >>>>>>>> + bt-enable-gpios = <&pmh0104_j_e1_gpios 5 GPIO_ACTIVE_HIGH>;
> >>>>>>>> + wlan-enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
> >>>>>>> swctrl-gpios?
> >>>>>> it is '<&sw_ctrl_default>' within 'pinctrl-0' above.
> >>>>>> the input pin is not used by power sequencing driver.
> >>>>>> just give it some default configurations here.
> >>>>> Please don't mix hardware description and the driver. If the pin is
> >>>>> wired, let's describe it in DT.
> >>>>>
> >>>> give comments about that pin in this dts file ?
> >>>> or give a seperated patch to describe the pin in DT binding schema of "qcom,wcn7850-pmu"?
> >>> It is there, as far as I remember.
> >>>
> >>> $ grep swctrl Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml
> >>> swctrl-gpios:
> >> swctrl-gpios may be not applicable for 'qcom,wcn7850-pmu' since there is no 'qcom,wcn7850-pmu' node
> >> which configures 'swctrl-gpios' within upstream DT tree.
> > It's a wrong way to check it.
> > Instead follow these steps:
> > - Is the pin defined in the datasheet?
> datasheet define this pin SW_CTRL with description
> "Switch request to the external PMU between active and sleep mode"
>
> > - Is the pin defined in the schema?
>
> schema define property 'swctrl-gpios' with description
> "GPIO line indicating the state of the clock supply to the BT module"
>
> > - Is the pin wired in the hardware?
> pin SW_CTRL is wired in hardware.
Granted your three answers, it can and should be described in the DT.
>
> i have below confusions about 'swctrl-gpios' of 'qcom,wcn7850-pmu'
> which WCN7850 pin is 'swctrl-gpios' mean for ?
> Why to introduce 'swctrl-gpios' ?
> what problem does it solve ?
> how to solve the problem ?
Please descibe the hardware in the DT. Problem solving belongs to the
driver.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: André Draszik @ 2026-03-30 12:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <355b2f8f-0a3e-4209-8b1e-10600c2b3df9@kernel.org>
On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>
> This causes warnings, so I dropped the patches.
I assume warnings are because I didn't make it clear enough that patch
2 is actually required?
> I really do not
> understand how this is organized. This is not a dependency for pm
> domains driver but it is included here.
The binding is being updated, and the driver follows suit.
I particular, the driver needs to be aware that pd is (can be) a child
of pmu.
Yes, the driver does not depend on this binding update, but it shows what
the driver must support. I believe this is what we have done in the past:
binding and driver updates in same series.
I could move patches 3 and 4 from this series together with a DTS
update patch into a separate series, if that would be deemed a better
approach?
> It is a soft dependency for DTS,
> but that is nowhere to be found.
I was waiting for review of all binding changes before posting DTS.
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v10 2/2] hwmon: add support for MCP998X
From: Victor.Duicu @ 2026-03-30 12:01 UTC (permalink / raw)
To: linux
Cc: corbet, linux-hwmon, devicetree, robh, linux-kernel, krzk+dt,
linux-doc, conor+dt, Marius.Cristea
In-Reply-To: <ccda48d0-3b10-4c3c-a632-6f70b54436fb@roeck-us.net>
Hi Guenter,
...
> > + }
> > +
> > + switch (type) {
> > + case hwmon_temp:
> > + switch (attr) {
> > + case hwmon_temp_input:
> > + /* Block reading from addresses 0x00->0x09 is
> > not allowed. */
> > + ret = regmap_read(priv->regmap,
> > MCP9982_HIGH_BYTE_ADDR(channel), ®_high);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_read(priv->regmap,
> > MCP9982_HIGH_BYTE_ADDR(channel) + 1,
> > + ®_low);
> > + if (ret)
> > + return ret;
>
> Reading the 11-bit temperature value involves two separate 8-bit
> register reads.
> If the chip updates the temperature between these two reads, the
> resulting value
> may be torn. While some chips latch the low byte upon reading the
> high byte,
> the driver does not explicitly rely on or document this behavior, and
> it's safer
> to use regmap_bulk_read if supported, or at least ensure the correct
> order and
> atomicity if possible.
>
> Note: Maybe the low temperature is latched, but there is no
> indication in the
> datasheet that this would be the case. Even if it is, the code above
> is
> inefficient.
The low temperature register is latched. In the documentation at
page 32 it is described that when reading the high byte register,
the value from the low byte register is copied into a 'shadow'
register. In this way it is guaranteed that when we read the low byte,
it will correspond to the high byte.
Regarding the bulk read, the chip has a number of design quirks and
because of that different commands are supported only on some
particular memory regions.
According to the documentation page 26, the only areas of memory that
support SMBus block read are 80h->89h(temperature memory block) and
90h->97h(status memory block). In order to block read the temperatures,
the area of memory targeted has to be the temperature memory block. In
this context the read operation uses SMBus protocol and the first value
returned will be the number of addresses that can be read (in our
particular case a max value of 10 bytes).
In v8 of the driver
https://lore.kernel.org/all/20251120071248.3767-1-victor.duicu@microchip.com/
,
the temperature values were read with regmap_bulk_read(). In that
version, regmap_bulk_read() was also used to read the temperature
limits, without returning count (this is an undocumented feature of the
chip and because of that we could assume is not supported).
In order to avoid this behaviour and avoid mixing the SMBus and I2C
protocols all block readings were removed.
In the hopes of bypassing a long chain of replies, I tested the
behaviour of the chip with different read instructions.
Regmap_bulk_read() when applied to the temperature memory block
(80h->89h) returns count and the high and low bytes. When it is applied
to the 00h->09h memory, it uses I2C. It returns one temperature byte,
but all other bytes are returned as 0xFF. The chip behaves as if
it is at the last register location in the temperature block while the
host continues to ACK.(behaviour described at page 26).
If we set use_single_read in regmap_config and apply regmap_bulk_read()
to the 00h->09h register area the high and low temperature bytes are
read successfully without count.
Regmap_multi_reg_read() reads a number of registers one by one. When
applied to the 00h->09h area, I2C is used and it returns only the high
and low temperature bytes. When applied to the temperature memory block
(80h->89h), because it is not a bulk function, returns the count till
the end of the temperature memory block (aka SMBus count).
I2c_smbus_read_block_data() when applied to the temperature block (80h-
89h) returns the count, the driver replies with an NACK and the
communication is stopped. In our case, the board we are using to test
the driver has an AT91 adapter and supports
I2C_FUNC_SMBUS_READ_BLOCK_DATA. It seems that the I2C driver for AT91
does not modify the buff length of the message, leaving it 1.
I2c_smbus_read_i2c_block_data() when applied to the temperature block
(80h-89h) returns count and the temperature values.
If you are of the opinion that block reading the temperatures is worth
introducing (even in case we need to skip count) then I can add it, but
we should come to an agreement on which function to use.
Please let me know your thoughts.
Kind regards,
Victor
^ permalink raw reply
* [PATCH 0/5] cpufreq: ti: Fix probe ordering and add device link support for K3 SoCs
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
For K3 SoCs, ti-cpufreq depends on k3-socinfo to provide SoC revision
information via soc_device_match(). If ti-cpufreq probes before
k3-socinfo, soc_device_match() returns NULL, causing incorrect
revision detection and OPP table initialization failures.
Add EPROBE_DEFER handling in ti-cpufreq when soc_device_match() fails
for K3 SoCs, ensuring k3-socinfo probes first.
Add device link support via a new DT property "ti,soc-info" in CPU
OPP tables. Device links prevent unbinding k3-socinfo while
ti-cpufreq is using it.
EPROBE_DEFER handles first-boot probe ordering, while device links
provide runtime dependency management.
For backward compatibility, the DT property is optional.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (5):
cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
cpufreq: ti: Add device link to k3-socinfo
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
drivers/cpufreq/ti-cpufreq.c | 57 +++++++++++++++++++++++++++
4 files changed, 60 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH 1/5] cpufreq: ti: Add EPROBE_DEFER for K3 SoCs
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Defer probe when k3-socinfo hasn't registered the SoC device yet.
Fixes incorrect revision detection when ti-cpufreq probes first.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 3d1129aeed02..88f7912ef6a8 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -441,6 +441,15 @@ static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
*/
*revision_value = 0x1;
goto done;
+ } else if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ /*
+ * For K3 SoCs, if soc_device_match fails, socinfo hasn't
+ * probed yet. Defer probe to wait for it.
+ */
+ return -EPROBE_DEFER;
}
ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
--
2.34.1
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: ti: k3-am625: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am625.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625.dtsi b/arch/arm64/boot/dts/ti/k3-am625.dtsi
index c249883a8a8d..b0020e667882 100644
--- a/arch/arm64/boot/dts/ti/k3-am625.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am625.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ti: k3-am62a7: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62a7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
index b6e5eee99370..6d1459e9ea71 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a7.dtsi
@@ -109,6 +109,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
index 8982a7b9f1a6..1a498c5eb3d1 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
@@ -108,6 +108,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Create explicit device link when OPP table has ti,soc-info property.
Prevents unbinding k3-socinfo while ti-cpufreq is using it.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 48 ++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 88f7912ef6a8..60c34b0da0c5 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/regmap.h>
@@ -111,6 +112,7 @@ struct ti_cpufreq_data {
struct device_node *opp_node;
struct regmap *syscon;
const struct ti_cpufreq_soc_data *soc_data;
+ struct device_link *soc_link;
};
static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
@@ -542,6 +544,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return -ENOMEM;
opp_data->soc_data = match->data;
+ platform_set_drvdata(pdev, opp_data);
opp_data->cpu_dev = get_cpu_device(0);
if (!opp_data->cpu_dev) {
@@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (ret)
goto fail_put_node;
+ /* Create device link to k3-socinfo if specified in DT */
+ if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ struct device_node *socinfo_np;
+
+ socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
+ if (socinfo_np) {
+ struct platform_device *socinfo_pdev;
+ struct device_link *link;
+
+ socinfo_pdev = of_find_device_by_node(socinfo_np);
+ of_node_put(socinfo_np);
+
+ if (!socinfo_pdev) {
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ if (!socinfo_pdev->dev.driver) {
+ put_device(&socinfo_pdev->dev);
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ link = device_link_add(opp_data->cpu_dev,
+ &socinfo_pdev->dev,
+ DL_FLAG_STATELESS);
+ if (link)
+ opp_data->soc_link = link;
+
+ put_device(&socinfo_pdev->dev);
+ }
+ }
+
/*
* OPPs determine whether or not they are supported based on
* two metrics:
@@ -600,6 +639,14 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return ret;
}
+static void ti_cpufreq_remove(struct platform_device *pdev)
+{
+ struct ti_cpufreq_data *opp_data = platform_get_drvdata(pdev);
+
+ if (opp_data && opp_data->soc_link)
+ device_link_del(opp_data->soc_link);
+}
+
static int __init ti_cpufreq_init(void)
{
const struct of_device_id *match;
@@ -616,6 +663,7 @@ module_init(ti_cpufreq_init);
static struct platform_driver ti_cpufreq_driver = {
.probe = ti_cpufreq_probe,
+ .remove = ti_cpufreq_remove,
.driver = {
.name = "ti-cpufreq",
},
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-30 12:03 UTC (permalink / raw)
To: Dmitry Baryshkov, Konrad Dybcio
Cc: Neil Armstrong, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vladimir Zapolskiy, linux-arm-msm, linux-phy,
linux-media, devicetree, linux-kernel
In-Reply-To: <gcu6qzsoff2fox3nbytegyikajn65ae4ekowcn7bs4x2k53vao@rykmxndzzhlu>
On 30/03/2026 12:49, Dmitry Baryshkov wrote:
>> // determined at runtime
>> csid_n: csid@1000000 {
>> phys = <&csiphy_0>,
>> [...]
>> <&csiphy_n-1>;
>> };
> I think the bigger problem is:
>
> &csid_L: {
> phys = <&csiphy_M>;
> };
>
> &csid_N: {
> phys = <&csiphy_M>;
> };
>
> aka split mode.
Depends on how you model it.
It feels like a philosophical as opposed to an engineering debate in a way.
The CSIPHY block is defined as one thing - is split mode one PHY or two ?
You could argue it either way BUT one strong argument for it being one
PHY is - voltage rails, input clocks etc power the block.
Sure there is an esoteric mode called split or combo mode but the
hardware block itself the thing we usually call the PHY lives as a block
diagram as a discreet entity.
So I think split-mode really is more like
&csid_L: {
phys = <&csiphy_0 DPHY>, <&csiphy_1 CPHY>;
};
&csid_M: {
phys = <&csiphy_0 DPHY>, <&csiphy_1 CPHY>;
};
Recall the debate about a mux is because CSID may connect to any CSIPHY.
csiphy_0: {
clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
<&camcc CAM_CC_CSI0PHYTIMER_CLK>;
clock-names = "core",
"timer";
operating-points-v2 = <&csiphy_opp_table>;
interrupts = <GIC_SPI 1 IRQ_TYPE_EDGE_RISING>;
power-domains = <&rpmhpd RPMHPD_MX>,
<&rpmhpd RPMHPD_MMCX>;
power-domain-names = "mx",
"mmcx";
vdda-0p9-supply = <&vreg_xyz_0p8>;
vdda-1p2-supply = <&vreg_qrs_1p2>;
ports {
port@0{};
port@1{};
};
};
csiphy_N: {
clocks = <&camcc CAM_CC_CSIPHY1_CLK>,
<&camcc CAM_CC_CSI1PHYTIMER_CLK>;
clock-names = "core",
"timer";
operating-points-v2 = <&csiphy_opp_table>;
interrupts = <GIC_SPI 2 IRQ_TYPE_EDGE_RISING>;
power-domains = <&rpmhpd RPMHPD_MX>,
<&rpmhpd RPMHPD_MMCX>;
power-domain-names = "mx",
"mmcx";
vdda-0p9-supply = <&vreg_abc_0p8>;
vdda-1p2-supply = <&vreg_def_1p2>;
ports {
port@0{};
};
};
IMO split mode is a special mode of that hardware block, not two
individual PHYs.
---
bod
^ permalink raw reply
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: Krzysztof Kozlowski @ 2026-03-30 12:10 UTC (permalink / raw)
To: André Draszik, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <dcf2c447d9bbe16e800a4dd7e74ecc26d3ade3db.camel@linaro.org>
On 30/03/2026 14:00, André Draszik wrote:
> On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>>
>> This causes warnings, so I dropped the patches.
>
> I assume warnings are because I didn't make it clear enough that patch
> 2 is actually required?
No, these are obvious errors coming from bindings. You can try yourself
instead of asking maintainer to run the commands for you...
>
>> I really do not
>> understand how this is organized. This is not a dependency for pm
>> domains driver but it is included here.
>
> The binding is being updated, and the driver follows suit.
> I particular, the driver needs to be aware that pd is (can be) a child
> of pmu.
>
> Yes, the driver does not depend on this binding update, but it shows what
> the driver must support. I believe this is what we have done in the past:
> binding and driver updates in same series.
Yes, foo-binding goes with foo-driver to foo-subsystem. It does not mean
you put here completely different bindings. Why? Because just like foo
goes to foo-subsystem, then bar-binding goes with bar-driver to
bar-subsystem.
>
> I could move patches 3 and 4 from this series together with a DTS
> update patch into a separate series, if that would be deemed a better
> approach?
I asked you what are the dependencies and you answer there are some but
you can move it outside of patchset. So are there or are there not
dependencies? If there are, then you cannot move out. But then I ask
what are the dependencies.
It feels like question to trick the maintainer. Maintainer complained,
so you propose whatever he objected to without understanding whether
this is correct or not correct approach.
>
>> It is a soft dependency for DTS,
>> but that is nowhere to be found.
>
> I was waiting for review of all binding changes before posting DTS.
That would be fine explanation, if you also read maintainer soc profile
for Samsung and try what is written there. You would see that you
introduced new warnings without any fix possible as far as next is
concerned.
Best regards,
Krzysztof
^ permalink raw reply
* Re: New default binding for PWM devices? [Was: Re: [PATCH] dt-bindings: timer: xlnx,xps-timer: Make PWM in example usable]
From: Geert Uytterhoeven @ 2026-03-30 12:12 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Krzysztof Kozlowski, Sean Anderson, linux-kernel,
linux-pwm, devicetree, Chris Packham, Marek Vasut
In-Reply-To: <erst43cabswj3cwnszssolgyoh4dsgrlnjjxhb7luk3qkqhyay@6zyoixljvwwg>
Hi Uwe,
On Sat, 7 Jun 2025 at 09:23, Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
> On Fri, Jun 06, 2025 at 09:13:24AM -0500, Rob Herring wrote:
> > reg:
> > > maxItems: 1
> > >
> > > - '#pwm-cells': true
> > > + '#pwm-cells':
> > > + const: 3
> > >
> > > xlnx,count-width:
> > > $ref: /schemas/types.yaml#/definitions/uint32
> > > @@ -82,7 +83,7 @@ examples:
> > > };
> > >
> > > timer@800f0000 {
> > > - #pwm-cells = <0>;
> > > + #pwm-cells = <3>;
> > > clock-names = "s_axi_aclk";
> > > clocks = <&zynqmp_clk 71>;
> > > compatible = "xlnx,xps-timer-1.00.a";
> > >
> > > There is however one concern that I want to get resolved first to
> > > prevent churn:
> > >
> > > In principle I think it's bad that a phandle to a PWM must contain a
> > > period and flags specifying the polarity. For some use cases the period
> > > might not matter or is implicitly given or more than one period length
> > > is relevant.
> >
> > Why can't the period be 0 and no flags set if they aren't needed?
>
> I don't say they cannot, and probably that's the most sane option if
> there is no fixed default period and flags and we're sticking to 3
> cells.
So zero should have been used for drivers/pwm/pwm-argon-fan-hat.c?
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
* [PATCH v2] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Ronald Claveau @ 2026-03-30 12:11 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Krzysztof Kozlowski, Ronald Claveau
Fix introduced invalid property for Khadas VIM4 sdcard regulator.
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603290828.5gt393t6-lkp@intel.com/
Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v2:
- Add Fixes tag according to Krzysztof's review.
- Link to v1: https://lore.kernel.org/r/20260330-fix-invalid-property-v1-1-e829c4d806cb@aliel.fr
---
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 11bfbc99191b6..003b3bcdaf2bc 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -65,7 +65,6 @@ sd_3v3: regulator-sdcard-3v3 {
vin-supply = <&vddao_3v3>;
gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
regulator-boot-on;
- enable-active-low;
regulator-always-on;
};
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260330-fix-invalid-property-bbe54d933f71
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
* [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Eliza QMP PHY
From: Abel Vesa @ 2026-03-30 12:19 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Abel Vesa
The QMP combo PHY found on Eliza SoC is fully compatible with the one
found on SM8650.
So document its compatible string and use the SM8650 as fallback.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
index 3d537b7f9985..4eff92343ce4 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
@@ -16,6 +16,10 @@ description:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - qcom,eliza-qmp-usb3-dp-phy
+ - const: qcom,sm8650-qmp-usb3-dp-phy
- items:
- enum:
- qcom,kaanapali-qmp-usb3-dp-phy
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260327-eliza-phy-usb-dp-combo-5a117520ac5b
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH] scripts/dtc: Remove unused dts_version in dtc-lexer.l
From: Rob Herring @ 2026-03-30 12:19 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Saravana Kannan, Nick Desaulniers, Bill Wendling, Justin Stitt,
devicetree, linux-kernel, llvm, stable
In-Reply-To: <20260327-dtc-drop-dts_version-v1-1-41066690aefd@kernel.org>
On Fri, Mar 27, 2026 at 4:39 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> A recent strengthening of -Wunused-but-set-variable (enabled with -Wall)
> in clang under a new subwarning, -Wunused-but-set-global, points out an
> unused static global variable in dtc-lexer.lex.c (compiled from
> dtc-lexer.l):
>
> scripts/dtc/dtc-lexer.lex.c:641:12: warning: variable 'dts_version' set but not used [-Wunused-but-set-global]
> 641 | static int dts_version = 1;
> | ^
>
> This variable has been unused since commit 658f29a51e98 ("of/flattree:
> Update dtc to current mainline."). Remove it to clear up the warning.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> This is commit 53373d1 ("dtc: Remove unused dts_version in dtc-lexer.l")
> in upstream dtc. I sent it separately to make it easier to backport to
> stable, along with updating the warning and hash to match the kernel's
> version.
> ---
> scripts/dtc/dtc-lexer.l | 3 ---
> 1 file changed, 3 deletions(-)
We don't take changes to dtc as we just sync with the upstream copy. I
saw you already submitted this upstream, so I will do a sync to pull
this in.
Rob
^ permalink raw reply
* Re: [PATCH v5 3/3] arm: dts: ti: Add device tree support for PRU-ICSS on AM335x
From: Parvathi Pudi @ 2026-03-30 12:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: Parvathi Pudi, Krzysztof Kozlowski, Kevin Hilman, nm,
Vignesh Raghavendra, afd, rogerq, tony, robh, krzk+dt, conor+dt,
richardcochran, aaro koskinen, andreas, linux-omap, devicetree,
linux-kernel, netdev, danishanwar, pratheesh, j-rameshbabu,
praneeth, srk, rogerq, m-malladi, krishna, mohan, pmohan,
basharath, Murali Karicheri
In-Reply-To: <6c523569-928b-4df5-89f3-9a460d5f6020@lunn.ch>
Hi,
>> We have verified that dtbs_check does report this issue, and we will update
>> our test setup to retain full dtbs_check output to avoid missing such warnings
>> in the future.
>
> I would expect the exit value is set to something other than 0 when it
> finds an error. Why not just fail the test based on that?
>
Earlier, we were using the command "grep -v '^\s\s*'" to capture the logs.
We noticed that this command skips capturing output lines that starts with an
indent. To prevent this, we have temporarily modified the grep command to capture
the full output. The downside is that this results in a bigger log file.
We will review and try to come up with a better way to handle this issue.
Thanks and Regards,
Parvathi
^ permalink raw reply
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Rodrigo Alencar @ 2026-03-30 12:49 UTC (permalink / raw)
To: Rodrigo Alencar, Andy Shevchenko
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <x34d7jz7be4ommjh6efx5mcq5pbpellykwuyrqayr4ske3lywf@wh46mu3anmcz>
On 26/03/27 03:17PM, Rodrigo Alencar wrote:
> On 26/03/27 12:21PM, Andy Shevchenko wrote:
> > On Fri, Mar 27, 2026 at 10:11:56AM +0000, Rodrigo Alencar wrote:
> > > On 26/03/27 11:17AM, Andy Shevchenko wrote:
> > > > On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > > > > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
...
> > > > Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
> > > >
> > > > With that we will always consider the fraction part as 32- or 64-bit,
> > > > imply floor() on the fraction for the sake of simplicity and require
> > > > it to be NUL-terminated with possible trailing '\n'.
> > >
> > > I think this is a good idea, but calling it float or fixed point itself
> > > is a bit confusing as float often refers to the IEEE 754 standard and
> > > fixed point types is often expressed in Q-format.
> >
> > Yeah... I am lack of better naming.
>
> decimals is the name, but they are often represented as:
>
> DECIMAL = INT * 10^X + FRAC
>
> in a single 64-bit number, which would be fine for my end use case.
> However IIO decimal fixed point parsing is out there for quite some time a
> lot of drivers use that. The interface often relies on breaking parsed values
> into an integer array (for standard attributes int val and int val2 are expected).
Thinking about this again and in IIO drivers we end up doing something like:
val64 = (u64)val * MICRO + val2;
so that drivers often work with scaled versions of the decimal value.
then, would it make sense to have a function that already outputs such value?
That would allow to have more freedom over the 64-bit split between integer
and fractional parts.
As a draft:
static int _kstrtodec64(const char *s, unsigned int scale, u64 *res)
{
u64 _res = 0, _frac = 0;
unsigned int rv;
if (*s != '.') {
rv = _parse_integer(s, 10, &_res);
if (rv & KSTRTOX_OVERFLOW)
return -ERANGE;
if (rv == 0)
return -EINVAL;
s += rv;
}
if (*s == '.') {
s++;
rv = _parse_integer_limit(s, 10, &_frac, scale);
if (rv & KSTRTOX_OVERFLOW)
return -ERANGE;
if (rv == 0)
return -EINVAL;
s += rv;
if (rv < scale)
_frac *= int_pow(10, scale - rv);
while (isdigit(*s)) /* truncate */
s++;
}
if (*s == '\n')
s++;
if (*s)
return -EINVAL;
if (check_mul_overflow(_res, int_pow(10, scale), &_res) ||
check_add_overflow(_res, _frac, &_res))
return -ERANGE;
*res = _res;
return 0;
}
noinline
int kstrtoudec64(const char *s, unsigned int scale, u64 *res)
{
if (s[0] == '+')
s++;
return _kstrtodec64(s, scale, res);
}
EXPORT_SYMBOL(kstrtoudec64);
noinline
int kstrtosdec64(const char *s, unsigned int scale, s64 *res)
{
u64 tmp;
int rv;
if (s[0] == '-') {
rv = _kstrtodec64(s + 1, scale, &tmp);
if (rv < 0)
return rv;
if ((s64)-tmp > 0)
return -ERANGE;
*res = -tmp;
} else {
rv = kstrtoudec64(s, scale, &tmp);
if (rv < 0)
return rv;
if ((s64)tmp < 0)
return -ERANGE;
*res = tmp;
}
return 0;
}
EXPORT_SYMBOL(kstrtosdec64);
e.g., kstrtosdec64() or kstrtoudec64() parses "3.1415" with scale 3 into 3141
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 5/7] dt-bindings: cache: ax45mp-cache: rename ax45mp-cache to llcache
From: Rob Herring (Arm) @ 2026-03-30 12:51 UTC (permalink / raw)
To: Hui Min Mina Chou
Cc: krzk+dt, jonathan.cameron, pjw, palmer, conor+dt, aou, alex749,
az70021, linux-renesas-soc, linux-kernel,
prabhakar.mahadev-lad.rj, devicetree, linux-riscv, geert+renesas,
alex, magnus.damm, ben717, tim609
In-Reply-To: <20260330102724.1012470-6-minachou@andestech.com>
On Mon, 30 Mar 2026 18:27:22 +0800, Hui Min Mina Chou wrote:
> The AX45MP-specific cache binding is renamed to a generic Last Level
> Cache (LLC) schema, as the driver now supports more Andes CPU cores
> beyond just AX45MP.
>
> Updated compatible strings:
> andestech,qilai-ax45mp-cache -> andestech,qilai-llcache
> renesas,r9a07g043f-ax45mp-cache -> renesas,r9a07g043f-llcache
> andestech,ax45mp-cache -> andestech,llcache
>
> Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
> ---
> ...ache.yaml => andestech,andes-llcache.yaml} | 20 +++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
> rename Documentation/devicetree/bindings/cache/{andestech,ax45mp-cache.yaml => andestech,andes-llcache.yaml} (76%)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
$id: http://devicetree.org/schemas/cache/andestech,llcache.yaml
file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260330102724.1012470-6-minachou@andestech.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 5/7] dt-bindings: cache: ax45mp-cache: rename ax45mp-cache to llcache
From: Krzysztof Kozlowski @ 2026-03-30 13:00 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021
In-Reply-To: <20260330102724.1012470-6-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> The AX45MP-specific cache binding is renamed to a generic Last Level
> Cache (LLC) schema, as the driver now supports more Andes CPU cores
> beyond just AX45MP.
>
> Updated compatible strings:
> andestech,qilai-ax45mp-cache -> andestech,qilai-llcache
> renesas,r9a07g043f-ax45mp-cache -> renesas,r9a07g043f-llcache
> andestech,ax45mp-cache -> andestech,llcache
Why? No explanations and that is clear ABI break.
=
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] cache: ax45mp_cache: refactor cache driver for generic Andes platform support
From: Krzysztof Kozlowski @ 2026-03-30 13:01 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021, charles
In-Reply-To: <20260330102724.1012470-2-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> -
> -static const struct riscv_nonstd_cache_ops ax45mp_cmo_ops __initdata = {
> - .wback = &ax45mp_dma_cache_wback,
> - .inv = &ax45mp_dma_cache_inv,
> - .wback_inv = &ax45mp_dma_cache_wback_inv,
> -};
> -
> -static const struct of_device_id ax45mp_cache_ids[] = {
> - { .compatible = "andestech,ax45mp-cache" },
NAK, actual ABI break.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/7] cache: andes_llcache: refactor initialization and cache operations
From: Krzysztof Kozlowski @ 2026-03-30 13:02 UTC (permalink / raw)
To: Hui Min Mina Chou, pjw, palmer, aou, alex, geert+renesas,
prabhakar.mahadev-lad.rj, magnus.damm, ben717, robh, krzk+dt,
conor+dt, jonathan.cameron, devicetree, linux-riscv, linux-kernel,
linux-renesas-soc
Cc: tim609, alex749, az70021
In-Reply-To: <20260330102724.1012470-3-minachou@andestech.com>
On 30/03/2026 12:27, Hui Min Mina Chou wrote:
> This patch cleans up the Andes LLC cache driver:
> - improved error handling in andes_cache_init() by using goto labels
> - updated andes_dma_cache_inv/wback() to check for !size instead of
> start == end
> - cache-line-size mismatch from an error to a warning
> - Use ALIGN and ALIGN_DOWN helpers instead of the alignment logic in
> andes_dma_cache_inv() and andes_dma_cache_wback().
Please read submitting patches document. One thing per commit with
proper rationale WHY you are doing this.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox