* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: sashiko-bot @ 2026-06-11 8:06 UTC (permalink / raw)
To: Xianwei Zhao via B4 Relay
Cc: robh, conor+dt, linux-amlogic, neil.armstrong, devicetree
In-Reply-To: <20260611-gpio-to-irq-v1-1-12201716f23f@amlogic.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The newly added `hw-irq` property is not marked as required for the GPIO banks, and the example is not updated.
- [Medium] The custom device tree property `hw-irq` lacks a vendor prefix.
- [Low] The newly added `hw-irq` property lacks a description field.
--
commit 779e29b8c4c1e37224d568880fcfcc77220c1d72
Author: Xianwei Zhao <xianwei.zhao@amlogic.com>
dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
Add the hw-irq property for each GPIO bank and enable interrupt-parent
for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
> diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> --- a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
[ ... ]
> @@ -65,6 +67,9 @@ patternProperties:
> gpio-ranges:
> maxItems: 1
>
> + hw-irq:
> + $ref: /schemas/types.yaml#/definitions/uint32
[Severity: Medium]
Should this custom property have a vendor prefix to prevent namespace
collisions, such as amlogic,hw-irq?
[Severity: Low]
Would it be helpful to include a description field here to document the
purpose and semantic usage of this new property?
> +
> required:
> - reg
> - reg-names
[Severity: Medium]
The commit message indicates this property is added for each GPIO bank.
Should hw-irq be included in this required list under the
patternProperties:^gpio@[0-9a-f]+$ node to ensure incomplete configurations
fail schema validation?
Additionally, the example at the bottom of the file doesn't seem to include
this new property:
examples:
...
gpio@4240 {
reg = <0 0x4240 0 0x40>, <0 0x4000 0 0x8>;
reg-names = "gpio", "mux";
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <&periphs_pinctrl 0 8 10>;
};
Does the example section need to be updated to demonstrate the usage of the
newly added property?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-gpio-to-irq-v1-0-12201716f23f@amlogic.com?part=1
^ permalink raw reply
* Re: [PATCH 6/9] arm64: dts/media: qcom: keep PLL8 out of Purwa camss hot path
From: Konrad Dybcio @ 2026-06-11 8:04 UTC (permalink / raw)
To: Ramshouriesh, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Bryan O'Donoghue, Vinod Koul, Neil Armstrong
Cc: Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <20260610-a14-himax-hm1092-v1-6-0c9907da47ed@gmail.com>
On 6/10/26 1:09 PM, Ramshouriesh wrote:
> cam_cc_pll8 (defined in camcc-x1e80100.c) doesn't latch on Purwa
> silicon. "Lucid PLL latch failed. Output may be unstable!" fires from
> wait_for_pll() whenever something asks for a PLL8-sourced rate, and
> the camera pipeline ends up dead with "Failed to start media
> pipeline: -32" even after the qcom,x1p42100-camss compatible is in
> place.
This patch is not right, seems like you're missing the hunk to override
the compatible for purwa, the tail end of:
https://lore.kernel.org/linux-arm-msm/20260507-purwa-videocc-camcc-v5-6-fc3af4130282@oss.qualcomm.com/
diff --git a/arch/arm64/boot/dts/qcom/purwa.dtsi b/arch/arm64/boot/dts/qcom/purwa.dtsi
index 9ab4f26b35f298ad7c6c361b3e232edf07baf223..25cd547caab8fa64eb1a134068b77f5178f5c248 100644
--- a/arch/arm64/boot/dts/qcom/purwa.dtsi
+++ b/arch/arm64/boot/dts/qcom/purwa.dtsi
@@ -6,6 +6,8 @@
/* X1P42100 is heavily based on hamoa, with some meaningful differences */
#include "hamoa.dtsi"
+#include <dt-bindings/clock/qcom,x1p42100-videocc.h>
+
/delete-node/ &bwmon_cluster0;
/delete-node/ &cluster_pd2;
/delete-node/ &cpu_map_cluster2;
@@ -36,6 +38,10 @@
/delete-node/ &thermal_gpuss_6;
/delete-node/ &thermal_gpuss_7;
+&camcc {
+ compatible = "qcom,x1p42100-camcc";
+};
+
&gcc {
compatible = "qcom,x1p42100-gcc", "qcom,x1e80100-gcc";
};
Konrad
^ permalink raw reply related
* Re: [PATCH RFC 2/2] pinctrl: meson: amlogic-a4: support gpiod_to_irq
From: sashiko-bot @ 2026-06-11 8:02 UTC (permalink / raw)
To: Xianwei Zhao via B4 Relay
Cc: linux-amlogic, conor+dt, robh, devicetree, neil.armstrong
In-Reply-To: <20260611-gpio-to-irq-v1-2-12201716f23f@amlogic.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Premature `of_node_put()` in `aml_get_of_irq()` creates a dangling pointer, leading to a Use-After-Free.
--
commit 682e8ff8b51a310ddf41177d04828ab2fd8a5670
Author: Xianwei Zhao <xianwei.zhao@amlogic.com>
pinctrl: meson: amlogic-a4: support gpiod_to_irq
This patch adds the to_irq() callback implementation so that gpiod_to_irq()
can map GPIO lines to IRQs correctly.
> diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
> index 5ae0c19d007d7..663681887f35c 100644
> --- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
> +++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
[ ... ]
> @@ -836,6 +839,32 @@ static int aml_pctl_parse_functions(struct device_node *np,
> return 0;
> }
>
> +static struct device_node *aml_get_of_irq(struct device_node *np)
> +{
> + struct device_node *of_irq;
> +
> + of_irq = of_irq_find_parent(np);
> + if (of_irq && of_device_is_compatible(of_irq, "amlogic,meson-gpio-intc")) {
> + of_node_put(of_irq);
> + return of_irq;
[Severity: High]
Does this premature of_node_put() call create a use-after-free risk?
of_irq_find_parent() returns a device node with an incremented reference
count. By calling of_node_put() before returning the pointer, the reference
is dropped while the pointer is still passed back and cached in bank->of_irq.
Later, aml_gpio_to_irq() dereferences this pointer:
fwspec.fwnode = of_fwnode_handle(bank->of_irq);
If the device node is dynamically freed (for example, during Device Tree
overlay removal) between caching and use, this would lead to a
use-after-free. Should we retain the reference here until driver teardown
instead?
> + }
> +
> + if (of_irq)
> + of_node_put(of_irq);
> +
> + return NULL;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-gpio-to-irq-v1-0-12201716f23f@amlogic.com?part=2
^ permalink raw reply
* [PATCH v2] dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
From: Bhargav Joshi @ 2026-06-11 8:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Sricharan R
Cc: devicetree, linux-kernel, goledhruva, m-chawdhry, daniel.baluta,
simona.toaca, j.bhargav.u
Convert TI irq-crossbar binding from text format to DT schema.
As part of conversion following changes are made:
- Add '#interrupt-cells' as a required property which was missing in
text binding
- As irq-crossbar is interrupt-controller. Move binding from
bindings/arm/omap to bindings/interrupt-controller
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
Changes in v2:
- Dropped property name change and driver updates.
- Link to v1: https://lore.kernel.org/r/20260606-crossbar-v1-0-f67f7cb9ee50@gmail.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 55 -------------
.../interrupt-controller/ti,irq-crossbar.yaml | 96 ++++++++++++++++++++++
2 files changed, 96 insertions(+), 55 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
deleted file mode 100644
index a43e4c7aba3d..000000000000
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Some socs have a large number of interrupts requests to service
-the needs of its many peripherals and subsystems. All of the
-interrupt lines from the subsystems are not needed at the same
-time, so they have to be muxed to the irq-controller appropriately.
-In such places a interrupt controllers are preceded by an CROSSBAR
-that provides flexibility in muxing the device requests to the controller
-inputs.
-
-Required properties:
-- compatible : Should be "ti,irq-crossbar"
-- reg: Base address and the size of the crossbar registers.
-- interrupt-controller: indicates that this block is an interrupt controller.
-- ti,max-irqs: Total number of irqs available at the parent interrupt controller.
-- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
-- ti,reg-size: Size of a individual register in bytes. Every individual
- register is assumed to be of same size. Valid sizes are 1, 2, 4.
-- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
- crossbar. These interrupt lines are reserved in the soc,
- so crossbar bar driver should not consider them as free
- lines.
-
-Optional properties:
-- ti,irqs-skip: This is similar to "ti,irqs-reserved", but these are for
- SOC-specific hard-wiring of those irqs which unexpectedly bypasses the
- crossbar. These irqs have a crossbar register, but still cannot be used.
-
-- ti,irqs-safe-map: integer which maps to a safe configuration to use
- when the interrupt controller irq is unused (when not provided, default is 0)
-
-Examples:
- crossbar_mpu: crossbar@4a002a48 {
- compatible = "ti,irq-crossbar";
- reg = <0x4a002a48 0x130>;
- ti,max-irqs = <160>;
- ti,max-crossbar-sources = <400>;
- ti,reg-size = <2>;
- ti,irqs-reserved = <0 1 2 3 5 6 131 132>;
- ti,irqs-skip = <10 133 139 140>;
- };
-
-Consumer:
-========
-See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
-Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml for
-further details.
-
-An interrupt consumer on an SoC using crossbar will use:
- interrupts = <GIC_SPI request_number interrupt_level>
-
-Example:
- device_x@4a023000 {
- /* Crossbar 8 used */
- interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
- ...
- };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml
new file mode 100644
index 000000000000..ec9a33511aae
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,irq-crossbar.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,irq-crossbar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments IRQ Crossbar
+
+maintainers:
+ - Sricharan R <r.sricharan@ti.com>
+
+description:
+ Some socs have a large number of interrupts requests to service the needs of
+ its many peripherals and subsystems. All of the interrupt lines from the
+ subsystems are not needed at the same time, so they have to be muxed to the
+ irq-controller appropriately. In such places a interrupt controllers are
+ preceded by an CROSSBAR that provides flexibility in muxing the device
+ requests to the controller inputs.
+
+properties:
+ compatible:
+ const: ti,irq-crossbar
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 3
+
+ ti,max-irqs:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Total number of irqs available at the parent interrupt controller.
+ minimum: 1
+
+ ti,max-crossbar-sources:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Maximum number of crossbar sources that can be routed.
+ minimum: 1
+
+ ti,reg-size:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Size of a individual register in bytes. Every individual
+ register is assumed to be of same size.
+ enum: [1, 2, 4]
+
+ ti,irqs-reserved:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ List of the reserved irq lines that are not muxed using crossbar. These
+ interrupt lines are reserved in the soc, so crossbar bar driver should not
+ consider them as free lines.
+
+ ti,irqs-skip:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Similar to "ti,crossbar-irqs-reserved", but these are for SOC-specific
+ hard-wiring of those irqs which unexpectedly bypasses the crossbar. These
+ irqs have a crossbar register, but still cannot be used.
+
+ ti,irqs-safe-map:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ integer which maps to a safe configuration to use when the interrupt
+ controller irq is unused.
+ default: 0
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - '#interrupt-cells'
+ - ti,max-irqs
+ - ti,max-crossbar-sources
+ - ti,reg-size
+ - ti,irqs-reserved
+
+additionalProperties: false
+
+examples:
+ - |
+ crossbar@4a002a48 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ ti,max-irqs = <160>;
+ ti,max-crossbar-sources = <400>;
+ ti,reg-size = <2>;
+ ti,irqs-reserved = <0 1 2 3 5 6 131 132>;
+ ti,irqs-skip = <10 133 139 140>;
+ };
---
base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11
change-id: 20260528-crossbar-2b9a641d2146
Best regards,
--
Bhargav
^ permalink raw reply related
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Liu Ying @ 2026-06-11 8:01 UTC (permalink / raw)
To: Marek Vasut
Cc: Piyush Patle, dri-devel, imx, linux-arm-kernel, linux-clk,
devicetree, Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <7fc8f50f-7f6d-4b45-b172-a83d97164b40@mailbox.org>
On Wed, Jun 10, 2026 at 06:31:02PM +0200, Marek Vasut wrote:
> On 6/9/26 10:26 AM, Liu Ying wrote:
>
> Hello Liu,
Hello Marek,
>
> > > > > I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
> > > > > LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
> > > > > LVDS format handling, and DC enable sequencing which needed rework before
> > > > > HDMI would come up reliably on the board.
> > > > >
> > > > > I don't see a v2 of the series and things seem to have been quiet since
> > > > > November. Are you planning to post an updated version?
> > > >
> > > > My plan was to enable prefetch engine support[1] for i.MX8QXP display
> > > > controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
> > > > before adding i.MX95 display controller support.
> > > >
> > > > Unfortunately, it seems that Marek is not a big fan of [1]
> > >
> > > I am fine with [1] as long as it can be isolated and does not affect every
> > > SoC that might reuse this driver, which I think it can be done.
> >
> > How can it be isolated?
>
> if (compatible("mx8q"))
> something->prefetch_op = somefunction;
I certainly cannot add this to [1], because currently the driver only supports
i.MX8QXP display controller.
>
> And then wherever is prefetch used, do
>
> if (something->prefetch_op)
> something->prefetch_op()
These 'if' checks can be avoided, if i.MX95 display controller is supported
by a separate driver. The checks are just telling us that the i.MX8QXP and
i.MX95 display controllers are different from H/W point of view - i.MX8QXP
SoC has prefetch engines, while i.MX95 SoC has not. Of course, there are a
lot more H/W differences, hence it's worth separate drivers. Without
prefetch engines to do tile to linear resolving for framebuffers, i.MX95
display controller's DRM planes cannot advertise tile specific modifiers.
The separate driver's IOCTL designs for blit-engine could also be different,
because of the prefetch engine and no Linear Tile Store(LTS) [2] attached to
i.MX95 display controller Store unit's output. Userspace could easily check
the DRM driver names to get the IOCTLS that a particular driver supports.
[2] https://elixir.bootlin.com/linux/v7.0/source/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dc-store.yaml#L73-L76
>
> Or something along those lines ?
>
> > > > and I'm busy
> > > > with downstream development so the plan doesn't move forward well. I still
> > > > think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
> > > > so I'd like to see review comments on [1] and hopefully people think that
> > > > the overall idea of [1] is ok.
> > >
> > > My only concern is, to keep it isolated to MX8Q, so this driver can be
> > > reused by MX95.
> > >
> > > > > I've accumulated a fair amount of rework while getting this running on the
> > > > > FRDM. If you're not planning a v2, I can clean things up and send one based
> > > > > on the current series.
> > > >
> > > > I still think that i.MX95 display controller driver should be in a separate
> > > > driver, rather than sharing the same driver with i.MX8QXP display controller
> > > > like this patch series does, because the two display controllers are quite
> > > > different as I mentioned in comments on this patch series and in discussion
> > > > in [1]. Also, the common part between the two display controllers should
> > > > be extracted to a common helper library as I mentioned there too.
> > > Are they really? It seems this series adds support for the MX95 DC without
> > > that many changes, so are the DCs really that different ? It seems the MX95
> > > DC is simply a reuse/evolution of the MX8Q DC blocks, so duplicating the
> > > code seems like the wrong direction, it will only lead to disparate sets of
> > > bugs in two drivers, which isn't desired.
> >
> > I pointed out a lot of H/W differences between the two display controllers
> > during the discussions for this patch series and my i.MX8QXP prefetch engine
> > patch series[1]. Please take a look at [1], which clearly shows that the
> > prefetch engine would considerably impact CRTC/plane atomic callback
> > implementations.
>
> Is the prefetch engine actually grown into the CRTC/DE or not ? I suspect it
> is separate and instead part of the built-in DMA, right ?
It is separate and not grown into CRTC/DE.
It sits between DRAM and pixel engine's or blit engine's fetchunit.
>
> > Display controller internal blocks would also impact
> > the implementations, e.g., DomainBlend block in i.MX95 display controller
> > doesn't present in i.MX8QXP display controller. It makes sense to use
> > separate drivers for the two display controllers instead of adding 'if/else'
> > checks to a single driver's atomic callbacks or introducing two pairs of
> > atomic callbacks to that single driver. I mentioned before, the code to
> > simply add a DRM driver(struct drm_driver) is fairly limited.
>
> Can't we simply have two sets of ops (one for mx8q and one for mx95) for
> those ops which are too complicated to implement as a single op with if/else
> statements ?
Technically, we can, but using separate drivers is a better design:
- no 'if/else' checks to advertise those tile specific modifiers or not.
- better IOCTL designs for blit-engine with different DRM driver names.
- again, the code to add a DRM driver(struct drm_driver) is fairly limited.
>
> > I also mentioned before that separate drivers make them easier to maintain:
> > we don't have to test both i.MX8QXP and i.MX95 if only one display controller
> > specific code is changed.
>
> The downside is lack of code reuse, which leads to disparate sets of bugs in
> these two drivers and code duplication. And it seems to me, that large parts
> of the MX8Q and MX95 DC are effectively identical.
A common helper library achieves code reuse, so that's not a downside.
I'd say a lot of display controller internal units are identical, but H/W
differences would significantly impact driver implementations:
- i.MX95-only display controller DomainBlend unit supports 4 different modes,
which impacts plane/CRTC drivers.
- i.MX8QXP-only prefetch engine impacts plane/CRTC drivers and blit-engine
driver/IOCTLs.
- i.MX8QXP-only LTS impacts blit-engine driver/IOCTLs.
>
> > > (I might not fully understand what you have in mind with the helper library
> > > though?)
> >
> > I said this could be something like imx-ldb-helper.c and plus perhaps some
> > callbacks like fg->dc_fg_cfg_videomode().
> Do you perceive that the DC driver cannot be parametrized easily enough that
> it has to be turned into a library like that ? When I look at this patchset,
> esp. the first half which updates the various blocks, it does not seem to me
> that way.
Yes, I do perceive that. Your patchset touches mostly the identical display
controller units(DomainBlend is an exception and could impact plane/CRTC
drivers a lot) and enables kind of minimal features. That's probaly why you
feel that way. If think more about the different part, probably it will make
you feel the other way around.
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH V11 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: Andy Shevchenko @ 2026-06-11 8:00 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260610175455.19006-6-macroalpha82@gmail.com>
On Wed, Jun 10, 2026 at 12:54:49PM -0500, Chris Morgan wrote:
> Add power management support for the ICM42607 device driver.
...
> struct inv_icm42607_state {
> struct mutex lock;
> const struct inv_icm42607_hw *hw;
> struct regmap *map;
> struct regulator *vddio_supply;
> + bool vddio_en;
> struct iio_mount_matrix orientation;
> struct inv_icm42607_conf conf;
> + struct inv_icm42607_suspended suspended;
> };
When adding a new member to the data structure always consult with `pahole`
tool to see if the layout is the best fit.
...
> +/*
> + * Suspend delay assumed from other icm42600 series device, not
> + * documented in datasheet.
> + */
> +#define INV_ICM42607_SUSPEND_DELAY_MS 2000
2 * USEC_PER_MSEC
...
> + sleepval = 0;
> + if (temp && !oldtemp)
> + sleepval = max(sleepval, INV_ICM42607_TEMP_STARTUP_TIME_MS);
> +
> + if (accel != oldaccel)
> + sleepval = max(sleepval, INV_ICM42607_ACCEL_STARTUP_TIME_MS);
> +
> + if (gyro != oldgyro)
> + sleepval = max(sleepval, INV_ICM42607_GYRO_STARTUP_TIME_MS);
> +
> + if (sleep_ms)
> + *sleep_ms = sleepval;
> + else if (sleepval)
> + fsleep(sleepval * USEC_PER_MSEC);
Also good to have a _ms suffis in sleepval.
...
> + dev_set_drvdata(dev, st);
This what requires device.h. So, you can start with it whenever you first need
dev_printk.h, devres/*.h, but it doesn't mean you are supposed to drop other
non-device.h related headers, such as err.h.
...
> +EXPORT_NS_GPL_DEV_PM_OPS(inv_icm42607_pm_ops, IIO_ICM42607) = {
> + SYSTEM_SLEEP_PM_OPS(inv_icm42607_suspend, inv_icm42607_resume)
> + RUNTIME_PM_OPS(inv_icm42607_runtime_suspend,
> + inv_icm42607_runtime_resume, NULL)
Keep it logically split, either as
RUNTIME_PM_OPS(inv_icm42607_runtime_suspend, inv_icm42607_runtime_resume, NULL)
or as
RUNTIME_PM_OPS(inv_icm42607_runtime_suspend,
inv_icm42607_runtime_resume,
NULL)
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: imx94: Add Root Port node and PERST property
From: sashiko-bot @ 2026-06-11 7:59 UTC (permalink / raw)
To: hongxing.zhu; +Cc: conor+dt, imx, robh, Frank.Li, devicetree
In-Reply-To: <20260611075057.2892593-1-hongxing.zhu@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Moving `vpcie3v3aux-supply` from the Host Bridge node to the Root Port node causes the PCIe controller driver to fail to find and enable the auxiliary power supply.
--
commit 881f61760fe4035aacb7e254c5a7890c62c2bcbf
Author: Richard Zhu <hongxing.zhu@nxp.com>
arm64: dts: imx94: Add Root Port node and PERST property
This commit moves the reset-gpios property to the new Root Port node as
recommended. It also moves the vpcie3v3aux-supply properties from the Host
Bridge nodes to the newly created Root Port nodes.
> diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> --- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> @@ -1034,12 +1034,15 @@ &pcie0 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> - vpcie3v3aux-supply = <®_m2_wlan>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie0_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> + vpcie3v3aux-supply = <®_m2_wlan>;
[Severity: High]
Does moving the vpcie3v3aux-supply property here break the auxiliary power
regulator initialization for this controller?
Looking at imx_pcie_probe() in drivers/pci/controller/dwc/pci-imx6.c, the
driver retrieves the regulator directly from the host bridge device node:
imx_pcie->vpcie_aux = devm_regulator_get_optional(&pdev->dev, "vpcie3v3aux");
Since the pci-imx6 driver hasn't been updated to look for the supply in the
Root Port child node, will devm_regulator_get_optional() now fail to find it
and leave the 3.3V auxiliary regulators disabled during PCIe initialization?
> +};
> +
[ ... ]
> @@ -1058,12 +1061,15 @@ &pcie1 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> - vpcie3v3aux-supply = <®_slot_pwr>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie1_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> + vpcie3v3aux-supply = <®_slot_pwr>;
[Severity: High]
Will this similarly cause the regulator for the second PCIe controller to
remain disabled, as the pci-imx6 driver will still search the parent &pcie1
node for the vpcie3v3aux supply?
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611075057.2892593-1-hongxing.zhu@oss.nxp.com?part=1
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: r8a77965-ulcb: Enable GPU support
From: Geert Uytterhoeven @ 2026-06-11 7:55 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Frank Binns,
Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm, Matt Coster,
Maxime Ripard, Niklas Söderlund, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
In-Reply-To: <20260611005952.146825-3-marek.vasut+renesas@mailbox.org>
On Thu, 11 Jun 2026 at 03:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Enable GPU on M3NULCB with R-Car M3-N.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: renesas: r8a77965-salvator-xs: Enable GPU support
From: Geert Uytterhoeven @ 2026-06-11 7:55 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Frank Binns,
Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm, Matt Coster,
Maxime Ripard, Niklas Söderlund, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
In-Reply-To: <20260611005952.146825-2-marek.vasut+renesas@mailbox.org>
On Thu, 11 Jun 2026 at 03:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Enable GPU on Salvator-X 2nd version with R-Car M3-N.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: renesas: r8a77965-salvator-x: Enable GPU support
From: Geert Uytterhoeven @ 2026-06-11 7:55 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, David Airlie, Frank Binns,
Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm, Matt Coster,
Maxime Ripard, Niklas Söderlund, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
In-Reply-To: <20260611005952.146825-1-marek.vasut+renesas@mailbox.org>
On Thu, 11 Jun 2026 at 03:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Enable GPU on Salvator-X with R-Car M3-N.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: sashiko-bot @ 2026-06-11 7:55 UTC (permalink / raw)
To: Ziming Zhu; +Cc: conor+dt, devicetree, linux-hwmon, robh
In-Reply-To: <20260611074335.4415-2-zmzhu0630@163.com>
> 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>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611074335.4415-1-zmzhu0630@163.com?part=1
^ permalink raw reply
* [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq
From: Xianwei Zhao via B4 Relay @ 2026-06-11 7:54 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, Xianwei Zhao
Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
Add the required DT binding and implementation to support this use case.
Since this introduces a new DT property, the property is kept optional to
maintain compatibility with existing SoCs and DTS files.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Xianwei Zhao (2):
dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
pinctrl: meson: amlogic-a4: support gpiod_to_irq
.../bindings/pinctrl/amlogic,pinctrl-a4.yaml | 5 ++
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 54 ++++++++++++++++++++++
2 files changed, 59 insertions(+)
---
base-commit: 4ca496f6285e16d91751e5c84c6010e03285528c
change-id: 20260520-gpio-to-irq-be4797d2a23f
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply
* [PATCH RFC 2/2] pinctrl: meson: amlogic-a4: support gpiod_to_irq
From: Xianwei Zhao via B4 Relay @ 2026-06-11 7:54 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, Xianwei Zhao
In-Reply-To: <20260611-gpio-to-irq-v1-0-12201716f23f@amlogic.com>
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Add the to_irq() callback implementation so that
gpiod_to_irq() can map GPIO lines to IRQs correctly.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 54 ++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
index 5ae0c19d007d..663681887f35 100644
--- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
+++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
@@ -10,6 +10,7 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_irq.h>
#include <linux/of_address.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
@@ -97,6 +98,8 @@ struct aml_gpio_bank {
struct regmap *reg_gpio;
struct regmap *reg_ds;
const struct multi_mux *p_mux;
+ struct device_node *of_irq;
+ u32 irq_start;
};
struct aml_pinctrl {
@@ -836,6 +839,32 @@ static int aml_pctl_parse_functions(struct device_node *np,
return 0;
}
+static struct device_node *aml_get_of_irq(struct device_node *np)
+{
+ struct device_node *of_irq;
+
+ of_irq = of_irq_find_parent(np);
+ if (of_irq && of_device_is_compatible(of_irq, "amlogic,meson-gpio-intc")) {
+ of_node_put(of_irq);
+ return of_irq;
+ }
+
+ if (of_irq)
+ of_node_put(of_irq);
+
+ return NULL;
+}
+
+static u32 aml_bank_irq(struct device_node *np)
+{
+ u32 hw_irq;
+
+ if (of_property_read_u32(np, "hw-irq", &hw_irq))
+ return U32_MAX;
+
+ return hw_irq;
+}
+
static u32 aml_bank_pins(struct device_node *np)
{
struct of_phandle_args of_args;
@@ -1003,6 +1032,27 @@ static int aml_gpio_get(struct gpio_chip *chip, unsigned int gpio)
return !!(val & BIT(bit));
}
+static int aml_gpio_to_irq(struct gpio_chip *chip, unsigned int gpio)
+{
+ struct aml_gpio_bank *bank = gpiochip_get_data(chip);
+ struct irq_fwspec fwspec;
+ int hwirq;
+
+ if (bank->irq_start == U32_MAX)
+ return -EINVAL;
+ if (!bank->of_irq)
+ return -EINVAL;
+
+ hwirq = gpio + bank->irq_start;
+
+ fwspec.fwnode = of_fwnode_handle(bank->of_irq);
+ fwspec.param_count = 2;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = IRQ_TYPE_NONE;
+
+ return irq_create_fwspec_mapping(&fwspec);
+}
+
static const struct gpio_chip aml_gpio_template = {
.request = gpiochip_generic_request,
.free = gpiochip_generic_free,
@@ -1012,6 +1062,7 @@ static const struct gpio_chip aml_gpio_template = {
.direction_input = aml_gpio_direction_input,
.direction_output = aml_gpio_direction_output,
.get_direction = aml_gpio_get_direction,
+ .to_irq = aml_gpio_to_irq,
.can_sleep = true,
};
@@ -1079,6 +1130,7 @@ static int aml_gpiolib_register_bank(struct aml_pinctrl *info,
bank->reg_ds = bank->reg_gpio;
}
+ bank->irq_start = aml_bank_irq(np);
bank->gpio_chip = aml_gpio_template;
bank->gpio_chip.base = -1;
bank->gpio_chip.ngpio = aml_bank_pins(np);
@@ -1154,6 +1206,8 @@ static int aml_pctl_probe_dt(struct platform_device *pdev,
pdesc->name = pin_names[j];
pdesc++;
}
+
+ info->banks[bank].of_irq = aml_get_of_irq(np);
bank++;
} else {
ret = aml_pctl_parse_functions(child, info,
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Xianwei Zhao via B4 Relay @ 2026-06-11 7:54 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, Xianwei Zhao
In-Reply-To: <20260611-gpio-to-irq-v1-0-12201716f23f@amlogic.com>
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Add the hw-irq property for each GPIO bank and enable interrupt-parent
for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
index b69db1b95345..65ec9121300e 100644
--- a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
@@ -37,6 +37,8 @@ properties:
ranges: true
+ interrupt-parent: true
+
patternProperties:
"^gpio@[0-9a-f]+$":
type: object
@@ -65,6 +67,9 @@ patternProperties:
gpio-ranges:
maxItems: 1
+ hw-irq:
+ $ref: /schemas/types.yaml#/definitions/uint32
+
required:
- reg
- reg-names
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v3 2/3] hwmon: pmbus: Add support for Silergy SQ24860
From: sashiko-bot @ 2026-06-11 7:54 UTC (permalink / raw)
To: Ziming Zhu; +Cc: robh, linux-hwmon, conor+dt, devicetree
In-Reply-To: <20260611074335.4415-3-zmzhu0630@163.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing signedness check on PMBus limits causes negative inputs to silently set maximum hardware limits.
- [Medium] Returns -EINVAL instead of clamping for out-of-bounds lower limits in PMBUS_IIN_OC_FAULT_LIMIT.
--
commit 1edf6322da1b629fce9b16a96496a18863aacef8
Author: Ziming Zhu <ziming.zhu@silergycorp.com>
hwmon: pmbus: Add support for Silergy SQ24860
Add PMBus hwmon support for the Silergy SQ24860 eFuse. The driver reports
voltage, current, power, and temperature, along with history attributes
and over-current fault limits.
> diff --git a/drivers/hwmon/pmbus/sq24860.c b/drivers/hwmon/pmbus/sq24860.c
> new file mode 100644
> index 0000000000000..f16f650ff7ba2
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/sq24860.c
[ ... ]
> +static int sq24860_write_word_data(struct i2c_client *client,
> + int page, int reg, u16 value)
> +{
> + int ret;
> +
> + switch (reg) {
> + case PMBUS_VIN_UV_WARN_LIMIT:
> + case PMBUS_VIN_UV_FAULT_LIMIT:
> + case PMBUS_VIN_OV_WARN_LIMIT:
> + case PMBUS_VIN_OV_FAULT_LIMIT:
> + case PMBUS_VOUT_UV_WARN_LIMIT:
> + case PMBUS_IIN_OC_WARN_LIMIT:
> + case PMBUS_OT_WARN_LIMIT:
> + case PMBUS_OT_FAULT_LIMIT:
> + case PMBUS_PIN_OP_WARN_LIMIT:
> + value >>= SQ24860_8B_SHIFT;
> + value = clamp_val(value, 0, 0xff);
[Severity: High]
Does this handle negative user inputs correctly?
The PMBus core converts limit values into 16-bit 2's complement integers
(s16), but passes them as u16 to sq24860_write_word_data(). Because this
driver treats value as an unsigned u16, a negative user limit written via
sysfs will become a large positive value (e.g., 0xFFFF).
When this large value is logically right-shifted and clamped here, it
results in setting the maximum possible hardware limit (0xff) instead of
clamping to the minimum limit (0).
> + ret = pmbus_write_word_data(client, page, reg, value);
> + break;
> +
> + case PMBUS_IIN_OC_FAULT_LIMIT:
> + if (value < SQ24860_IIN_OCF_OFF)
> + return -EINVAL;
[Severity: High]
Could a negative user limit bypass this bounds check?
Since value is unsigned, a negative limit (e.g., 0xFFFF) will evaluate
as greater than SQ24860_IIN_OCF_OFF (165). This bypasses the check below
and overflows the 32-bit unsigned calculation, effectively disabling
over-current protection by incorrectly setting the hardware limit to its
maximum.
[Severity: Medium]
Should this clamp the value instead of returning an error?
The hwmon sysfs ABI convention requires drivers to silently clamp
out-of-range user limits to the nearest supported hardware value rather
than returning an error.
If the requested limit translates to a value below SQ24860_IIN_OCF_OFF,
returning -EINVAL violates this convention. Would it be better to clamp
the limit to SQ24860_IIN_OCF_OFF so the underlying register is set to 0?
> + value -= SQ24860_IIN_OCF_OFF;
> + value = DIV_ROUND_CLOSEST(((unsigned int)value) * SQ24860_IIN_OCF_DIV,
> + SQ24860_IIN_OCF_NUM);
> + value = clamp_val(value, 0, 0x3f);
> + ret = pmbus_write_byte_data(client, page, SQ24860_VIREF, value);
> + break;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611074335.4415-1-zmzhu0630@163.com?part=2
^ permalink raw reply
* Re: [PATCH v8 1/3] dt-bindings: timer: mips,p8700-gcru
From: Krzysztof Kozlowski @ 2026-06-11 7:50 UTC (permalink / raw)
To: Aleksa Paunovic
Cc: alex@ghiti.fr, aou@eecs.berkeley.edu, cfu@mips.com,
conor+dt@kernel.org, conor.dooley@microchip.com,
daniel.lezcano@linaro.org, devicetree@vger.kernel.org,
Djordje Todorovic, jstultz@google.com, krzk+dt@kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
palmer@dabbelt.com, paul.walmsley@sifive.com, pjw@kernel.org,
robh@kernel.org, sboyd@kernel.org, tglx@linutronix.de,
wangruikang@iscas.ac.cn
In-Reply-To: <ed1e9743-1a8c-409f-9cf7-391719ea68fb@htecgroup.com>
On 11/06/2026 09:39, Aleksa Paunovic wrote:
> Hi Krzysztof,
>
>
> On 6/11/26 08:54, Krzysztof Kozlowski wrote:
>> On 11/06/2026 08:51, Krzysztof Kozlowski wrote:
>>> On 10/06/2026 10:22, Aleksa Paunovic via B4 Relay wrote:
>>>> From: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
>>>>
>>>> Add dt-bindings for the GCR.U memory mapped timer device for RISC-V
>>>> platforms. The GCR.U memory region contains shadow copies of the RISC-V
>>>> mtime register and the hrtime Global Configuration Register.
>>>>
>>>> Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
>>> You keep ignoring reviews you received (14th May!) and sending same mistake.
>>>
>>> Can you address the emails?
> I wasn't really sure what the etiquette was for replying to Sashiko reviews, so I decided to
> address the comments for other patches and send a v8 without replying.
>
> As for this patch, the GCR.U itself does start at 0x7F000, but the first
> actual register (mtime) is at 0x7F050 [1].
> I'm not seeing any warnings when running dt_binding_check.
It's still a warning which you can easily reproduce on W=1 on dts. You
CANNOT have mismatch. If block starts at 0x7f000, first register CANNOT
start at different address or it completely does not matter where the
register is. It's contradictory. The block start address defines
where... does it start.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] hwmon: Add documentation for SQ24860
From: sashiko-bot @ 2026-06-11 7:50 UTC (permalink / raw)
To: Ziming Zhu; +Cc: robh, conor+dt, linux-hwmon, devicetree
In-Reply-To: <20260611074335.4415-4-zmzhu0630@163.com>
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Document the supported sysfs attributes for the Silergy SQ24860 PMBus
> hwmon driver.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611074335.4415-1-zmzhu0630@163.com?part=3
^ permalink raw reply
* Re: [PATCH V11 4/9] iio: imu: inv_icm42607: Add I2C and SPI For icm42607
From: Andy Shevchenko @ 2026-06-11 7:49 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260610175455.19006-5-macroalpha82@gmail.com>
On Wed, Jun 10, 2026 at 12:54:48PM -0500, Chris Morgan wrote:
> Add I2C and SPI driver support for InvenSense ICM-42607 devices.
> Add necessary Kconfig and Makefile to allow building of (incomplete)
> driver.
...
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/Makefile | 1 +
> drivers/iio/imu/inv_icm42607/Kconfig | 30 +++++
> drivers/iio/imu/inv_icm42607/Makefile | 10 ++
These should be part of the previous patch.
...
> +config INV_ICM42607
> + tristate
To make it compilable w.o. SPI/I2C make this as
tristate "Inven... Core driver" if COMPILE_TEST
> + select IIO_BUFFER
> + select IIO_INV_SENSORS_TIMESTAMP
...
> +obj-$(CONFIG_INV_ICM42607_I2C) += inv-icm42607-i2c.o
> +inv-icm42607-i2c-y += inv_icm42607_i2c.o
> +
> +obj-$(CONFIG_INV_ICM42607_SPI) += inv-icm42607-spi.o
> +inv-icm42607-spi-y += inv_icm42607_spi.o
Add each of them in a separate patch.
...
> +#include <linux/device.h>
Why?
And a lot of missing headers (bitfield.h, dev_printk.h, mod_devicetable.h, err.h)
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
...
> +static int inv_icm42607_probe(struct i2c_client *client)
> +{
> + const struct inv_icm42607_hw *hw;
> + struct regmap *regmap;
> +
> + hw = i2c_get_match_data(client);
> + if (!hw)
> + return dev_err_probe(&client->dev, -ENODEV,
> + "Failed to get i2c data\n");
Add
struct device *dev = &client->dev;
and modify this and other eligible pieces accordingly.
return dev_err_probe(dev, -ENODEV, "Failed to get i2c data\n");
> + regmap = devm_regmap_init_i2c(client, &inv_icm42607_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(&client->dev, PTR_ERR(regmap),
> + "Failed to register i2c regmap %ld\n",
Do not duplicate a printing of an error code.
> + PTR_ERR(regmap));
return dev_err_probe(dev, PTR_ERR(regmap),
"Failed to register i2c regmap\n");
> + return inv_icm42607_core_probe(regmap, hw, inv_icm42607_i2c_bus_setup);
> +}
> +
...
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
As per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 26/37] arm64: dts: qcom: sc8180x: Move PCIe phy and GPIOs to root port node
From: Konrad Dybcio @ 2026-06-11 7:49 UTC (permalink / raw)
To: Krishna Chaitanya Chundru, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, cros-qcom-dts-watchers,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru
In-Reply-To: <20260611-wake-v2-26-2744251b1181@oss.qualcomm.com>
On 6/11/26 6:59 AM, Krishna Chaitanya Chundru wrote:
> The PCIe phy reference and the perst/wake GPIO properties are
> per root port and belong in the root port node (pcie@0), not in the
> RC controller node. Move phys and phy-names from the controller to
> pcie0_port0, pcie1_port0, pcie2_port0, and pcie3_port0, adding
> labels to these nodes to allow board-level overrides. Move
> perst-gpios/wake-gpios from the controller overrides to the
> respective port nodes in the board files, renaming perst-gpios to
> reset-gpios to match the binding used in the root port context.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com>
> ---
[...]
> @@ -1779,13 +1779,11 @@ pcie0: pcie@1c00000 {
> <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_PCIE_0 0>;
> interconnect-names = "pcie-mem", "cpu-pcie";
>
> - phys = <&pcie0_phy>;
> - phy-names = "pciephy";
> dma-coherent;
>
> status = "disabled";
>
> - pcie@0 {
> + pcie0_port0: pcie@0 {
> device_type = "pci";
> reg = <0x0 0x0 0x0 0x0 0x0>;
> bus-range = <0x01 0xff>;
> @@ -1793,6 +1791,8 @@ pcie@0 {
> #address-cells = <3>;
> #size-cells = <2>;
> ranges;
> +
> + phys = <&pcie0_phy>;
Other DTs put this between bus-range and address-cells, e.g. hamoa:
pcie3_port0: pcie@0 {
device_type = "pci";
compatible = "pciclass,0604";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
phys = <&pcie3_phy>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
};
Please follow this style
Konrad
^ permalink raw reply
* [PATCH v3] arm64: dts: imx94: Add Root Port node and PERST property
From: hongxing.zhu @ 2026-06-11 7:50 UTC (permalink / raw)
To: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
From: Richard Zhu <hongxing.zhu@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
arch/arm64/boot/dts/freescale/imx943-evk.dts | 14 ++++++++++----
arch/arm64/boot/dts/freescale/imx943.dtsi | 11 +++++++++++
3 files changed, 32 insertions(+), 4 deletions(-)
---
Changes in v3:
- Move the regulator to Root Port node as well, since [2] had been
settled.
- Collect Reviewed-by tag issued by Sherry.
Changes in v2:
- Delete reset-gpio properties in PCIe bridge node.
- Correct the "reset-gpio" property to "reset-gpios".
Since the patch-set [1] issued by Sherry had been landed. Add according changes on i.MX943 board too.
[1] https://lkml.org/lkml/2026/6/1/1461
[2] https://lore.kernel.org/imx/20260520084904.2424253-1-sherry.sun@oss.nxp.com/
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index 1f9035e6cf159..dfbb73603cb24 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1411,6 +1411,17 @@ pcie0: pcie@4c300000 {
power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@4c300000 {
diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
index 7cfd424689507..674410e541cba 100644
--- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
@@ -1034,12 +1034,15 @@ &pcie0 {
<&pcie_ref_clk>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
"ref", "extref";
- reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
- vpcie3v3aux-supply = <®_m2_wlan>;
supports-clkreq;
status = "okay";
};
+&pcie0_port0 {
+ reset-gpios = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
+ vpcie3v3aux-supply = <®_m2_wlan>;
+};
+
&pcie0_ep {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
@@ -1058,12 +1061,15 @@ &pcie1 {
<&pcie_ref_clk>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
"ref", "extref";
- reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
- vpcie3v3aux-supply = <®_slot_pwr>;
supports-clkreq;
status = "okay";
};
+&pcie1_port0 {
+ reset-gpios = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
+ vpcie3v3aux-supply = <®_slot_pwr>;
+};
+
&pcie1_ep {
pinctrl-0 = <&pinctrl_pcie1>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx943.dtsi b/arch/arm64/boot/dts/freescale/imx943.dtsi
index cf5b3dbb47ff7..01152fd0efa5e 100644
--- a/arch/arm64/boot/dts/freescale/imx943.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx943.dtsi
@@ -255,6 +255,17 @@ pcie1: pcie@4c380000 {
power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie1_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie1_ep: pcie-ep@4c380000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: qcom: sm8550: add SDHC4 controller node
From: Vladimir Zapolskiy @ 2026-06-11 7:48 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: <aik1ZYUT-cnpfdQn@will-Legion-Slim-5-16APH8>
On 6/10/26 12:59, William Bright wrote:
> On Wed, Jun 10, 2026 at 11:21:53AM +0300, Vladimir Zapolskiy wrote:
>> FWIW due to https://www.nxp.com/docs/en/data-sheet/IW416.pdf "10.7.1 VIO_SD
>> DC characteristics" SDR104 speed mode is not supported by the module, thus
>> the selection of the SDR50 speed mode on the host side sounds to be correct
>> in your case.
>>
>> In SDR50 speed mode gcc_sdcc4_apps_clk clock frequency should be exactly
>> 100MHz, and since it differs, it has an impact during the tuning phase.
>>
>> Definitely clk/qcom/gcc-sm8550.c says that the maximum supported frequency
>> is 75MHz, the same is found in the downstream v5.15 kernel:
>>
>> static const struct freq_tbl ftbl_gcc_sdcc4_apps_clk_src[] = {
>> F(400000, P_BI_TCXO, 12, 1, 4),
>> F(25000000, P_GCC_GPLL0_OUT_EVEN, 12, 0, 0),
>> F(37500000, P_GCC_GPLL0_OUT_EVEN, 8, 0, 0),
>> F(75000000, P_GCC_GPLL0_OUT_EVEN, 4, 0, 0),
>> { }
>> };
>>
>> Can you dump CAPS1 register value of SM8550 SDHC4? What does it say about
>> SDR50 mode support and need for SDR50 mode tuning?
>>
>> --
>> Best wishes,
>> Vladimir
> CAPS0 and CAPS1 are below:
> sdhci_msm 8844000.mmc: CAPS0: 0x3029c8b2 CAPS1: 0x0000a08b
> For CAPS1:
> Bit 0 (SDR50 support) = 1
> Bit 13 (Use Tuning for SDR50) = 1
> It looks to report that SDR50 is supported with tuning required.
>
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.
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 23/37] arm64: dts: qcom: sa8295p: Move PCIe GPIOs to root port node
From: Konrad Dybcio @ 2026-06-11 7:48 UTC (permalink / raw)
To: Krishna Chaitanya Chundru, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, cros-qcom-dts-watchers,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
Krishna Chaitanya Chundru
In-Reply-To: <20260611-wake-v2-23-2744251b1181@oss.qualcomm.com>
On 6/11/26 6:58 AM, Krishna Chaitanya Chundru wrote:
> The perst/wake GPIO properties are per root port and belong in the
> root port node, not in the RC controller node. Move perst-gpios/
> wake-gpios from the &pcie2a, &pcie3a, &pcie3b, and &pcie4 controller
> overrides to the respective &pcie2a_port0, &pcie3a_port0,
> &pcie3b_port0, and &pcie4_port0 nodes, renaming perst-gpios to
> reset-gpios to match the binding used in the root port context.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chaitanya.chundru@oss.qualcomm.com>
> ---
The other 8280 SKUs should also be converted (and the phys reference
moved to the port node) - sa8540, sa8295 and sc8280 - they can be
done in a single commit
On a sidenote, extending the scope of your series looks "odd" (mildly
related changes) and may delay it getting merged (perhaps not now since
we're at rc7 so no more merging for some 3-4 weeks..) as the new pieces
may spark lots of review comments
Konrad
^ permalink raw reply
* [PATCH v3 2/3] hwmon: pmbus: Add support for Silergy SQ24860
From: Ziming Zhu @ 2026-06-11 7:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260611074335.4415-1-zmzhu0630@163.com>
From: Ziming Zhu <ziming.zhu@silergycorp.com>
Add PMBus hwmon support for the Silergy SQ24860 eFuse.
The driver reports input voltage, output voltage, auxiliary voltage,
input current, input power, and temperature. It also exposes peak,
average, and minimum history attributes, sample count configuration,
and maps the manufacturer-specific VIREF register to the generic input
over-current fault limit attribute.
The IMON resistor value is read from the silergy,rimon-micro-ohms device
property and used to configure the input current calibration gain.
Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
---
drivers/hwmon/pmbus/Kconfig | 19 ++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/sq24860.c | 430 ++++++++++++++++++++++++++++++++++
3 files changed, 450 insertions(+)
create mode 100644 drivers/hwmon/pmbus/sq24860.c
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 8f4bff375ecb..a905b5af137c 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -612,6 +612,25 @@ config SENSORS_STEF48H28
This driver can also be built as a module. If so, the module will
be called stef48h28.
+config SENSORS_SQ24860
+ tristate "Silergy SQ24860"
+ help
+ If you say yes here you get hardware monitoring support for Silergy
+ SQ24860 eFuse.
+
+ This driver can also be built as a module. If so, the module will
+ be called sq24860.
+
+config SENSORS_SQ24860_REGULATOR
+ bool "Regulator support for SQ24860"
+ depends on SENSORS_SQ24860 && REGULATOR
+ default SENSORS_SQ24860
+ help
+ If you say yes here you get regulator support for Silergy SQ24860.
+ The regulator is registered through the PMBus regulator framework and
+ can be used to control the output exposed by the device.
+ This option is only useful if regulator framework support is needed.
+
config SENSORS_STPDDC60
tristate "ST STPDDC60"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 7129b62bc00f..86bc93c6c091 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_SENSORS_PM6764TR) += pm6764tr.o
obj-$(CONFIG_SENSORS_PXE1610) += pxe1610.o
obj-$(CONFIG_SENSORS_Q54SJ108A2) += q54sj108a2.o
obj-$(CONFIG_SENSORS_STEF48H28) += stef48h28.o
+obj-$(CONFIG_SENSORS_SQ24860) += sq24860.o
obj-$(CONFIG_SENSORS_STPDDC60) += stpddc60.o
obj-$(CONFIG_SENSORS_TDA38640) += tda38640.o
obj-$(CONFIG_SENSORS_TPS25990) += tps25990.o
diff --git a/drivers/hwmon/pmbus/sq24860.c b/drivers/hwmon/pmbus/sq24860.c
new file mode 100644
index 000000000000..f16f650ff7ba
--- /dev/null
+++ b/drivers/hwmon/pmbus/sq24860.c
@@ -0,0 +1,430 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Author: Ziming Zhu <ziming.zhu@silergycorp.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/math64.h>
+
+#include "pmbus.h"
+
+#define SQ24860_IIN_CAL_GAIN 0x38
+#define SQ24860_READ_VAUX 0xd0
+#define SQ24860_READ_VIN_MIN 0xd1
+#define SQ24860_READ_VIN_PEAK 0xd2
+#define SQ24860_READ_IIN_PEAK 0xd4
+#define SQ24860_READ_PIN_PEAK 0xd5
+#define SQ24860_READ_TEMP_AVG 0xd6
+#define SQ24860_READ_TEMP_PEAK 0xd7
+#define SQ24860_READ_VOUT_MIN 0xda
+#define SQ24860_READ_VIN_AVG 0xdc
+#define SQ24860_READ_VOUT_AVG 0xdd
+#define SQ24860_READ_IIN_AVG 0xde
+#define SQ24860_READ_PIN_AVG 0xdf
+#define SQ24860_VIREF 0xe0
+#define SQ24860_PK_MIN_AVG 0xea
+#define PK_MIN_AVG_RST_PEAK BIT(7)
+#define PK_MIN_AVG_RST_AVG BIT(6)
+#define PK_MIN_AVG_RST_MIN BIT(5)
+#define PK_MIN_AVG_AVG_CNT GENMASK(2, 0)
+#define SQ24860_MFR_WRITE_PROTECT 0xf8
+#define SQ24860_UNLOCKED BIT(7)
+
+#define SQ24860_8B_SHIFT 2
+#define SQ24860_IIN_OCF_NUM 1000000
+#define SQ24860_IIN_OCF_DIV 129278
+#define SQ24860_IIN_OCF_OFF 165
+
+#define PK_MIN_AVG_RST_MASK (PK_MIN_AVG_RST_PEAK | \
+ PK_MIN_AVG_RST_AVG | \
+ PK_MIN_AVG_RST_MIN)
+#define SQ24860_MAX_SAMPLES BIT(FIELD_MAX(PK_MIN_AVG_AVG_CNT))
+/*
+ * Arbitrary default Rimon value: 1.6kOhm
+ */
+#define SQ24860_DEFAULT_RIMON 1600000000
+#define SQ24860_GIMON 18180
+
+#define SQ24860_VAUX_DIV 20
+
+static int sq24860_write_iin_cal_gain(struct i2c_client *client, u32 rimon)
+{
+ u64 temp = 6400ULL * 1000000000ULL * 1000ULL;
+ u64 denom;
+ u64 word;
+
+ if (!rimon)
+ return -EINVAL;
+
+ denom = (u64)rimon * SQ24860_GIMON;
+ word = div64_u64(temp, denom);
+ if (!word || word > U16_MAX)
+ return -EINVAL;
+
+ return i2c_smbus_write_word_data(client, SQ24860_IIN_CAL_GAIN,
+ (u16)word);
+}
+
+static int sq24860_mfr_write_protect_set(struct i2c_client *client,
+ u8 protect)
+{
+ u8 val;
+
+ switch (protect) {
+ case 0:
+ val = 0xa2;
+ break;
+ case PB_WP_ALL:
+ val = 0x0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return pmbus_write_byte_data(client, -1, SQ24860_MFR_WRITE_PROTECT,
+ val);
+}
+
+static int sq24860_mfr_write_protect_get(struct i2c_client *client)
+{
+ int ret = pmbus_read_byte_data(client, -1, SQ24860_MFR_WRITE_PROTECT);
+
+ if (ret < 0)
+ return ret;
+
+ return (ret & SQ24860_UNLOCKED) ? 0 : PB_WP_ALL;
+}
+
+static int sq24860_read_word_data(struct i2c_client *client,
+ int page, int phase, int reg)
+{
+ int ret;
+
+ switch (reg) {
+ case PMBUS_VIRT_READ_VIN_MAX:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_VIN_PEAK);
+ break;
+
+ case PMBUS_VIRT_READ_VIN_MIN:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_VIN_MIN);
+ break;
+
+ case PMBUS_VIRT_READ_VIN_AVG:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_VIN_AVG);
+ break;
+
+ case PMBUS_VIRT_READ_VOUT_MIN:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_VOUT_MIN);
+ break;
+
+ case PMBUS_VIRT_READ_VOUT_AVG:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_VOUT_AVG);
+ break;
+
+ case PMBUS_VIRT_READ_IIN_AVG:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_IIN_AVG);
+ break;
+
+ case PMBUS_VIRT_READ_IIN_MAX:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_IIN_PEAK);
+ break;
+
+ case PMBUS_VIRT_READ_TEMP_AVG:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_TEMP_AVG);
+ break;
+
+ case PMBUS_VIRT_READ_TEMP_MAX:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_TEMP_PEAK);
+ break;
+
+ case PMBUS_VIRT_READ_PIN_AVG:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_PIN_AVG);
+ break;
+
+ case PMBUS_VIRT_READ_PIN_MAX:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_PIN_PEAK);
+ break;
+
+ case PMBUS_VIRT_READ_VMON:
+ ret = pmbus_read_word_data(client, page, phase,
+ SQ24860_READ_VAUX);
+ if (ret < 0)
+ break;
+ ret = DIV_ROUND_CLOSEST(ret, SQ24860_VAUX_DIV);
+ break;
+
+ case PMBUS_VIN_UV_WARN_LIMIT:
+ case PMBUS_VIN_UV_FAULT_LIMIT:
+ case PMBUS_VIN_OV_WARN_LIMIT:
+ case PMBUS_VIN_OV_FAULT_LIMIT:
+ case PMBUS_VOUT_UV_WARN_LIMIT:
+ case PMBUS_IIN_OC_WARN_LIMIT:
+ case PMBUS_OT_WARN_LIMIT:
+ case PMBUS_OT_FAULT_LIMIT:
+ case PMBUS_PIN_OP_WARN_LIMIT:
+ /*
+ * These registers provide an 8 bits value instead of a
+ * 10bits one. Just shifting twice the register value is
+ * enough to make the sensor type conversion work, even
+ * if the datasheet provides different m, b and R for
+ * those.
+ */
+ ret = pmbus_read_word_data(client, page, phase, reg);
+ if (ret < 0)
+ break;
+ ret <<= SQ24860_8B_SHIFT;
+ break;
+
+ case PMBUS_IIN_OC_FAULT_LIMIT:
+ /*
+ * VIREF directly sets the over-current limit at which the eFuse
+ * will turn the FET off and trigger a fault. Expose it through
+ * this generic property instead of a manufacturer specific one.
+ */
+ ret = pmbus_read_byte_data(client, page, SQ24860_VIREF);
+ if (ret < 0)
+ break;
+ ret = DIV_ROUND_CLOSEST(ret * SQ24860_IIN_OCF_NUM,
+ SQ24860_IIN_OCF_DIV);
+ ret += SQ24860_IIN_OCF_OFF;
+ break;
+
+ case PMBUS_VIRT_SAMPLES:
+ ret = pmbus_read_byte_data(client, page, SQ24860_PK_MIN_AVG);
+ if (ret < 0)
+ break;
+ ret = BIT(FIELD_GET(PK_MIN_AVG_AVG_CNT, ret));
+ break;
+
+ case PMBUS_VIRT_RESET_TEMP_HISTORY:
+ case PMBUS_VIRT_RESET_VIN_HISTORY:
+ case PMBUS_VIRT_RESET_IIN_HISTORY:
+ case PMBUS_VIRT_RESET_PIN_HISTORY:
+ case PMBUS_VIRT_RESET_VOUT_HISTORY:
+ ret = 0;
+ break;
+
+ default:
+ ret = -ENODATA;
+ break;
+ }
+
+ return ret;
+}
+
+static int sq24860_write_word_data(struct i2c_client *client,
+ int page, int reg, u16 value)
+{
+ int ret;
+
+ switch (reg) {
+ case PMBUS_VIN_UV_WARN_LIMIT:
+ case PMBUS_VIN_UV_FAULT_LIMIT:
+ case PMBUS_VIN_OV_WARN_LIMIT:
+ case PMBUS_VIN_OV_FAULT_LIMIT:
+ case PMBUS_VOUT_UV_WARN_LIMIT:
+ case PMBUS_IIN_OC_WARN_LIMIT:
+ case PMBUS_OT_WARN_LIMIT:
+ case PMBUS_OT_FAULT_LIMIT:
+ case PMBUS_PIN_OP_WARN_LIMIT:
+ value >>= SQ24860_8B_SHIFT;
+ value = clamp_val(value, 0, 0xff);
+ ret = pmbus_write_word_data(client, page, reg, value);
+ break;
+
+ case PMBUS_IIN_OC_FAULT_LIMIT:
+ if (value < SQ24860_IIN_OCF_OFF)
+ return -EINVAL;
+ value -= SQ24860_IIN_OCF_OFF;
+ value = DIV_ROUND_CLOSEST(((unsigned int)value) * SQ24860_IIN_OCF_DIV,
+ SQ24860_IIN_OCF_NUM);
+ value = clamp_val(value, 0, 0x3f);
+ ret = pmbus_write_byte_data(client, page, SQ24860_VIREF, value);
+ break;
+
+ case PMBUS_VIRT_SAMPLES:
+ value = clamp_val(value, 1, SQ24860_MAX_SAMPLES);
+ value = ilog2(value);
+ ret = pmbus_update_byte_data(client, page, SQ24860_PK_MIN_AVG,
+ PK_MIN_AVG_AVG_CNT,
+ FIELD_PREP(PK_MIN_AVG_AVG_CNT, value));
+ break;
+
+ case PMBUS_VIRT_RESET_TEMP_HISTORY:
+ case PMBUS_VIRT_RESET_VIN_HISTORY:
+ case PMBUS_VIRT_RESET_IIN_HISTORY:
+ case PMBUS_VIRT_RESET_PIN_HISTORY:
+ case PMBUS_VIRT_RESET_VOUT_HISTORY:
+ /*
+ * SQ24860 has history resets based on MIN/AVG/PEAK instead of per
+ * sensor type. Exposing this quirk in hwmon is not desirable so
+ * reset MIN, AVG and PEAK together. Even is there effectively only
+ * one reset, which resets everything, expose the 5 entries so
+ * userspace is not required map a sensor type to another to trigger
+ * a reset
+ */
+ ret = pmbus_update_byte_data(client, 0, SQ24860_PK_MIN_AVG,
+ PK_MIN_AVG_RST_MASK,
+ PK_MIN_AVG_RST_MASK);
+ break;
+
+ default:
+ ret = -ENODATA;
+ break;
+ }
+
+ return ret;
+}
+
+static int sq24860_read_byte_data(struct i2c_client *client,
+ int page, int reg)
+{
+ int ret;
+
+ switch (reg) {
+ case PMBUS_WRITE_PROTECT:
+ ret = sq24860_mfr_write_protect_get(client);
+ break;
+
+ default:
+ ret = -ENODATA;
+ break;
+ }
+
+ return ret;
+}
+
+static int sq24860_write_byte_data(struct i2c_client *client,
+ int page, int reg, u8 byte)
+{
+ int ret;
+
+ switch (reg) {
+ case PMBUS_WRITE_PROTECT:
+ ret = sq24860_mfr_write_protect_set(client, byte);
+ break;
+
+ default:
+ ret = -ENODATA;
+ break;
+ }
+
+ return ret;
+}
+
+#if IS_ENABLED(CONFIG_SENSORS_SQ24860_REGULATOR)
+static const struct regulator_desc sq24860_reg_desc[] = {
+ PMBUS_REGULATOR_ONE_NODE("vout"),
+};
+#endif
+
+static const struct pmbus_driver_info sq24860_base_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = direct,
+ .m[PSC_VOLTAGE_IN] = 64,
+ .b[PSC_VOLTAGE_IN] = 0,
+ .R[PSC_VOLTAGE_IN] = 0,
+ .format[PSC_VOLTAGE_OUT] = direct,
+ .m[PSC_VOLTAGE_OUT] = 64,
+ .b[PSC_VOLTAGE_OUT] = 0,
+ .R[PSC_VOLTAGE_OUT] = 0,
+ .format[PSC_TEMPERATURE] = direct,
+ .m[PSC_TEMPERATURE] = 1,
+ .b[PSC_TEMPERATURE] = 0,
+ .R[PSC_TEMPERATURE] = 0,
+/*
+ * Current and power measurements depend on the calibration gain
+ * programmed from the board-specific IMON resistor value.
+ */
+ .format[PSC_CURRENT_IN] = direct,
+ .m[PSC_CURRENT_IN] = 16,
+ .b[PSC_CURRENT_IN] = 0,
+ .R[PSC_CURRENT_IN] = 0,
+ .format[PSC_POWER] = direct,
+ .m[PSC_POWER] = 2,
+ .b[PSC_POWER] = 0,
+ .R[PSC_POWER] = 0,
+ .func[0] = PMBUS_HAVE_VIN |
+ PMBUS_HAVE_VOUT |
+ PMBUS_HAVE_VMON |
+ PMBUS_HAVE_IIN |
+ PMBUS_HAVE_PIN |
+ PMBUS_HAVE_TEMP |
+ PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_STATUS_TEMP |
+ PMBUS_HAVE_SAMPLES,
+ .read_word_data = sq24860_read_word_data,
+ .write_word_data = sq24860_write_word_data,
+ .read_byte_data = sq24860_read_byte_data,
+ .write_byte_data = sq24860_write_byte_data,
+
+#if IS_ENABLED(CONFIG_SENSORS_SQ24860_REGULATOR)
+ .reg_desc = sq24860_reg_desc,
+ .num_regulators = ARRAY_SIZE(sq24860_reg_desc),
+#endif
+};
+
+static const struct i2c_device_id sq24860_i2c_id[] = {
+ { "sq24860" },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, sq24860_i2c_id);
+
+static const struct of_device_id sq24860_of_match[] = {
+ { .compatible = "silergy,sq24860" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sq24860_of_match);
+
+static int sq24860_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct pmbus_driver_info *info;
+ u32 rimon;
+ int ret;
+
+ if (device_property_read_u32(dev, "silergy,rimon-micro-ohms", &rimon))
+ rimon = SQ24860_DEFAULT_RIMON;
+ ret = sq24860_write_iin_cal_gain(client, rimon);
+ if (ret < 0)
+ return dev_err_probe(&client->dev, ret,
+ "Failed to set gain\n");
+ info = devm_kmemdup(dev, &sq24860_base_info, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ return pmbus_do_probe(client, info);
+}
+
+static struct i2c_driver sq24860_driver = {
+ .driver = {
+ .name = "sq24860",
+ .of_match_table = sq24860_of_match,
+ },
+ .probe = sq24860_probe,
+ .id_table = sq24860_i2c_id,
+};
+module_i2c_driver(sq24860_driver);
+
+MODULE_AUTHOR("Ziming Zhu <ziming.zhu@silergycorp.com>");
+MODULE_DESCRIPTION("PMBUS driver for SQ24860 eFuse");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/3] Add Silergy SQ24860 support
From: Ziming Zhu @ 2026-06-11 7:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
From: Ziming Zhu <ziming.zhu@silergycorp.com>
Add devicetree bindings, PMBus hwmon driver support, and documentation
for the Silergy SQ24860 eFuse.
The device provides voltage, current, power, and temperature telemetry.
The driver also supports peak, average, and minimum history reporting,
sample count configuration, and maps the manufacturer-specific VIREF
register to the generic input over-current fault limit attribute.
Changes in v3:
- fix remaining checkpatch issues in the SQ24860 driver
- use C comments consistently in the driver
- drop unused header files
- make GIMON a constant in the gain calculation helper
- use proper 64-bit division for the calibration gain calculation
- return -EINVAL when the calculated gain does not fit
- reject PMBUS_IIN_OC_FAULT_LIMIT values outside the hardware range
- treat malformed silergy,rimon-micro-ohms as an error
- sort sq24860 correctly in Documentation/hwmon/index.rst
Ziming Zhu (3):
dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
hwmon: pmbus: Add support for Silergy SQ24860
hwmon: Add documentation for SQ24860
.../bindings/hwmon/pmbus/silergy,sq24860.yaml | 74 +++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/sq24860.rst | 96 ++++
drivers/hwmon/pmbus/Kconfig | 19 +
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/sq24860.c | 430 ++++++++++++++++++
6 files changed, 621 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
create mode 100644 Documentation/hwmon/sq24860.rst
create mode 100644 drivers/hwmon/pmbus/sq24860.c
--
2.25.1
^ permalink raw reply
* [PATCH v3 3/3] hwmon: Add documentation for SQ24860
From: Ziming Zhu @ 2026-06-11 7:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260611074335.4415-1-zmzhu0630@163.com>
From: Ziming Zhu <ziming.zhu@silergycorp.com>
Document the supported sysfs attributes for the Silergy SQ24860 PMBus
hwmon driver.
Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/sq24860.rst | 96 +++++++++++++++++++++++++++++++++
2 files changed, 97 insertions(+)
create mode 100644 Documentation/hwmon/sq24860.rst
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 8b655e5d6b68..6184b88e2095 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -243,6 +243,7 @@ Hardware Monitoring Kernel Drivers
smsc47m1
sparx5-temp
spd5118
+ sq24860
stpddc60
surface_fan
sy7636a-hwmon
diff --git a/Documentation/hwmon/sq24860.rst b/Documentation/hwmon/sq24860.rst
new file mode 100644
index 000000000000..f0182b955d8a
--- /dev/null
+++ b/Documentation/hwmon/sq24860.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver sq24860
+=====================
+
+Supported chips:
+
+ * Silergy SQ24860
+
+ Prefix: 'sq24860'
+
+Author:
+
+ Ziming Zhu <ziming.zhu@silergycorp.com>
+
+Description
+------------
+
+This driver implements support for the Silergy SQ24860 eFuse. The device is an
+integrated circuit protection and power management device with a PMBus
+interface.
+
+The device supports direct format for reading input voltage, output voltage,
+auxiliary voltage, input current, input power, and temperature.
+
+The current and power measurement scale depends on the resistor connected
+between the IMON pin and ground. The resistor value can be configured with the
+``silergy,rimon-micro-ohms`` device tree property. See
+``Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml`` for details.
+
+Due to the specificities of the chip, all history reset attributes are tied
+together. Resetting the history of one sensor resets the history of all sensors.
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+
+======================= ======================================================
+in1_label "vin"
+in1_input Measured input voltage.
+in1_average Average measured input voltage.
+in1_min Minimum input voltage limit.
+in1_lcrit Critical low input voltage limit.
+in1_max Maximum input voltage limit.
+in1_crit Critical high input voltage limit.
+in1_min_alarm Input voltage low warning alarm.
+in1_lcrit_alarm Input voltage low fault alarm.
+in1_max_alarm Input voltage high warning alarm.
+in1_crit_alarm Input voltage high fault alarm.
+in1_highest Historical maximum input voltage.
+in1_lowest Historical minimum input voltage.
+in1_reset_history Write any value to reset history.
+
+in2_label "vmon"
+in2_input Measured auxiliary input voltage.
+
+in3_label "vout1"
+in3_input Measured output voltage.
+in3_average Average measured output voltage.
+in3_min Minimum output voltage limit.
+in3_min_alarm Output voltage low alarm.
+in3_lowest Historical minimum output voltage.
+in3_reset_history Write any value to reset history.
+
+curr1_label "iin"
+curr1_input Measured input current.
+curr1_average Average measured input current.
+curr1_max Maximum input current warning limit.
+curr1_crit Critical input over-current fault limit.
+curr1_max_alarm Input current warning alarm.
+curr1_crit_alarm Input over-current fault alarm.
+curr1_highest Historical maximum input current.
+curr1_reset_history Write any value to reset history.
+
+power1_label "pin"
+power1_input Measured input power.
+power1_average Average measured input power.
+power1_max Maximum input power warning limit.
+power1_alarm Input power warning alarm.
+power1_input_highest Historical maximum input power.
+power1_reset_history Write any value to reset history.
+
+temp1_input Measured temperature.
+temp1_average Average measured temperature.
+temp1_max Maximum temperature warning limit.
+temp1_crit Critical temperature fault limit.
+temp1_max_alarm Temperature warning alarm.
+temp1_crit_alarm Temperature fault alarm.
+temp1_highest Historical maximum temperature.
+temp1_reset_history Write any value to reset history.
+
+samples Number of samples used for average values.
+======================= ======================================================
+
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox