* Re: [PATCH v4 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Krzysztof Kozlowski @ 2026-06-12 8:53 UTC (permalink / raw)
To: Ziming Zhu
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc, Ziming Zhu, Conor Dooley
In-Reply-To: <20260612030304.5165-2-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:02AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add devicetree binding documentation for the Silergy SQ24860 eFuse.
>
> The device is a PMBus hardware monitoring device which reports voltage,
> current, power, and temperature telemetry. The board-specific IMON
> resistor value is described with silergy,rimon-micro-ohms.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
>
Do not add blank lines between tags. I recommend to use b4 to handle
this - it would solve your problems, including the missing tag in
previous version.
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> .../bindings/hwmon/pmbus/silergy,sq24860.yaml | 74 +++++++++++++++++++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
> new file mode 100644
> index 000000000000..03ef82c11e1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/hwmon/pmbus/silergy,sq24860.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Silergy SQ24860 eFuse
> +
> +maintainers:
> + - Ziming Zhu <ziming.zhu@silergycorp.com>
> +
> +description:
> + The Silergy SQ24860 is an integrated, high-current circuit protection and
> + power management device with PMBus interface.
> +
> +properties:
> + compatible:
> + const: silergy,sq24860
> +
> + reg:
> + maxItems: 1
> +
> + silergy,rimon-micro-ohms:
Isn't this just shunt-resistor-micro-ohms? IOW, didn't you just describe
the shunt?
> + description:
> + Micro-ohms value of the resistance installed between the IMON pin and
> + the ground reference.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10 2/6] clk: Introduce clk_hw_set_spread_spectrum
From: sashiko-bot @ 2026-06-12 8:54 UTC (permalink / raw)
Cc: robh, conor+dt, devicetree
In-Reply-To: <20260612-clk-v10-v10-2-eb92484eda38@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] clk_hw_set_spread_spectrum() modifies clock hardware state without checking if the clock rate is exclusively protected.
- [Medium] clk_hw_set_spread_spectrum() silently returns success (0) when the clock provider does not implement the set_spread_spectrum callback.
--
commit fbe42efd1852814fc95559f8dd8be280e7cdb66e
Author: Peng Fan <peng.fan@nxp.com>
clk: Introduce clk_hw_set_spread_spectrum
This commit adds clk_hw_set_spread_spectrum() to configure the spread spectrum
feature of a clock. It also introduces the set_spread_spectrum callback for
clock drivers to provide hardware-specific implementations.
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 048adfa86a5d0..8c78621cde253 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
[ ... ]
> @@ -2774,6 +2774,33 @@ int clk_set_max_rate(struct clk *clk, unsigned long rate)
> }
> EXPORT_SYMBOL_GPL(clk_set_max_rate);
>
> +int clk_hw_set_spread_spectrum(struct clk_hw *hw, const struct clk_spread_spectrum *ss_conf)
> +{
> + struct clk_core *core;
> + int ret;
> +
> + if (!hw)
> + return 0;
> +
> + core = hw->core;
> +
> + clk_prepare_lock();
> +
> + ret = clk_pm_runtime_get(core);
> + if (ret)
> + goto fail;
> +
[Severity: High]
Should this check if the clock rate is exclusively protected before modifying
the hardware state?
Other clock adjustment functions like clk_set_phase() or clk_set_rate() check
clk_core_rate_is_protected(core) and return -EBUSY to prevent interference
with consumers that require a strict, stable clock. Since enabling spread
spectrum dynamically modulates the frequency, it seems like it could disrupt
consumers relying on that protection.
> + if (core->ops->set_spread_spectrum)
> + ret = core->ops->set_spread_spectrum(hw, ss_conf);
> +
[Severity: Medium]
If the clock provider does not implement the set_spread_spectrum callback,
will this silently return 0 (success) because ret was set to 0 by a
successful clk_pm_runtime_get(core)?
Returning success when the operation is unsupported might mislead callers into
believing the spread spectrum modulation is active. Does it make sense to
return an error code like -EOPNOTSUPP instead?
> + clk_pm_runtime_put(core);
> +
> +fail:
> + clk_prepare_unlock();
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_set_spread_spectrum);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-clk-v10-v10-0-eb92484eda38@nxp.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: hwmon: ina2xx: add ina232 compatible
From: Krzysztof Kozlowski @ 2026-06-12 8:54 UTC (permalink / raw)
To: Loic Poulain, Guenter Roeck, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-hwmon, devicetree, linux-kernel, linux-arm-msm,
Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-1-e4375ce652d0@oss.qualcomm.com>
On 11/06/2026 16:05, Loic Poulain wrote:
> From: Martino Facchin <m.facchin@arduino.cc>
>
> The INA232 is a current/power monitor from Texas Instruments sharing
> the same register map as the other INA2xx.
>
> Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10 3/6] clk: conf: Support assigned-clock-sscs
From: sashiko-bot @ 2026-06-12 8:54 UTC (permalink / raw)
Cc: robh, devicetree, conor+dt
In-Reply-To: <20260612-clk-v10-v10-3-eb92484eda38@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Spread Spectrum Configuration (SSC) is applied before clock parents and rates are set, which can result in the SSC configuration being overwritten or becoming mathematically invalid.
- [Medium] Parsing `assigned-clock-sscs` by casting an array of `struct clk_spread_spectrum` to a `u32 *` violates strict typing and is highly brittle.
--
commit dcd88e4f08b6ae89c38dd70d8a94011d30708d37
Author: Peng Fan <peng.fan@nxp.com>
clk: conf: Support assigned-clock-sscs
This commit adds support for parsing Spread Spectrum Configuration (SSC) from
the device tree and configuring clocks accordingly. It introduces a new
function to read the assigned-clock-sscs property and apply the settings.
> diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c
> index 303a0bb26e54a..550b8ae375a2c 100644
> --- a/drivers/clk/clk-conf.c
> +++ b/drivers/clk/clk-conf.c
> @@ -155,6 +155,78 @@ static int __set_clk_rates(struct device_node *node, bool clk_supplier)
[ ... ]
> +static int __set_clk_spread_spectrum(struct device_node *node, bool clk_supplier)
> +{
[ ... ]
> + sscs = kcalloc(count, elem_size, GFP_KERNEL);
> + if (!sscs)
> + return -ENOMEM;
> +
> + rc = of_property_read_u32_array(node, "assigned-clock-sscs", (u32 *)sscs,
> + count * 3);
[Severity: Medium]
Is it safe to cast an array of struct clk_spread_spectrum to u32 * here?
If any fields are added to the struct or the compiler adds padding, the OF
helper will read data in 12-byte chunks, which will silently misalign with the
struct array boundaries for all elements after the first.
Would it be better to read into a dynamically allocated temporary u32 array
and explicitly populate each struct field?
> + if (rc)
> + goto free_sscs;
> +
[ ... ]
> @@ -174,6 +246,10 @@ int of_clk_set_defaults(struct device_node *node, bool clk_supplier)
> if (!node)
> return 0;
>
> + rc = __set_clk_spread_spectrum(node, clk_supplier);
> + if (rc < 0)
> + return rc;
> +
> rc = __set_clk_parents(node, clk_supplier);
[Severity: High]
Does configuring spread spectrum before setting clock parents and rates cause
issues?
Spread spectrum modulates the base frequency, so its hardware parameters
usually depend on the final base rate and parent clock. By configuring SSC
first, the settings might be computed based on the old hardware state, or
subsequent rate and parent changes might wipe out the SSC settings.
Should SSC be configured after parents and rates are set?
> if (rc < 0)
> return rc;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-clk-v10-v10-0-eb92484eda38@nxp.com?part=3
^ permalink raw reply
* Re: [PATCH v10 4/6] clk: Add KUnit tests for assigned-clock-sscs
From: sashiko-bot @ 2026-06-12 8:55 UTC (permalink / raw)
Cc: conor+dt, devicetree, robh
In-Reply-To: <20260612-clk-v10-v10-4-eb92484eda38@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Extraneous `assigned-clock-sscs` properties injected into `u64` rate test overlays without accompanying test assertions.
--
commit 210e00ec864807cd43e4b4e5dca8755417d9ee5a
Author: Peng Fan <peng.fan@nxp.com>
Subject: clk: Add KUnit tests for assigned-clock-sscs
This commit adds KUnit test coverage for the assigned-clock-sscs device tree
property. It extends the dummy clock framework to support spread spectrum
configuration and introduces a new test suite with several scenarios,
including single assignments, multiple assignments, and malformed DT
properties. It also adds new DT overlays for these test scenarios.
> diff --git a/drivers/clk/kunit_clk_assigned_rates_u64_multiple.dtso b/drivers/clk/kunit_clk_assigned_rates_u64_multiple.dtso
> index 389b4e2eb7f74..3a717dab2d00b 100644
> --- a/drivers/clk/kunit_clk_assigned_rates_u64_multiple.dtso
> +++ b/drivers/clk/kunit_clk_assigned_rates_u64_multiple.dtso
> @@ -12,5 +12,11 @@ clk: kunit-clock {
> <&clk 1>;
> assigned-clock-rates-u64 = /bits/ 64 <ASSIGNED_RATES_0_RATE>,
> /bits/ 64 <ASSIGNED_RATES_1_RATE>;
> + assigned-clock-sscs = <ASSIGNED_SSCS_0_MODFREQ
> + ASSIGNED_SSCS_0_SPREAD
> + ASSIGNED_SSCS_0_METHOD>,
> + <ASSIGNED_SSCS_1_MODFREQ
> + ASSIGNED_SSCS_1_SPREAD
> + ASSIGNED_SSCS_1_METHOD>;
[Severity: Low]
Looking at the kunit-clock node in
drivers/clk/kunit_clk_assigned_rates_u64_multiple.dtso, are these
assigned-clock-sscs properties necessary in the u64 rate test overlays?
The test cases utilizing these overlays only verify rate assignments and do
not assert anything about the parsed SSCS state. Since dedicated SSCS test
overlays were added, it seems these additions might be extraneous.
> };
> };
[ ... ]
> diff --git a/drivers/clk/kunit_clk_assigned_rates_u64_one.dtso b/drivers/clk/kunit_clk_assigned_rates_u64_one.dtso
> index 87041264e8f54..9b04d6927f083 100644
> --- a/drivers/clk/kunit_clk_assigned_rates_u64_one.dtso
> +++ b/drivers/clk/kunit_clk_assigned_rates_u64_one.dtso
> @@ -10,5 +10,8 @@ clk: kunit-clock {
> #clock-cells = <0>;
> assigned-clocks = <&clk>;
> assigned-clock-rates-u64 = /bits/ 64 <ASSIGNED_RATES_0_RATE>;
> + assigned-clock-sscs = <ASSIGNED_SSCS_0_MODFREQ
> + ASSIGNED_SSCS_0_SPREAD
> + ASSIGNED_SSCS_0_METHOD>;
[Severity: Low]
Similar to the multiple overlay, is this property needed in the kunit-clock
node of drivers/clk/kunit_clk_assigned_rates_u64_one.dtso for the u64 tests?
> };
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-clk-v10-v10-0-eb92484eda38@nxp.com?part=4
^ permalink raw reply
* Re: [PATCH v2 07/16] usb: hub: Power on connected M.2 E-key connectors
From: Chen-Yu Tsai @ 2026-06-12 8:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
In-Reply-To: <CAMRc=Mc3DqGb2MsvM4tjcqFuRraAO+EftO1UrtNFvR5dMRXmVA@mail.gmail.com>
On Thu, Jun 11, 2026 at 6:11 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Wed, 10 Jun 2026 10:40:41 +0200, Chen-Yu Tsai <wenst@chromium.org> said:
> > The new M.2 E-key connector can have a USB connection. For the USB device
> > on this connector to work, its power must be enabled and the W_DISABLE2#
> > signal deasserted. The connector driver handles this and provides a
> > toggle over the power sequencing API.
> >
> > This feature currently only supports a directly connected (no mux in
> > between) M.2 E-key connector. Existing USB connector types are not
> > covered. The USB A connector was recently added to the onboard devices
> > driver. USB B connectors have historically been managed by the USB
> > gadget or dual-role device controller drivers. USB C connectors are
> > handled by TCPM drivers.
> >
> > The power sequencing API does not know whether a power sequence provider
> > is not needed or not available yet, so we only request it for connectors
> > that we know need it, which at this time is just the E-key connector.
> >
> > On the USB side, the port firmware node (if present) is tied to the
> > usb_port device. This device is used to acquire the power sequencing
> > descriptor. This allows the provider to tell the different ports on one
> > hub apart.
> >
> > This feature is not implemented in the onboard USB devices driver. The
> > power sequencing API expects the consumer device to make the request,
> > but there is no device node to instantiate a platform device to tie
> > the driver to. The connector is not a child node of the USB host or
> > hub, and the graph connection is from a USB port to the connector.
> > And the connector itself already has a driver.
> >
> > Power sequencing is not directly enabled in the connector driver as
> > that would completely decouple the timing of it from the USB subsystem.
> > It would not be possible for the USB subsystem to toggle the power
> > for a power cycle or to disable the port.
> >
> > This change depends on another change to make the power sequencing
> > framework bool instead of tristate. The USB core and hub driver are
> > bool, so if the power sequencing framework is built as a module, the
> > kernel will fail to link.
> >
>
> That bit needs to go away I suppose?
Yeah, instead we need
config USB
depends on POWER_SEQUENCING && !POWER_SEQUENCING
But I ran into a dozen or so drivers that have "select USB", mostly
input devices:
config TOUCHSCREEN_USB_COMPOSITE
tristate "USB Touchscreen Driver"
depends on USB_ARCH_HAS_HCD
select USB
Kconfig complains about unmet dependencies.
> I see Andy has some suggestions but in general I like this approach much better
> than adding the pwrseq_get_index() function. Thanks!
Thanks!
ChenYu
^ permalink raw reply
* Re: [PATCH v10 6/6] clk: scmi: Add i.MX95 OEM extension support for SCMI clock driver
From: sashiko-bot @ 2026-06-12 8:58 UTC (permalink / raw)
Cc: robh, conor+dt, devicetree
In-Reply-To: <20260612-clk-v10-v10-6-eb92484eda38@nxp.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The driver fails to link when compiled as a module (`CONFIG_COMMON_CLK_SCMI=m`) because `clk-scmi.c` and `clk-scmi-oem.c` are built as separate modules without exporting their shared symbols.
- [High] Incorrect unit conversion for spread spectrum percentage causes valid spread values to be truncated to 0.
Pre-existing issues:
- [High] Missing bounds check on SCMI firmware-provided parent clock index leads to heap out-of-bounds read and wild pointer dereference.
--
commit 02412e4d55042034939e6eece844d1bd4d62d5e9
Author: Peng Fan <peng.fan@nxp.com>
clk: scmi: Add i.MX95 OEM extension support for SCMI clock driver
Introduces clk-scmi-oem.c to support vendor-specific OEM extensions for the
SCMI clock driver. This enables querying OEM-specific features and setting
spread spectrum configurations.
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 6a726331b6c9e..c2ae700ec0f2a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -98,7 +98,7 @@ obj-$(CONFIG_COMMON_CLK_RP1) += clk-rp1.o
> obj-$(CONFIG_COMMON_CLK_RPMI) += clk-rpmi.o
> obj-$(CONFIG_COMMON_CLK_HI655X) += clk-hi655x.o
> obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
> -obj-$(CONFIG_COMMON_CLK_SCMI) += clk-scmi.o
> +obj-$(CONFIG_COMMON_CLK_SCMI) += clk-scmi.o clk-scmi-oem.o
[Severity: High]
Will this fail to link when compiled as a module (CONFIG_COMMON_CLK_SCMI=m)?
It looks like Kbuild will treat clk-scmi.o and clk-scmi-oem.o as separate
kernel modules rather than linking them into a single composite module.
Since neither file exports their shared symbols (like scmi_proto_clk_ops
or scmi_clk_oem_init), won't this result in undefined reference errors?
Should this use a composite module definition instead?
scmi-clk-y := clk-scmi.o clk-scmi-oem.o
obj-$(CONFIG_COMMON_CLK_SCMI) += scmi-clk.o
[ ... ]
> diff --git a/drivers/clk/clk-scmi-oem.c b/drivers/clk/clk-scmi-oem.c
> new file mode 100644
> index 0000000000000..be11d359b4ec3
> --- /dev/null
> +++ b/drivers/clk/clk-scmi-oem.c
[ ... ]
> +static int
> +scmi_clk_imx_set_spread_spectrum(struct clk_hw *hw,
> + const struct clk_spread_spectrum *ss_conf)
> +{
> + struct scmi_clk *clk = to_scmi_clk(hw);
> + int ret;
> + u32 val;
> +
> + /*
> + * extConfigValue[7:0] - spread percentage (%)
> + * extConfigValue[23:8] - Modulation Frequency
> + * extConfigValue[24] - Enable/Disable
> + * extConfigValue[31:25] - Reserved
> + */
> + val = FIELD_PREP(SCMI_CLOCK_IMX_SS_PERCENTAGE_MASK, ss_conf->spread_bp / 10000);
[Severity: High]
Does this integer division by 10000 inadvertently truncate valid spread
spectrum values to 0?
Since ss_conf->spread_bp is in basis points (where 100 basis points equals
1%), and standard configurations usually range from 50 to 500 basis points
(0.5% to 5%), dividing by 10000 will always result in zero. Could this
divide by 100 instead to correctly convert basis points to a percentage?
[ ... ]
> diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
> index d88e78cc9a12e..2dd50c5b4ea8f 100644
> --- a/drivers/clk/clk-scmi.c
> +++ b/drivers/clk/clk-scmi.c
[ ... ]
> @@ -406,7 +419,7 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
> * to avoid sharing the devm_ allocated clk_ops between multiple
> * SCMI clk driver instances.
> */
> - scmi_ops = scmi_clk_ops_select(sclk, transport_is_atomic,
> + scmi_ops = scmi_clk_ops_select(sdev, sclk, transport_is_atomic,
> atomic_threshold_us,
> scmi_clk_ops_db,
> ARRAY_SIZE(scmi_clk_ops_db));
[Severity: High]
This is a pre-existing issue, but is it possible for the SCMI firmware to
trigger an out-of-bounds read right after this ops setup?
Looking at scmi_clocks_probe(), it uses the parent index provided by the
SCMI firmware to directly access the dynamically allocated hws array:
drivers/clk/clk-scmi.c:scmi_clocks_probe() {
...
for (int i = 0; i < sclk->info->num_parents; i++) {
sclk->parent_data[i].index = sclk->info->parents[i];
sclk->parent_data[i].hw = hws[sclk->info->parents[i]];
...
}
If the firmware provides an index greater than or equal to the total clock
count, won't this result in an out-of-bounds read on the heap, potentially
dereferencing a wild pointer? Should this index be verified against count
first?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-clk-v10-v10-0-eb92484eda38@nxp.com?part=6
^ permalink raw reply
* Re: [PATCH v2 08/16] Revert "dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP"
From: Krzysztof Kozlowski @ 2026-06-12 8:59 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-9-wenst@chromium.org>
On Wed, Jun 10, 2026 at 04:40:42PM +0800, Chen-Yu Tsai wrote:
> This reverts commit 454a1e3cd36c113341d7b71e8e691c6e47ab4a8a.
>
> mtk-xhci handles both USB 2.0 High Speed (HS) and USB 3.x SuperSpeed
> (SS) host connections. And there are USB 2.0 only mtk-xhci blocks.
> The SSUSB controller handles the device or gadget mode. Saying that
> SSUSB handles the HS portion is wrong.
>
> Fixes: 454a1e3cd36c ("dt-bindings: usb: mediatek,mtk-xhci: Add port for SuperSpeed EP")
> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 4 ----
> 1 file changed, 4 deletions(-)
Please squash both commits. Reverting just for sake of revert is
pointless. We want wrong binding to be corrected, not to be reverted.
You revert something if there is nothing to fix afterwards, IOW.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
From: Krzysztof Kozlowski @ 2026-06-12 9:02 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, linux-arm-msm, linux-kernel,
devicetree
In-Reply-To: <20260611-ipq9650_refgen-v2-2-d96a91d5b99e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:33:17PM +0530, Kathiravan Thirumoorthy wrote:
> IPQ9650 has two REFGEN blocks which provide reference current to the PCIe,
> USB and UNIPHY PHYs. Unlike other supported platforms, IPQ9650 requires the
> REFGEN clocks to be enabled explicitly.
>
> Document the IPQ9650 compatible and the required clocks for it.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
You just ignored feedback... From me and Sashiko.
So you got the same comments.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: Krzysztof Kozlowski @ 2026-06-12 9:04 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Abel Vesa
Document Qualcomm PMK7750 GPIO used with Eliza SoC. PMIC is almost the
same as PMK8550, thus compatible with it.
Cc: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v3:
1. Drop stale pmk7750 from main enum lisrt (the big one) - leftover of
previous version
Changes in v2:
1. Add fallback compatible.
---
.../bindings/pinctrl/qcom,pmic-gpio.yaml | 151 +++++++++---------
1 file changed, 78 insertions(+), 73 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index 386c31e9c52b..5ecf5da3d100 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -15,79 +15,84 @@ description:
properties:
compatible:
- items:
- - enum:
- - qcom,pm2250-gpio
- - qcom,pm660-gpio
- - qcom,pm660l-gpio
- - qcom,pm6125-gpio
- - qcom,pm6150-gpio
- - qcom,pm6150l-gpio
- - qcom,pm6350-gpio
- - qcom,pm6450-gpio
- - qcom,pm7250b-gpio
- - qcom,pm7325-gpio
- - qcom,pm7550-gpio
- - qcom,pm7550ba-gpio
- - qcom,pm8005-gpio
- - qcom,pm8018-gpio
- - qcom,pm8019-gpio
- - qcom,pm8038-gpio
- - qcom,pm8058-gpio
- - qcom,pm8150-gpio
- - qcom,pm8150b-gpio
- - qcom,pm8150l-gpio
- - qcom,pm8226-gpio
- - qcom,pm8350-gpio
- - qcom,pm8350b-gpio
- - qcom,pm8350c-gpio
- - qcom,pm8450-gpio
- - qcom,pm8550-gpio
- - qcom,pm8550b-gpio
- - qcom,pm8550ve-gpio
- - qcom,pm8550vs-gpio
- - qcom,pm8916-gpio
- - qcom,pm8917-gpio
- - qcom,pm8921-gpio
- - qcom,pm8937-gpio
- - qcom,pm8941-gpio
- - qcom,pm8950-gpio
- - qcom,pm8953-gpio
- - qcom,pm8994-gpio
- - qcom,pm8998-gpio
- - qcom,pma8084-gpio
- - qcom,pmc8180-gpio
- - qcom,pmc8180c-gpio
- - qcom,pmc8380-gpio
- - qcom,pmcx0102-gpio
- - qcom,pmd8028-gpio
- - qcom,pmh0101-gpio
- - qcom,pmh0104-gpio
- - qcom,pmh0110-gpio
- - qcom,pmi632-gpio
- - qcom,pmi8950-gpio
- - qcom,pmi8994-gpio
- - qcom,pmi8998-gpio
- - qcom,pmih0108-gpio
- - qcom,pmiv0104-gpio
- - qcom,pmk8350-gpio
- - qcom,pmk8550-gpio
- - qcom,pmk8850-gpio
- - qcom,pmm8155au-gpio
- - qcom,pmm8654au-gpio
- - qcom,pmp8074-gpio
- - qcom,pmr735a-gpio
- - qcom,pmr735b-gpio
- - qcom,pmr735d-gpio
- - qcom,pms405-gpio
- - qcom,pmx55-gpio
- - qcom,pmx65-gpio
- - qcom,pmx75-gpio
- - qcom,pmxr2230-gpio
-
- - enum:
- - qcom,spmi-gpio
- - qcom,ssbi-gpio
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm2250-gpio
+ - qcom,pm660-gpio
+ - qcom,pm660l-gpio
+ - qcom,pm6125-gpio
+ - qcom,pm6150-gpio
+ - qcom,pm6150l-gpio
+ - qcom,pm6350-gpio
+ - qcom,pm6450-gpio
+ - qcom,pm7250b-gpio
+ - qcom,pm7325-gpio
+ - qcom,pm7550-gpio
+ - qcom,pm7550ba-gpio
+ - qcom,pm8005-gpio
+ - qcom,pm8018-gpio
+ - qcom,pm8019-gpio
+ - qcom,pm8038-gpio
+ - qcom,pm8058-gpio
+ - qcom,pm8150-gpio
+ - qcom,pm8150b-gpio
+ - qcom,pm8150l-gpio
+ - qcom,pm8226-gpio
+ - qcom,pm8350-gpio
+ - qcom,pm8350b-gpio
+ - qcom,pm8350c-gpio
+ - qcom,pm8450-gpio
+ - qcom,pm8550-gpio
+ - qcom,pm8550b-gpio
+ - qcom,pm8550ve-gpio
+ - qcom,pm8550vs-gpio
+ - qcom,pm8916-gpio
+ - qcom,pm8917-gpio
+ - qcom,pm8921-gpio
+ - qcom,pm8937-gpio
+ - qcom,pm8941-gpio
+ - qcom,pm8950-gpio
+ - qcom,pm8953-gpio
+ - qcom,pm8994-gpio
+ - qcom,pm8998-gpio
+ - qcom,pma8084-gpio
+ - qcom,pmc8180-gpio
+ - qcom,pmc8180c-gpio
+ - qcom,pmc8380-gpio
+ - qcom,pmcx0102-gpio
+ - qcom,pmd8028-gpio
+ - qcom,pmh0101-gpio
+ - qcom,pmh0104-gpio
+ - qcom,pmh0110-gpio
+ - qcom,pmi632-gpio
+ - qcom,pmi8950-gpio
+ - qcom,pmi8994-gpio
+ - qcom,pmi8998-gpio
+ - qcom,pmih0108-gpio
+ - qcom,pmiv0104-gpio
+ - qcom,pmk8350-gpio
+ - qcom,pmk8550-gpio
+ - qcom,pmk8850-gpio
+ - qcom,pmm8155au-gpio
+ - qcom,pmm8654au-gpio
+ - qcom,pmp8074-gpio
+ - qcom,pmr735a-gpio
+ - qcom,pmr735b-gpio
+ - qcom,pmr735d-gpio
+ - qcom,pms405-gpio
+ - qcom,pmx55-gpio
+ - qcom,pmx65-gpio
+ - qcom,pmx75-gpio
+ - qcom,pmxr2230-gpio
+ - enum:
+ - qcom,spmi-gpio
+ - qcom,ssbi-gpio
+ - items:
+ - enum:
+ - qcom,pmk7750-gpio
+ - const: qcom,pmk8550-gpio
+ - const: qcom,spmi-gpio
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Potin Lai @ 2026-06-12 9:10 UTC (permalink / raw)
To: Conor Dooley
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss, linux-hwmon, devicetree, linux-kernel, Cosmo Chou,
Mike Hsieh, Potin Lai
In-Reply-To: <20260611-mocha-strive-a7f3265dd3f4@spud>
On Fri, Jun 12, 2026 at 1:27 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Thu, Jun 11, 2026 at 05:58:44PM +0800, Potin Lai wrote:
> > Add mutually exclusive 'ti,cl-smbus-high' and 'ti,cl-smbus-low' boolean
> > properties to configure the device's Current Limit (CL) behavior using
> > SMBus settings instead of physical pins.
> >
> > Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> > ---
> > .../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > index a20f140dc79a..95ea7c26dec2 100644
> > --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > @@ -46,6 +46,26 @@ properties:
> >
> > additionalProperties: false
> >
> > + ti,cl-smbus-high:
> > + description: |
> > + Configure the Current Limit (CL) to use the SMBus high setting.
> > + type: boolean
> > +
> > + ti,cl-smbus-low:
> > + description: |
> > + Configure the Current Limit (CL) to use the SMBus low setting.
> > + type: boolean
>
> What's smbus specific about this? If the pin was connected to a GPIO,
> you'd then need to have different properties or use these ones with an
> inaccurate name.
>
The "smbus" in the property name was originally meant to indicate
that the setting is configured via the internal register over the SMBus (I2C)
interface, rather than physical pins.
> Please also spell out "current-limit".
>
I will rename the properties to "ti,current-limit-high" and
"ti,current-limit-low"
in the next version.
Thanks,
Potin
> pw-bot: changes-requested
>
> Thanks,
> Conor.
>
> > +
> > +dependencies:
> > + ti,cl-smbus-high:
> > + not:
> > + required:
> > + - ti,cl-smbus-low
> > + ti,cl-smbus-low:
> > + not:
> > + required:
> > + - ti,cl-smbus-high
> > +
> > required:
> > - compatible
> > - reg
> >
> > --
> > 2.52.0
> >
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: iio: st,st-sensors: remove lis302dl and lis3lv02d from deprecated list
From: Krzysztof Kozlowski @ 2026-06-12 9:07 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, devicetree, jic23, robh, krzk+dt, conor+dt, linusw,
linux-kernel
In-Reply-To: <20260611154105.3727-3-shofiqtest@gmail.com>
On Thu, Jun 11, 2026 at 06:41:04PM +0300, Md Shofiqul Islam wrote:
> st,lis302dl-spi and st,lis3lv02d are being given their own binding in
> Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml. Remove
This is not supposed to be a separate commit. Removing compatible and
making it missing from schemas is not a desired change by itself.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)
From: Krzysztof Kozlowski @ 2026-06-12 9:10 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, devicetree, jic23, robh, krzk+dt, conor+dt, linusw,
linux-kernel
In-Reply-To: <20260611154105.3727-4-shofiqtest@gmail.com>
On Thu, Jun 11, 2026 at 06:41:05PM +0300, Md Shofiqul Islam wrote:
> Replace the plain text lis302.txt with a YAML schema for the
> LIS302DL/LIS3LV02D accelerometer family.
There is no "YAML schema". There is DT schema. See submitting patches
doc in DT dir.
...
> +description: |
> + WARNING: This is a legacy binding for hardware that predates modern DT
> + practices. It is documented as-found in upstream board files. Do NOT use
> + this as a template for new drivers or bindings.
> +
> + The driver lives in drivers/misc/lis3lv02d, not in IIO. Many properties
> + listed here represent run-time driver configuration that would normally not
> + appear in device tree. They are documented here only because existing
> + upstream board DTS files use them.
> +
> + Compatibles st,lis302dl-spi and st,lis3lv02d were previously listed as
> + deprecated in st,st-sensors.yaml. They are moved here with their actual
> + hardware configuration so validation works correctly.
> +
> +maintainers:
> + - Linus Walleij <linus.walleij@linaro.org>
> +
> +properties:
> + compatible:
> + oneOf:
> + - description: I2C variant (original part)
> + const: st,lis302dl
This wasn't in the old binding. You need to explain in the commit msg
changes done to the binding during conversion.
> + - description: I2C variant (larger range)
> + const: st,lis3lv02d
> + - description: SPI variant; including the bus type in the compatible
> + string is a legacy naming error, do not copy for new bindings
> + const: st,lis302dl-spi
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
From: Krzysztof Kozlowski @ 2026-06-12 9:11 UTC (permalink / raw)
To: Vikash Garodia
Cc: Bryan O'Donoghue, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-media, devicetree, linux-kernel
In-Reply-To: <20260612-shikra_vpu-v2-1-bf8727370a1e@oss.qualcomm.com>
On Fri, Jun 12, 2026 at 01:19:40AM +0530, Vikash Garodia wrote:
> Document the iris video accelerator used on shikra platforms by adding
> the qcom,shikra-iris compatible.
>
> Although QCM2290 and shikra share the same video hardware and overall
> integration, their SMMU programming differs. QCM2290 exposes separate
> stream IDs for the video hardware and the Xtensa path, requiring two
> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> and Xtensa isolation requirements, such SMR masking is not applicable on
> QCM2290 platforms.
> Since shikra uses the same video hardware as QCM2290 and shares the same
> programming model and capabilities, it is added as a fallback compatible
> to qcom,qcm2290-venus, with conditional handling to allow either one or
> two IOMMU entries.
>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,qcm2290-venus.yaml | 26 ++++++++++++++++------
> 1 file changed, 19 insertions(+), 7 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/4] iio: core: add IIO_VAL_DECIMAL64_FEMTO format type
From: Rodrigo Alencar @ 2026-06-12 9:11 UTC (permalink / raw)
To: Wadim Mueller, Jonathan Cameron, Krzysztof Kozlowski, Rob Herring,
Conor Dooley, David Lechner, Nuno Sá, Andy Shevchenko,
Maxwell Doose
Cc: linux-iio, devicetree, linux-kernel, Marcelo Schmitt,
Rodrigo Alencar
In-Reply-To: <20260611132700.671322-4-wafgo01@gmail.com>
On 11/06/26 15:26, Wadim Mueller wrote:
> Extend the IIO_VAL_DECIMAL64_* family with a femto-scaled variant
> (scale 15), following the existing MILLI/MICRO/NANO/PICO pattern. Both
> the read formatting path in __iio_format_value() and the write parsing
> path in iio_write_channel_info() (via kstrtodec64()) already derive
> their scale from "type - IIO_VAL_DECIMAL64_BASE", so the new type only
> needs to be added to the respective switch cases.
>
> This is needed by drivers reporting very small SI quantities where the
> existing pico scale loses precision. For example the Sensirion SLF3S
> liquid flow sensor reports its volume-flow scale in m^3/s, where the
> SLF3S-0600F scale is ~1.667e-12 m^3/s: at pico scale only a single
> significant digit survives, whereas femto scale preserves the full
> sensor resolution.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> ---
Reviewed-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> drivers/iio/industrialio-core.c | 2 ++
> include/linux/iio/types.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 571b8ba4e..685661cd8 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -713,6 +713,7 @@ static ssize_t __iio_format_value(char *buf, size_t offset, unsigned int type,
> case IIO_VAL_DECIMAL64_MICRO:
> case IIO_VAL_DECIMAL64_NANO:
> case IIO_VAL_DECIMAL64_PICO:
> + case IIO_VAL_DECIMAL64_FEMTO:
> {
> int scale = type - IIO_VAL_DECIMAL64_BASE;
> s64 frac;
> @@ -1030,6 +1031,7 @@ static ssize_t iio_write_channel_info(struct device *dev,
> case IIO_VAL_DECIMAL64_MICRO:
> case IIO_VAL_DECIMAL64_NANO:
> case IIO_VAL_DECIMAL64_PICO:
> + case IIO_VAL_DECIMAL64_FEMTO:
> dec_scale = type - IIO_VAL_DECIMAL64_BASE;
> fallthrough;
> case IIO_VAL_INT_64:
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 3b8a2d82f..1f2f03d5d 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -41,6 +41,7 @@ enum iio_event_info {
> #define IIO_VAL_DECIMAL64_MICRO (IIO_VAL_DECIMAL64_BASE + 6)
> #define IIO_VAL_DECIMAL64_NANO (IIO_VAL_DECIMAL64_BASE + 9)
> #define IIO_VAL_DECIMAL64_PICO (IIO_VAL_DECIMAL64_BASE + 12)
> +#define IIO_VAL_DECIMAL64_FEMTO (IIO_VAL_DECIMAL64_BASE + 15)
>
> static inline s64 iio_val_s64_compose(s32 val0, s32 val1)
> {
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v4 6/8] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Dmitry Baryshkov @ 2026-06-12 9:11 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Bartosz Golaszewski
In-Reply-To: <20260609-block-as-nvmem-v4-6-45712e6b22c6@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 09:52:31AM +0200, Loic Poulain wrote:
> Some devices store the Bluetooth BD address in non-volatile
> memory, which can be accessed through the NVMEM framework.
> Similar to Ethernet or WiFi MAC addresses, add support for
> reading the BD address from a 'local-bd-address' NVMEM cell.
>
> As with the device-tree provided BD address, add a quirk to
> indicate whether a device or platform should attempt to read
> the address from NVMEM when no valid in-chip address is present.
> Also add a quirk to indicate if the address is stored in
> big-endian byte order.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> include/net/bluetooth/hci.h | 18 ++++++++++++++++++
> net/bluetooth/hci_sync.c | 39 ++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 572b1c620c5d653a1fe10b26c1b0ba33e8f4968f..7686466d1109253b0d75edeb5f6a99fb98ce4cc6 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -164,6 +164,24 @@ enum {
> */
> HCI_QUIRK_BDADDR_PROPERTY_BROKEN,
>
> + /* When this quirk is set, the public Bluetooth address
> + * initially reported by HCI Read BD Address command
> + * is considered invalid. The public BD Address can be
> + * retrieved via a 'local-bd-address' NVMEM cell.
Why do we need a quirk here? Can't we always assume that if there is an
NVMEM cell, it contains a correct address, even if HCI command returned
a seemingly-sensible one?
> + *
> + * This quirk can be set before hci_register_dev is called or
> + * during the hdev->setup vendor callback.
> + */
> + HCI_QUIRK_USE_BDADDR_NVMEM,
> +
> + /* When this quirk is set, the Bluetooth Device Address provided by
> + * the 'local-bd-address' NVMEM is stored in big-endian order.
> + *
> + * This quirk can be set before hci_register_dev is called or
> + * during the hdev->setup vendor callback.
> + */
> + HCI_QUIRK_BDADDR_NVMEM_BE,
Also, is this necessary? Are the devices which store the address in the
wrong format in the NVMEM?
> +
> /* When this quirk is set, the duplicate filtering during
> * scanning is based on Bluetooth devices addresses. To allow
> * RSSI based updates, restart scanning if needed.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: sm8550: add SDHC4 controller node
From: Vladimir Zapolskiy @ 2026-06-12 9:11 UTC (permalink / raw)
To: William Bright
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Ram Boukobza, Tendai Makumire
In-Reply-To: <aivHs6p28uN3d6TI@will-Legion-Slim-5-16APH8>
On 6/12/26 11:47, William Bright wrote:
> On Thu, Jun 11, 2026 at 10:48:34AM +0300, Vladimir Zapolskiy wrote:
>> Looks like the SDHC driver behaves expectedly then. For me it's hard to say
>> what may be the rootcause, I believe the lower bus frequency should be fine,
>> so it sounds like a hardware issue, but could it be PCB/board specific one?
>>
>> If you find a chance to copy the SDHC driver (and its small dependencies)
>> from Android and test it on your board, and if it also fails, then it might
>> be well concluded that something is wrong with hardware, still it won't be
>> quite convincing that the SoC SDHC is to blame here.
>>
>> Hope it helps.
>>
> My colleague Tendai (<tendai.makumire@imd-tec.com>) had the same issue
> with dll-tuning failing in SDR50 when working on the downstream 5.15 msm
> kernel [1].
If Qualcomm supports their downstream Android kernel running on your
board, it should be worth to contact them.
> It does sound like a potential SI issue so I will try the following:
> - Sweeping the drive-strength values for the sdhc_4 lines to see if I
> can find a set of values that work
> - Scoping the lines to check SI when performing dll-tuning, our board
> is very dense so this is challenging.
> I am guessing this patch is only acceptable to be upstreamed once we get
> to the bottom of why dll-tuning is failing?
Apparently if Qualcomm confirms that SM8550 SDHC4 actually has this
discovered and unveiled defect, then this change will be accepted for
all SM8550 platform like you propose it to be done.
According to my experince SM8550 SDHC2 operates properly in UHS-I
SDR50/SDR104 speed modes, this can be verified on the reference boards
like HDK or QRD, and for me it sounds oddly that there is such a problem
with SDHC4.
If the proposed change as is does not enter upstream for SM8550 SoC, you
may keep it as a necessary change in your particular board .dts file.
> [1] https://github.com/imd-tec/meta-imdt-qcom/tree/kirkstone/patches/msm-kernel/files
>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 10/16] power: sequencing: pcie-m2: support matching on remote "port" node
From: Chen-Yu Tsai @ 2026-06-12 9:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ail1sAxgh5Xtkj2y@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:33 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:44PM +0800, Chen-Yu Tsai wrote:
> > A USB hub can have multiple ports, and this driver needs to
> > differentiate which port is being matched to. The USB hub driver now
> > associates the "port" node with the usb_port device, so here we can
> > use the remote "port" node to check for a match. Then fall back to
> > the remote device node for the other connection types.
>
> ...
>
> > + if (remote_port && remote_port == dev_of_node(dev))
> > + return PWRSEQ_MATCH_OK;
> > if (remote && (remote == dev_of_node(dev)))
> > return PWRSEQ_MATCH_OK;
>
> We have device_match_of_node() IIRC the name of that API.
Ack. Will also replace the existing instance.
^ permalink raw reply
* Re: [PATCH v4 7/8] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
From: Dmitry Baryshkov @ 2026-06-12 9:12 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Bartosz Golaszewski
In-Reply-To: <20260609-block-as-nvmem-v4-7-45712e6b22c6@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 09:52:32AM +0200, Loic Poulain wrote:
> When the controller BD address is invalid (zero or default),
> set the NVMEM quirks to allow retrieving the address from a
> 'local-bd-address' NVMEM cell. The BD address is often stored
> alongside the WiFi MAC address in big-endian format, so also
> set the big-endian quirk.
Okay, this answers my question to the previous patch. We need to support
BE addresses.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/bluetooth/btqca.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 6/9] clk: eyeq: Introduce a generic clock type
From: Benoît Monin @ 2026-06-12 9:12 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260604135106.867711F00893@smtp.kernel.org>
On Thursday, 4 June 2026 at 15:51:06 CEST, sashiko-bot@kernel.org wrote:
...
> [Severity: High]
> This isn't a bug introduced by this patch, but since multiple writable
> clock dividers share the same physical register (for example, div-ospi-ref
> and div-ospi-sys share the register at 0x090), can concurrent clk_set_rate()
> calls cause read-modify-write races here?
>
> Because NULL is passed as the lock parameter, the clock divider core will
> perform a lockless read-modify-write sequence. Would it be safer to provide
> a shared spinlock to protect the register state?
>
This is a fairly theoretical point. For now, the clocks are unused and not
tied to any device in the device tree on the EyeQ6H SoC. Even so, both
clocks are related to the octo-spi controller which uses the
spi-cadence-quadspi driver. In this driver, the clocks are handled by the
clk-bulk API which serialize clock accesses in lk_bulk_prepare_enable() and
clk_bulk_disable_unprepare(). And there are no calls to clk_set_rate() in
this driver.
Best regards,
--
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v8 7/9] clk: eyeq: Convert clocks declaration to eqc_clock
From: Benoît Monin @ 2026-06-12 9:12 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260604134458.F1C311F00893@smtp.kernel.org>
On Thursday, 4 June 2026 at 15:44:58 CEST, sashiko-bot@kernel.org wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but since both "div-ospi-ref" and
> "div-ospi-sys" share the same hardware register at 0x090, does this need a
> spinlock?
>
> Looking at eqc_probe_divider() in drivers/clk/clk-eyeq.c, it passes a NULL
> spinlock argument to clk_hw_register_divider_table_parent_data():
>
> drivers/clk/clk-eyeq.c:eqc_probe_divider() {
> ...
> hw = clk_hw_register_divider_table_parent_data(dev, clk->name,
> &parent_data, 0, base + clk->div.reg, clk->div.shift,
> clk->div.width, clk->div.flags, clk->div.table, NULL);
> ...
> }
>
> Will concurrent rate changes via clk_set_rate() execute unprotected
> read-modify-write cycles on this shared register and cause register corruption?
>
See my reply to the previous patch of the series.
Best regards,
--
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v8 9/9] clk: eyeq: Add EyeQ7H compatibles
From: Benoît Monin @ 2026-06-12 9:12 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260604134302.BD19F1F00893@smtp.kernel.org>
On Thursday, 4 June 2026 at 15:43:02 CEST, sashiko-bot@kernel.org wrote:
...
> [Severity: High]
> This isn't a bug introduced by this patch, but do these calculations silently
> overflow and truncate on 32-bit architectures?
>
> The variables *mult and *div are unsigned long pointers, which are 32 bits
> wide on 32-bit systems. When *div is multiplied by (1ULL << 24) and then
> by 2048 (if DOWN_SPREAD is enabled), it evaluates to ref_div * (1 << 35).
> If ref_div is 32, this becomes 1 << 40, which truncates to exactly 0.
>
> This truncated 0 is later passed to clk_hw_register_fixed_factor_pdata(),
> which can cause an immediate division-by-zero panic in the Common Clock
> Framework when clk_factor_recalc_rate() divides by fix->div.
>
This driver is specific to EyeQ SoCs, and Mobileye EyeQ SoCs are 64 bits.
So no risk of overflow here.
> > +
> > + if (!*mult || !*div)
> > + return -EINVAL;
> > +
> > + if (r2 & (JFRACR_PCSR2_RESET | JFRACR_PCSR2_DIS_SSCG)) {
> > + *acc = 0;
> > + } else {
> > + /* spread spectrum is identical to FRACG PLL */
> > + spread = FIELD_GET(JFRACR_PCSR2_SPREAD, r2);
> > + *acc = DIV_ROUND_CLOSEST(spread * 1000000000, 1024 * 2);
>
> [Severity: High]
> This is a pre-existing issue in the FRACG code duplicated here, but does
> this spread spectrum accuracy calculation overflow on 32-bit architectures?
>
> The operation spread * 1000000000 is evaluated in 32-bit math. If spread
> is greater than 4, it wraps around UINT_MAX, resulting in an incorrect
> clock accuracy.
>
Same as above. No risk of overflow on EyeQ SoCs.
> [ ... ]
>
> > @@ -339,6 +481,32 @@ static int eqc_probe_pll_fracg(struct device *dev, struct device_node *np,
> > return 0;
> > }
> >
> > +static int eqc_probe_pll_jfracr(struct device *dev, struct device_node *np,
> > + const struct eqc_clock *clk, void __iomem *base,
> > + struct clk_hw_onecell_data *cells)
> > +{
>
> [ ... ]
>
> > + hw = clk_hw_register_fixed_factor_pdata(dev, np, clk->name, &parent_data, 0, mult,
> > + div, acc, CLK_FIXED_FACTOR_FIXED_ACCURACY);
>
> [Severity: Medium]
> This isn't a new bug as it exists in the FRACG probe function as well, but
> does passing CLK_FIXED_FACTOR_FIXED_ACCURACY unconditionally override the
> parent clock accuracy when Spread Spectrum is disabled?
>
> When the DIS_SSCG bit is set, the driver calculates acc = 0. By always
> providing this flag, the Common Clock Framework treats the PLL's absolute
> accuracy as exactly 0 ppb error. This wipes out and fails to inherit the
> parent clock's natural accuracy, which could break downstream consumers
> that rely on accurate tolerance reporting.
>
The clock structure of Mobileye EyeQ SoC is such that PLLs with a spread
spectrum modulator (FRACG, JFRACR) are fed by the main oscillator, or a
fixed factor from the oscillator. So the parent clock of those PLLs has an
accuracy of 0 ppb.
> [ ... ]
>
> > @@ -411,6 +579,22 @@ static int eqc_probe(struct platform_device *pdev)
>
> [Severity: Medium]
> This is a pre-existing issue in eqc_probe(), but does the error path leak
> resources?
>
> At the end of eqc_probe(), if of_clk_add_hw_provider() fails, the function
> returns directly without unmapping the I/O memory from ioremap(), freeing
> the cells array from kzalloc_flex(), or unregistering the previously
> initialized clocks.
>
> Because the clocks are registered with clk_hw_register_fixed_factor_pdata()
> (which bypasses the devm_ auto-cleanup wrapper), failing to unregister them
> manually leaves orphaned clock objects in the system.
>
If the clock driver fails to probe, the SoC wont be functional anyway. I do
not think it is worth adding code for a code path that only leads to a dead
system when reached.
Best regards,
--
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: sashiko-bot @ 2026-06-12 9:16 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260612090426.23403-2-krzysztof.kozlowski@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing Compatible String in Conditional Block for 'qcom,pmk7750-gpio'
- [Low] Missing PMK7750 PMIC parent node in MFD bindings
--
commit 4f1189e771b6e33f2285b6ec22e2635e18bc5718
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
Document Qualcomm PMK7750 GPIO used with Eliza SoC. PMIC is almost the
same as PMK8550, thus compatible with it.
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> index 386c31e9c52b8..5ecf5da3d1000 100644
> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> @@ -15,79 +15,84 @@ description:
>
> properties:
> compatible:
[ ... ]
> + - items:
> + - enum:
> + - qcom,pmk7750-gpio
> + - const: qcom,pmk8550-gpio
> + - const: qcom,spmi-gpio
>
> reg:
> maxItems: 1
[Severity: Low]
Does the allOf conditional block for qcom,pmk8550-gpio need to be updated
to explicitly include qcom,pmk7750-gpio?
Looking at the existing conditional blocks further down in the file:
- if:
properties:
compatible:
contains:
enum:
- qcom,pm8018-gpio
- qcom,pm8019-gpio
- qcom,pm8550vs-gpio
- qcom,pmk8550-gpio
then:
Since qcom,pmk7750-gpio is compatible with qcom,pmk8550-gpio, should it also
be explicitly listed in these constraints to ensure schema validation remains
complete?
[Severity: Low]
Does the parent PMIC qcom,pmk7750 need to be added to the MFD bindings in
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml?
The MFD binding strictly enforces exactly a two-element array:
compatible:
items:
- enum:
- qcom,pm2250
...
- qcom,pmk8550
...
- const: qcom,spmi-pmic
Since qcom,pmk7750-gpio is added here, will device trees fail schema
validation for the parent PMIC node if qcom,pmk7750 is missing from the
enum in qcom,spmi-pmic.yaml?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612090426.23403-2-krzysztof.kozlowski@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v2 11/16] power: sequencing: pcie-m2: Add usb and sdio targets for E-key connector
From: Chen-Yu Tsai @ 2026-06-12 9:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ail2VcubjT7HNGUC@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:36 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:45PM +0800, Chen-Yu Tsai wrote:
> > The M.2 E-key connector allows either PCIe or SDIO for WiFi and USB or
> > UART for BT. Currently the driver only supports PCIe and UART.
> >
> > Add power sequencing targets for SDIO and USB. To avoid adding a
> > complicated dependency tree, rename the existing power sequencing units
> > "pcie" and "uart" to "wifi" and "bt". The existing target names are left
> > untouched. The new "sdio" and "usb" targets just point to the renamed
> > "wifi" and "bt" units.
>
> Why can we do that? No breakage? Only internal names? No ABI affected?
> Please, clarify all this in the commit message.
Will do.
In short, the target names (which are not modified) are used by the
consumer, while the unit names are internal only.
ChenYu
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sdm850-lenovo-yoga-c630: lower PSCI cluster idle
From: Dmitry Baryshkov @ 2026-06-12 9:25 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abel Vesa
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <10f2cd7b-4f87-4581-8065-3c140ee473c1@oss.qualcomm.com>
On Fri, May 15, 2026 at 02:15:55PM +0300, Dmitry Baryshkov wrote:
> On 15/05/2026 14:13, Konrad Dybcio wrote:
> > On 5/15/26 1:09 PM, Dmitry Baryshkov wrote:
> > > On 15/05/2026 14:03, Konrad Dybcio wrote:
> > > > On 5/15/26 1:01 PM, Dmitry Baryshkov wrote:
> > > > > On 15/05/2026 14:00, Konrad Dybcio wrote:
> > > > > > On 4/28/26 9:36 PM, Dmitry Baryshkov wrote:
> > > > > > > With the default PSCI suspend value for cluster idle state Lenovo Yoga
> > > > > > > C630 isn't stable enough. For example it might reset if display device
> > > > > > > isn't probed early enough. Drop one of the bits from the PSCI suspend
> > > > > > > value to make C630 work in stable way.
> > > > > > >
> > > > > > > Fixes: a1ade6cac5a2 ("arm64: dts: qcom: sdm845: Switch PSCI cpu idle states from PC to OSI")
> > > > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > > > > > ---
> > > > > > > arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 4 ++++
> > > > > > > 1 file changed, 4 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> > > > > > > index e41200839dbe..e6c67016552a 100644
> > > > > > > --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> > > > > > > @@ -347,6 +347,10 @@ &cdsp_pas {
> > > > > > > status = "okay";
> > > > > > > };
> > > > > > > +&cluster_sleep_0 {
> > > > > > > + arm,psci-suspend-param = <0x41003244>;
> > > > > > > +};
> > > > > >
> > > > > > Is it better if you do hack in a
> > > > > >
> > > > > > qmp_send(qmp, "{class: cx_mol, res: cx, val: mol}");
> > > > >
> > > > > Any clarification? Then I can try hacking it in.
> > > >
> > > > This will send a message to AOSS to intrusct it to prevent CX from
> > > > collapsing
> > >
> > > This sounds like a dirty hack. I think, hacking psci-suspend-param is a lesser evil.
> >
> > Yes, that dirty hack is supposed to help us understand why this is an issue
> > in the first place. Especially since it only came around at some point
> > (although I suppose you're not really happy with spending a day bisecting
> > when exactly)
>
> A similar patch has, I think, always been in any laptop tree targeting c630.
> It could having been a disablement of sync state, a removal of cluster sleep
> or something similar.
And gracious ping.... Can we sort this out somehow?
>
> >
> > > I know that we should spend time on understanding, what should vote on CX instead, but having the issue only on C630 doesn't really help. Maybe it will go away once I can sort out the gcc / dispcc / mdss issue on SDM845 & SM8150.
> >
> > If it's a "not enough votes" type issue, it can vary from device to
> > device, from unit to unit, depending on your luck in the silicon
> > lottery
> >
> > Konrad
>
>
> --
> With best wishes
> Dmitry
--
With best wishes
Dmitry
^ 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