* [PATCH v3 0/2] ASoC: codecs: add Texas Instruments TAS2557 smart amplifier driver
From: Gianluca Boiano @ 2026-07-17 23:33 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: Gianluca Boiano, Shenghao Ding, Kevin Lu, Baojun Xu, Wang, Sen,
linux-sound, devicetree, linux-kernel
The TAS2557 is a mono Class-D smart amplifier with an on-chip DSP for
speaker protection, controlled over I2C with audio carried over
I2S/TDM. The DSP requires a board-specific firmware image generated
with TI's PurePath Console tuning tools; without it the device passes
no audio.
Patch 1 adds the devicetree binding. Patch 2 adds the ASoC codec
driver. A single node manages one physical TAS2557, or two of them
sharing one ASI bus and one reset/IRQ pair, using the reg-array
convention of ti,tas2781.yaml: the device at reg index 0 is DEV_A and
the device at index 1 is DEV_B, so no channel-selection property is
needed. The driver covers mono and dual-device stereo operation and
fault-interrupt recovery that reloads the firmware configuration on
clock loss, over-current, brownout or over-temperature.
The driver has been exercised across development of this series in
mono configuration on Xiaomi Mi A2 (SDM660, jasmine), Xiaomi Redmi
Note 6 Pro (SDM636, tulip) and Xiaomi Redmi 5 Plus (MSM8953, vince),
driving the top speaker, and in dual-device stereo on Xiaomi Mi Pad 4
(SDM660, clover). The v3 ASI word-length and data-slot-offset
changes follow hardware reports from vince (16-bit, offset 0) and
have not yet been re-confirmed on the 32-bit/offset-1 boards above.
Changes in v3:
- rework the binding and driver to a single-node, reg-array model
that manages up to two devices, matching ti,tas2781.yaml; drop the
ti,channel property entirely and derive DEV_A/DEV_B tuning from the
device order in reg (Krzysztof Kozlowski)
- rename ti,imon-slot-no/ti,vmon-slot-no to the plural
ti,imon-slot-nos/ti,vmon-slot-nos arrays (one entry per reg entry),
and constrain firmware-name to maxItems: 1 (Krzysztof Kozlowski)
- derive the ASI word length from the stream (params_width) and
re-apply it after each reset instead of hardcoding 32-bit, so
16-bit boards are no longer forced to 32-bit
- set symmetric_rate on the DAI (Mark Brown), and add
symmetric_sample_bits since one firmware config (one rate) is
active at a time and playback and capture share the single ASI
word length
- apply the same write-then-cache ordering used for the DAC-gain
control to the ISENSE/VSENSE mixer setters, so a failed
POWER_CTRL2 write no longer leaves the cached enable state stale
- only cache the DAC gain after the hardware write succeeds, so a
failed write no longer leaves the cache out of sync (Mark Brown)
- default the ASI data-slot offset to 0; an explicit
snd_soc_dai_set_tdm_slot() still takes precedence
Changes in v2:
- add the four mandatory supplies (vbat/iovdd/avdd/dvdd) to the
devicetree binding's "required" list (Wang Sen)
- propagate register-write failures out of hw_params() instead of
only logging them (Wang Sen)
- return IRQ_NONE instead of IRQ_HANDLED from the fault interrupt
handler when the device isn't in a state to have raised it, so
shared-IRQ accounting stays correct (Mark Brown)
- re-apply cached runtime state (DAI format, sense enables, DAC gain,
ASI slot offsets) after every device reset, including fault
recovery, instead of letting a hardcoded startup sequence silently
override set_dai_fmt()/the ISENSE/VSENSE mixer controls (Mark Brown)
- honour explicit snd_soc_dai_set_tdm_slot() configuration in
hw_params, and restore TX (OFFSET2) slot offsets after reset
- wait for the asynchronous firmware load on first stream start
instead of failing with -ENODEV
- make mute_stream direction-aware so capture-only IV-sense streams
are unmuted and stopping playback no longer mutes a live capture
Link to v2: https://lore.kernel.org/linux-sound/20260711145722.188556-1-morf3089@gmail.com/
Link to v1: https://lore.kernel.org/linux-sound/20260709221331.989109-1-morf3089@gmail.com/
Gianluca Boiano (2):
dt-bindings: sound: add Texas Instruments TAS2557
ASoC: codecs: add TAS2557 mono smart amplifier driver
.../devicetree/bindings/sound/ti,tas2557.yaml | 174 +
MAINTAINERS | 1 +
sound/soc/codecs/Kconfig | 11 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas2557.c | 3067 +++++++++++++++++
sound/soc/codecs/tas2557.h | 228 ++
6 files changed, 3483 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/ti,tas2557.yaml
create mode 100644 sound/soc/codecs/tas2557.c
create mode 100644 sound/soc/codecs/tas2557.h
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
--
2.55.0
^ permalink raw reply
* Re: [PATCH v5 2/3] phy: qcom: qmp-pcie: Add QMP PCIe Multi-PHY driver
From: Bjorn Andersson @ 2026-07-17 22:45 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Philipp Zabel, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260717-glymur_linkmode_0717-v5-2-4f9e87a61463@oss.qualcomm.com>
On Fri, Jul 17, 2026 at 02:58:34AM -0700, Qiang Yu wrote:
[..]
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c
> new file mode 100644
> index 000000000000..b79edf2b7d5f
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-multiphy.c
> @@ -0,0 +1,770 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2026, Qualcomm Technologies, Inc. and/or its subsidiaries.
No, there should not be a year in there.
> + */
> +
[..]
> +static int qmp_pcie_pd_power_on(struct qmp_pcie *qmp)
> +{
> + const struct qmp_phy_cfg *cfg = qmp->cfg;
> + int i, ret;
> +
> + for (i = 0; i < cfg->num_pds; i++) {
> + ret = pm_runtime_get_sync(qmp->pd_devs[i]);
In the error path you will put pd_devs[0..i-1], but
pm_runtime_get_sync() requires that you put pd_devs[i] as well.
Please use pm_runtime_resume_and_get() instead.
> + if (ret < 0) {
> + dev_err(qmp->dev, "failed to power on %s domain\n",
> + cfg->pd_names[i]);
> + goto err_power_off;
> + }
> + }
> +
> + return 0;
> +
> +err_power_off:
> + while (--i >= 0)
> + pm_runtime_put(qmp->pd_devs[i]);
> +
> + return ret;
> +}
Regards,
Bjorn
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: display: Add GlandaGPU binding
From: Leander Kieweg @ 2026-07-17 22:39 UTC (permalink / raw)
To: Conor Dooley
Cc: dri-devel, devicetree, airlied, simona, maarten.lankhorst,
mripard, tzimmermann, robh, krzk+dt, conor+dt
In-Reply-To: <20260716-decidable-tingle-175efaf36540@spud>
Hi Conor,
Thanks for the review.
> Sadly googling this device only shows up Phoronix and other copy-paste
> reporting sites. I think it'd probably be good to include a link to your
> project either here or in the commit message.
Good point either way. The link was in the cover letter, but I agree
it makes sense to have it directly in the description too, so it's
not something you have to go dig up separately when looking at just
this patch.
> This clock sounds like it is actually required? Doubt the device works
> without it!
> pw-bot: changes-requested
You're right, I'll move clocks into the required list.
> Usually I would say do not include things if you don't have to, but I
> would much rather you did if the alternative is an interrupts property
> like this that doesn't resemble anything used in devicetrees.
The example was actually taken from my DE10-Standard DTS, just
shortened, since I understood examples are generally expected to be
minimal. For v2 I'll add interrupt-parent back in and use the
GIC_SPI/IRQ_TYPE_LEVEL_HIGH macros from
dt-bindings/interrupt-controller/arm-gic.h instead of raw numbers:
#include <dt-bindings/interrupt-controller/arm-gic.h>
gpu@c0000000 {
compatible = "glanda,gpu-1.0";
reg = <0xc0000000 0x1000000>;
interrupt-parent = <&intc>;
interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&osc1>;
};
Thanks again,
Leander
^ permalink raw reply
* Re: [PATCH v3 00/11] arm64: dts: qcom: Add x1e/Hamoa camera DTSI
From: Bryan O'Donoghue @ 2026-07-17 22:21 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Vladimir Zapolskiy,
Konrad Dybcio, Aleksandrs Vinarskis
In-Reply-To: <alqn705VnocjAGbW@baldur>
On 17/07/2026 23:16, Bjorn Andersson wrote:
>>> For example: compatible = "qcom,x1e80100-csi2-phy"; is not a valid binding
> It doesn't say anywhere that I merged the csi2-phy nodes, above
> ty-letter states that I merged the camcc patch.
Ah camcc - my mistake I really thought you'd pulled in the WIP stuff for
CSIPHY etc.
Thanks for checking.
---
bod
^ permalink raw reply
* Re: [PATCH v2 3/8] clk: sunxi-ng: a733: Add PRCM CCU
From: Andre Przywara @ 2026-07-17 22:13 UTC (permalink / raw)
To: sashiko-bot
Cc: sashiko-reviews, Junhui Liu, linux-sunxi, robh, devicetree,
conor+dt
In-Reply-To: <20260712081340.438D21F00A3A@smtp.kernel.org>
On Sun, 12 Jul 2026 08:13:39 +0000
sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] Missing reset controls for hardware modules R-TWD, R-PPU, R-TZMA, and R-CPU-BIST.
Those devices indeed have no reset controls, so the code is right.
> - [Medium] The mux shift for `r_cpu_timer0..3` is incorrectly set to 4, which is anomalous for PRCM CCU clocks and likely a copy-paste error.
Those timer control register differs from the other ones, so the code
is correct: CLK_SRC_SEL is bits [6:4], S_TIMER<n>_CLK_GATING is bit 0.
Cheers,
Andre
> --
>
> --- Patch [3]: [PATCH v2 3/8] clk: sunxi-ng: a733: Add PRCM CCU ---
> commit 52650c9e3c767283edee5eb6338cdb409a63f50e
> Author: Junhui Liu <junhui.liu@pigmoral.tech>
>
> clk: sunxi-ng: a733: Add PRCM CCU
>
> Add support for the Power Reset Clock Management (PRCM) module found in
> the Allwinner A733 SoC. This clock controller manages the clock control
> and reset functions for device modules within the CPUS domain.
>
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun60i-a733-r.c b/drivers/clk/sunxi-ng/ccu-sun60i-a733-r.c
> > new file mode 100644
> > index 0000000000000..a56cd3edff5fe
> > --- /dev/null
> > +++ b/drivers/clk/sunxi-ng/ccu-sun60i-a733-r.c
> [ ... ]
> > +static SUNXI_CCU_P_DATA_WITH_MUX_GATE(r_cpu_timer0, "r-timer0", r_apb_parents, 0x100,
> > + 1, 3, /* P */
> > + 4, 3, /* mux */
> > + BIT(0), /* gate */
> > + 0);
> > +static SUNXI_CCU_P_DATA_WITH_MUX_GATE(r_cpu_timer1, "r-timer1", r_apb_parents, 0x104,
> > + 1, 3, /* P */
> > + 4, 3, /* mux */
> > + BIT(0), /* gate */
> > + 0);
> > +static SUNXI_CCU_P_DATA_WITH_MUX_GATE(r_cpu_timer2, "r-timer2", r_apb_parents, 0x108,
> > + 1, 3, /* P */
> > + 4, 3, /* mux */
> > + BIT(0), /* gate */
> > + 0);
> > +static SUNXI_CCU_P_DATA_WITH_MUX_GATE(r_cpu_timer3, "r-timer3", r_apb_parents, 0x10c,
> > + 1, 3, /* P */
> > + 4, 3, /* mux */
> > + BIT(0), /* gate */
> > + 0);
>
> [Severity: Medium]
> Are the mux shift values for r_cpu_timer0 through r_cpu_timer3 correct?
>
> Most of the other PRCM clocks in this driver use bit 24 for the mux shift.
> If the hardware actually expects the mux configuration at bit 24, writing
> to bits 4-6 might fail to select the correct parent clock and could
> accidentally overwrite other configuration bits, resulting in incorrect
> timer frequencies.
>
> [ ... ]
> > +static struct ccu_reset_map sun60i_a733_r_ccu_resets[] = {
> > + [RST_BUS_R_TIMER] = { 0x11c, BIT(16) },
> > + [RST_BUS_R_PWM] = { 0x13c, BIT(16) },
>
> [Severity: Medium]
> Should there be reset controls for the R-TWD, R-PPU, R-TZMA, and
> R-CPU-BIST modules mapped here?
>
> These modules have clock gate offsets defined (0x12c, 0x1ac, 0x1b0, 0x1bc)
> elsewhere in the driver, but are omitted from this reset list. If they do
> have corresponding reset lines, missing them could prevent their drivers
> from taking the hardware out of reset during initialization, potentially
> causing uninitialized states or bus hangs upon access.
>
> > + [RST_BUS_R_SPI] = { 0x15c, BIT(16) },
> > + [RST_BUS_R_MSGBOX] = { 0x17c, BIT(16) },
> [ ... ]
>
^ permalink raw reply
* Re: [PATCH v3 00/11] arm64: dts: qcom: Add x1e/Hamoa camera DTSI
From: Bjorn Andersson @ 2026-07-17 22:16 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Vladimir Zapolskiy,
Konrad Dybcio, Aleksandrs Vinarskis
In-Reply-To: <alfzEnd10K2kPjwp@baldur>
On Wed, Jul 15, 2026 at 03:52:47PM -0500, Bjorn Andersson wrote:
> On Wed, Jul 08, 2026 at 10:33:12PM +0100, Bryan O'Donoghue wrote:
> > On 08/07/2026 22:11, Bryan O'Donoghue wrote:
> > > On 08/07/2026 15:56, Bjorn Andersson wrote:
> > > > Applied, thanks!
> > > >
> > > > [01/11] arm64: dts: qcom: x1e80100: Add CAMCC block definition
> > > > commit: 6a3568f938c9ff2cb493f82dc595b4dc2760f517
> > > > [02/11] arm64: dts: qcom: x1e80100: Add CCI definitions
> > > > (no commit info)
> > > > [03/11] arm64: dts: qcom: x1e80100: Add CAMSS block definition
> > > > (no commit info)
> > > > [04/11] arm64: dts: qcom: x1e80100-crd: Add pm8010 CRD pmic,id=m
> > > > regulators
> > > > (no commit info)
> > > > [05/11] arm64: dts: qcom: x1e80100-crd: Add ov08x40 RGB sensor on CSIPHY4
> > > > (no commit info)
> > > > [06/11] arm64: dts: qcom: x1e80100-t14s: Add pm8010 camera PMIC with
> > > > voltage levels for IR and RGB camera
> > > > (no commit info)
> > > > [07/11] arm64: dts: qcom: x1e80100-t14s: Add on ov02c10 RGB sensor
> > > > on CSIPHY4
> > > > (no commit info)
> > > > [08/11] arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Add pm8010
> > > > camera PMIC with voltage levels for IR and RGB camera
> > > > (no commit info)
> > > > [09/11] arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Add l7b_2p8
> > > > voltage regulator for RGB camera
> > > > (no commit info)
> > > > [10/11] arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Add ov02c10
> > > > RGB sensor on CSIPHY4
> > > > (no commit info)
> > > > [11/11] arm64: dts: qcom: x1e80100-dell-inspiron14-7441: Switch on
> > > > CAMSS RGB sensor
> > > > (no commit info)
> > > >
> > > > Best regards,
> > > > -- Bjorn Andersson <andersson@kernel.org>
> > >
> > > Bjorn.
> > >
Sorry, should have paid a bit more attention here.
I believe I had previously tried to apply part of this series, just to
realize that the bindings weren't in place - and hence backed them out
again.
So the change I actually merged was [1], but for some reason we got a
ty-letter on this series.
[1] https://lore.kernel.org/all/20260507-purwa-videocc-camcc-v5-6-fc3af4130282@oss.qualcomm.com/
> > > This is v3 from March. We are on v12. I don't think you meant to apply
> > > this.
I have v3, v4, and v5 of the camcc addition, I merged v5. I'm not able
to figure what series you're talking about, but it must be something
else?
> > >
> > > ---
> > > bod
> >
> > For example: compatible = "qcom,x1e80100-csi2-phy"; is not a valid binding
It doesn't say anywhere that I merged the csi2-phy nodes, above
ty-letter states that I merged the camcc patch.
> >
> > Please revert.
> >
>
> Done
>
And the revert is dropped as it was incorrect, sorry about that.
Regards,
Bjorn
> Regards,
> Bjorn
>
>
> > ---
> > bod
> >
>
^ permalink raw reply
* Re: [PATCH RFC 3/8] clk: sunxi-ng: a733: Add PRCM CCU
From: Andre Przywara @ 2026-07-17 21:57 UTC (permalink / raw)
To: Enzo Adriano
Cc: Junhui Liu, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260702165944.828550-1-enzo.adriano.code@gmail.com>
On Thu, 2 Jul 2026 12:59:44 -0400
Enzo Adriano <enzo.adriano.code@gmail.com> wrote:
Hi Enzo,
> Register check for the PRCM driver against the public A733 User Manual
> V0.92, chapter 4.2.5: all 41 entries I could extract (13 reset-map
> entries, 18 bus gates, 10 mod/mux clocks) match the manual's register
> offsets and bit positions. No discrepancies found in this patch.
>
> For what it's worth, we have also exercised the R-domain at runtime on a
> Radxa Cubie A7S (r-ahb/r-apb0 rates with live consumers on r-pinctrl,
> r-rtc and the PPU, bus-r-cpucfg via its critical flag), with no
> misbehavior attributable to the PRCM model.
many thanks for doing this, but please add proper tags to your replies,
otherwise this won't be carried over to new revision, and your work
gets lost in the cracks - as it happened this time.
So you now would need to redo the review on v2. I'd suggest to compare
the patches between their RFC and v2 version, and if you agree that the
changes don't touch anything you checked (register offsets, bit
positions), then you can just (re-)post your review with the proper
tags - and a brief list of what you checked, as you did in the RFC
reply.
Thanks,
Andre
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: qcom,snps-dwc3: Add property indicating presence of eUSB2 phy
From: Thinh Nguyen @ 2026-07-17 21:34 UTC (permalink / raw)
To: Peter Chen, Krishna Kurapati
Cc: Thinh Nguyen, Konrad Dybcio, Krzysztof Kozlowski,
Dmitry Baryshkov, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <bea99c43-16c2-4f5b-b14c-e1a518b97e11@oss.qualcomm.com>
On Fri, Jul 17, 2026, Krishna Kurapati wrote:
>
>
> On 7/17/2026 9:12 AM, Peter Chen wrote:
> > On 26-07-17 01:56:59, Thinh Nguyen wrote:
> > > On Thu, Jul 16, 2026, Peter Chen wrote:
> > > > On 26-07-17 00:06:37, Thinh Nguyen wrote:
> > > > > >
> > > > > > I have seen fewer platforms use "phy_type" at dts for arm64, dwc3
> > > > > > core uses it only for special cases and the code was added for
> > > > > > ten years ago. For the default situation, we may not need to
> > > > > > change DWC3_GUSB2PHYCFG_EUSB2OPMODE value for UTMI+, Thinh, is it
> > > > > > correct?
> > > > > >
> > > > >
> > > > > The GUSB2PHYCFG.eUSB2OPMODE is only relevant for host mode and mainly
> > > > > for electrical compliance. Usually by default, the CoreConsultant
> > > > > setting should have this set correctly. So not explicitly setting it
> > > > > should be functionally fine (IIRC).
> > > > >
> > > > > That said, this is separate from the GUSB2PHYCFG.PHYIF, which the core
> > > > > uses dwc->hsphy_mode to indicate whether the UTMI interface is 8-bit or
> > > > > 16-bit.
> > > > >
> > > >
> > > > Why only rockchip uses this "phy_type" property, why other SoC vendors
> > > > no this requirement for UTMI width setting?
> > > >
> > >
> > > Not just rockchip, some tegra and hikey also use it. Some old qcom dts
> > > files also have it for ulpi.
> >
> > Tegra and old qcom platforms use chipidea, hikey uses dwc3.
> >
> > >
> > > It is typically set when the coreConsultant default differs from what
> > > the platform needs, so the driver can override it with the correct
> > > setting.
> > >
> > > My point is that changing "phy_type" definition is more involved than it
> > > looks. I'm open to alternatives.
> > >
> >
> > I know your concern that in case the eUSB2 PHY SoC wants to change UTMI
> > width, it can't do that. Are there controller register know it connects
> > eUSB2 PHY?
The controller doesn't know that.
> >
> > For the place to put "eusb2" for phy type, I still think enum
> > usb_phy_interface at: include/linux/usb/phy.h is the most suitable
> > place, would you have any alternatives?
> >
> > Another solution is using generic PHY API phy_get_mode, set fixed "eusb2"
> > mode at eUSB2 PHY driver, but it depends on PHY driver doesn't have
> > different settings for device and host mode.
> >
>
> Konrad did suggest this on v3:
>
> https://urldefense.com/v3/__https://lore.kernel.org/all/3de365a0-4632-42ea-8a8a-5a4765945a76@oss.qualcomm.com/__;!!A4F2R9G_pg!bFfHVkKIznULZPI2qLzahGobT6OIz4j3-XA_n_3hHnRuvzps_XuAGJdphzxkK4bk6twEah-Zn6xRS1uCQCjZ1ud3HnRftKhw2SXfqA$
>
> This involves cleaning all drivers using these enums if we take that route.
We should not be using phy_attrs.mode. It's a runtime operation mode.
Instead, we can introduce a new phy attribute phy_attrs.type and
phy_get_type(). The phy driver can set this at probe and the dwc3-qcom.c
can query it from the phy phandle.
We can define PHY_TYPE_EUSB2 along with the existing types in
include/dt-bindings/phy/phy.h for this attribute.
BR,
Thinh
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: nvidia,tegra234-mgbe: Add missing properties
From: Rob Herring @ 2026-07-17 21:27 UTC (permalink / raw)
To: Thierry Reding
Cc: Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jonathan Hunter,
netdev, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260716212001.989872-1-thierry.reding@kernel.org>
On Thu, Jul 16, 2026 at 11:20:01PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Being a DWMAC derivative, the Tegra234 MGBE supports AXI configuration
> nodes named stmmac-axi-config and phandle references to them using the
> snps,axi-config property.
>
> While at it, add the 10gbase-r PHY mode.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> This gets rid of the remaining warnings on half of the Tegra234 boards.
>
> .../devicetree/bindings/net/nvidia,tegra234-mgbe.yaml | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
> index 215f14d1897d..dc897e312c55 100644
> --- a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
> +++ b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
> @@ -81,8 +81,9 @@ properties:
> phy-mode:
> contains:
> enum:
> - - usxgmii
> - 10gbase-kr
> + - 10gbase-r
> + - usxgmii
>
> mdio:
> $ref: mdio.yaml#
> @@ -90,6 +91,12 @@ properties:
> description:
> Optional node for embedded MDIO controller.
>
> + snps,axi-config:
> + $ref: snps,dwmac.yaml#/properties/snps,axi-config
> +
> + stmmac-axi-config:
> + $ref: snps,dwmac.yaml#/properties/stmmac-axi-config
You should be referencing the whole snps,dwmac.yaml.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: soc: imx-iomuxc-gpr: allow bridge@18 as child node
From: Rob Herring (Arm) @ 2026-07-17 21:25 UTC (permalink / raw)
To: Frank.Li
Cc: Fabio Estevam, imx, linux-arm-kernel, Pengutronix Kernel Team,
Conor Dooley, Frank Li, linux-kernel, Krzysztof Kozlowski,
Sascha Hauer, Peng Fan, devicetree, Shawn Guo
In-Reply-To: <20260717201519.844259-1-Frank.Li@oss.nxp.com>
On Fri, 17 Jul 2026 16:15:17 -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> The legacy i.MX6SX (>15 year) SoC imx-iomuxc-gpr contains one LDB_CTRL
> register. Allow the LVDS Display Bridge(LDB) child node under
> imx-iomuxc-gpr.
>
> Fix below CHECK_DTBS warnings:
> arch/arm/boot/dts/nxp/imx/imx6sx-nitrogen6sx.dtb: syscon@20e4000 (fsl,imx6sx-iomuxc-gpr): '#address-cells', '#size-cells', 'bridge@18' do not match any of the regexes: '^ipu[12]_csi[01]_mux$', '^pinctrl-[0-9]+$
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v2
> - remove status = "disabled" at example
> ---
> .../bindings/soc/imx/fsl,imx-iomuxc-gpr.yaml | 58 +++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.example.dtb: syscon@20e4000 (fsl,imx6sx-iomuxc-gpr): bridge@18:reg: [[24, 4]] is too short
from schema $id: http://devicetree.org/schemas/soc/imx/fsl,imx-iomuxc-gpr.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/imx/fsl,imx-iomuxc-gpr.example.dtb: bridge@18 (fsl,imx6sx-ldb): reg: [[24, 4]] is too short
from schema $id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260717201519.844259-1-Frank.Li@oss.nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 5/6] hwmon: (adt7470) Register as a PWM provider
From: sashiko-bot @ 2026-07-17 21:17 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca; +Cc: devicetree, linux-hwmon, robh, conor+dt
In-Reply-To: <20260717-adt7470_thermalzone-v2-5-a55147958fad@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] Calculating the PWM duty cycle using `DIV_ROUND_CLOSEST_ULL` with a 64-bit divisor causes 32-bit truncation and a divide-by-zero kernel panic on 32-bit architectures.
- [High] Early return in PWM apply relies on unsynchronized, zero-initialized cache values, potentially ignoring the first 0% duty cycle request.
- [Medium] Registering a generic PWM provider directly from a hardware monitoring driver violates subsystem layering guidelines.
- [Medium] The driver silently ignores the requested PWM signal polarity, applying normal polarity even when inverted is requested.
Pre-existing issues:
- [High] The PWM automatic mode mask calculation swaps the masks for PWM channels 3 and 4, causing writes to one channel to affect the configuration of the other.
--
--- Patch [5]: [PATCH v2 5/6] hwmon: (adt7470) Register as a PWM provider ---
commit e11bee28efc81066c4940f5c07591cd6181c6453
Author: Luiz Angelo Daros de Luca <luizluca@gmail.com>
hwmon: (adt7470) Register as a PWM provider
The patch registers the ADT7470 hardware monitoring driver as a generic PWM
provider, allowing standard Device Tree consumers like "pwm-fan" to use it.
It converts the PWM framework's requested duty cycle to the 0-255 scale
used by the hardware registers. The legacy sysfs interface operates in
parallel and remains unaffected.
> diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
> index d881609c99aa3..aaae14a421cd8 100644
> --- a/drivers/hwmon/adt7470.c
> +++ b/drivers/hwmon/adt7470.c
[ ... ]
> @@ -864,6 +865,57 @@ static int adt7470_pwm_write(struct device *dev, u32 attr, int channel, long val
> return err;
> }
>
> +static int adt7470_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct adt7470_data *data = pwmchip_get_drvdata(chip);
> + unsigned int pwm_auto_reg_mask;
> + int err;
> + u8 val;
> +
> + if (pwm->hwpwm % 2)
> + pwm_auto_reg_mask = ADT7470_PWM2_AUTO_MASK;
> + else
> + pwm_auto_reg_mask = ADT7470_PWM1_AUTO_MASK;
[Severity: High]
This is a pre-existing issue, but does this logic incorrectly swap the masks
for PWM channels 3 and 4?
The logic uses hwpwm % 2 to select between ADT7470_PWM1_AUTO_MASK and
ADT7470_PWM2_AUTO_MASK. For channel 3 (hwpwm = 2) and channel 4 (hwpwm = 3),
does this inadvertently select 0x80 for PWM3 and 0x40 for PWM4?
If the datasheet and macro definitions dictate 0x40 for PWM3 and 0x80 for
PWM4, could writing to one of these channels corrupt the configuration
of the other?
This issue seems to be copied from the preexisting adt7470_pwm_write() sysfs
handler.
> +
> + if (state->enabled && state->period > 0)
[Severity: Medium]
Does this apply callback silently ignore requested PWM polarities?
If a consumer specifies PWM_POLARITY_INVERSED in the PWM state, the hardware
only supports normal polarity.
Since there is no check to see if state->polarity != PWM_POLARITY_NORMAL,
will this cause the driver to quietly apply normal polarity instead of
rejecting the unsupported request?
> + val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * 255, state->period);
[Severity: High]
Does this calculation cause a divide-by-zero on 32-bit architectures?
When a consumer requests a PWM period that is a multiple of 2^32 ns,
do_div() implicitly casts the divisor to a 32-bit integer on 32-bit systems,
meaning a value like 1ULL << 32 becomes 0.
Since the truncation happens during the division after the state->period > 0
check, can this lead to a kernel panic?
> + else
> + val = 0;
> +
> + mutex_lock(&data->lock);
> +
> + if (data->pwm[pwm->hwpwm] == val &&
> + data->pwm_automatic[pwm->hwpwm] == 0) {
> + mutex_unlock(&data->lock);
> + return 0;
> + }
[Severity: High]
Can this early return falsely ignore the first 0% duty cycle request?
Because the driver data is allocated with devm_kzalloc(), data->pwm is
zero-initialized.
If a consumer requests a 0% duty cycle (val = 0) before the
adt7470_update_thread has completed its first hardware state synchronization,
will this condition pass and return early without sending the 0% duty cycle
to the hardware?
[ ... ]
> @@ -1299,6 +1351,21 @@ static int adt7470_probe(struct i2c_client *client)
> if (IS_ERR(hwmon_dev))
> return PTR_ERR(hwmon_dev);
>
> + if (IS_REACHABLE(CONFIG_PWM)) {
> + struct pwm_chip *chip;
> +
> + chip = devm_pwmchip_alloc(dev, ADT7470_PWM_COUNT, 0);
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> +
> + chip->ops = &adt7470_pwm_ops;
> + pwmchip_set_drvdata(chip, data);
> +
> + err = devm_pwmchip_add(dev, chip);
> + if (err)
> + return dev_warn_probe(dev, err, "failed to register PWM chip\n");
> + }
[Severity: Medium]
Does this violate the hardware monitoring subsystem guidelines?
The guidelines indicate that secondary functionalities, such as PWM or GPIO,
should be implemented as auxiliary devices rather than registering directly
from drivers/hwmon/.
By using devm_pwmchip_alloc() and devm_pwmchip_add() directly in the hwmon
probe function, does this bypass the separation into an auxiliary device and
cross-subsystem review?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format
From: Francesco Dolcini @ 2026-07-17 21:13 UTC (permalink / raw)
To: Frank Li, Francesco Dolcini
Cc: sashiko-reviews, devicetree, robh, dri-devel, Frank.Li, conor+dt,
imx
In-Reply-To: <20260717205754.GB512678@francesco-nb>
On Fri, Jul 17, 2026 at 10:57:54PM +0200, Francesco Dolcini wrote:
> On Fri, Jul 17, 2026 at 10:55:51AM -0500, Frank Li wrote:
> > On Fri, Jul 17, 2026 at 12:28:07PM +0000, sashiko-bot@kernel.org wrote:
> > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > - [Low] Introduction of the legacy, non-standard `interface-pix-fmt` property for a standard hardware concept (parallel bus width), violating modern DT principles.
> > > --
> > >
> > > --- Patch [1]: [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format ---
> > > commit 7225ea545d2ff50540972dd75d375b8ecea4f315
> > > Author: Francesco Dolcini <francesco.dolcini@toradex.com>
> > >
> > > dt-bindings: lcdif: Add interface pixel format
> > >
> > > This commit updates the fsl,lcdif device tree binding to support the
> > > interface-pix-fmt property. The property is used to describe the hardware's
> > > parallel data bus transfer width to match board wiring and prevent shifted
> > > colors.
> > >
> > > > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > > > index 2dd0411ec6516..209ee5a96e393 100644
> > > > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> > > > @@ -58,6 +58,13 @@ properties:
> > > > items:
> > > > - const: rx
> > > >
> > > > + interface-pix-fmt:
> > > > + $ref: /schemas/types.yaml#/definitions/string
> > > > + enum:
> > > > + - rgb24
> > > > + - rgb565
> > > > + - rgb666
> > >
> > > [Severity: Low]
> > > Is this introducing a legacy, non-standard property into the new schema ABI?
> > >
> > > Standard devicetree guidelines usually prefer endpoint properties like
> > > bus-width (defined in video-interfaces.yaml) to describe physical parallel
> > > data line configurations, such as setting bus-width = <18> for RGB666.
> >
> > Make sense, can we use standard property?
>
> video-interfaces.yaml is for video capture interfaces (cameras and the
> media/v4l subsystem). It does not apply here for DPI display interfaces.
ok, looking at this closer, it seems this is a used property also in the
DRM subsystem. I'll appreciate a feedback from some DT maintainer before
reworking this patch accordingly.
^ permalink raw reply
* Re: [PATCH v2 3/6] hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread
From: sashiko-bot @ 2026-07-17 21:12 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca; +Cc: devicetree, linux-hwmon, robh, conor+dt
In-Reply-To: <20260717-adt7470_thermalzone-v2-3-a55147958fad@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] Module unload hang due to missed wakeup in kthread loop
- [High] Temperature alarm bitmask logic error causes false negatives and incorrect states
- [High] Unfreezable polling kthread can crash or hang the I2C bus during system suspend
- [High] Subsystem guideline violation: Driver uses private lock instead of hwmon_lock()
--
--- Patch [3]: [PATCH v2 3/6] hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread ---
commit e6d87eed20a630165f01d0513e17b82247a7f775
Author: Luiz Angelo Daros de Luca <luizluca@gmail.com>
hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread
This commit prevents a busy-loop and I2C flooding in the background kthread
when userspace configures auto_update_interval and num_temp_sensors to 0.
It resolves the issue by raising the lower limit of the clamp_val in
auto_update_interval_store() from 0 to 500 milliseconds.
Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org
> diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
> index 481d51617f4be..77e7be6927906 100644
> --- a/drivers/hwmon/adt7470.c
> +++ b/drivers/hwmon/adt7470.c
> @@ -509,7 +509,7 @@ static ssize_t auto_update_interval_store(struct device *dev,
> if (kstrtol(buf, 10, &temp))
> return -EINVAL;
>
> - temp = clamp_val(temp, 0, 60000);
> + temp = clamp_val(temp, 500, 60000);
>
> mutex_lock(&data->lock);
[Severity: High]
This isn't a bug introduced by this patch, but does the use of a private
mutex for an extra sysfs attribute violate the HWMON subsystem directive
to use the central hwmon_lock() and hwmon_unlock() for this purpose?
> data->auto_update_interval = temp;
I would also like to ask about some other pre-existing issues in this file:
drivers/hwmon/adt7470.c:adt7470_update_thread() {
[ ... ]
while (!kthread_should_stop()) {
mutex_lock(&data->lock);
adt7470_read_temperatures(data);
mutex_unlock(&data->lock);
if (kthread_should_stop())
break;
schedule_timeout_interruptible(msecs_to_jiffies(data->auto_update_interval));
}
[ ... ]
}
[Severity: High]
This is a pre-existing issue, but does checking the stop condition while
the thread is in TASK_RUNNING without preparing to sleep cause missed
wakeups?
If the unbind process calls kthread_stop(), it sets the stop flag and
wakes the thread. Because the thread is still in TASK_RUNNING, the wake
is a no-op, and the thread will then call schedule_timeout_interruptible()
and go to sleep, hanging module unload for up to 60 seconds.
[Severity: High]
This is also a pre-existing issue, but does this kthread lack
set_freezable() and try_to_freeze()? It appears to unconditionally attempt
I2C access while the bus might be suspended. Can this crash or hang the
I2C bus during system suspend and resume transitions?
drivers/hwmon/adt7470.c:adt7470_temp_read() {
[ ... ]
case hwmon_temp_alarm:
*val = !!(data->alarm & channel);
break;
[ ... ]
}
[Severity: High]
This is a pre-existing issue, but does this logic incorrectly use the
integer index channel as a bitwise AND mask instead of a bit shift?
Could this yield completely incorrect hardware alarm states, preventing
userspace from properly monitoring temperature emergencies?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 2/6] hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors
From: sashiko-bot @ 2026-07-17 21:10 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca; +Cc: robh, conor+dt, linux-hwmon, devicetree
In-Reply-To: <20260717-adt7470_thermalzone-v2-2-a55147958fad@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the driver violates hwmon subsystem guidelines by using a private mutex `data->lock` for sysfs attributes instead of the standard `hwmon_lock()` API.
--
--- Patch [2]: [PATCH v2 2/6] hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors ---
commit f5bf8b0ee6f2d048580f6d00a71e61df362fa4c6
Author: Luiz Angelo Daros de Luca <luizluca@gmail.com>
hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors
This commit introduces a recovery path in adt7470_read_temperatures() to ensure
that original PWM configuration registers are restored if an I2C operation
fails after temporarily switching the fans to manual mode.
Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org
> diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
> index 664349756dc2b..481d51617f4be 100644
> --- a/drivers/hwmon/adt7470.c
> +++ b/drivers/hwmon/adt7470.c
> @@ -205,11 +205,12 @@ static inline int adt7470_write_word_data(struct adt7470_data *data, unsigned in
> /* Probe for temperature sensors. Assumes lock is held */
> static int adt7470_read_temperatures(struct adt7470_data *data)
> {
[Severity: High]
This isn't a bug introduced by this patch, but this driver appears to use a
private mutex (data->lock) for internal synchronization instead of the
standard hwmon_lock() API.
For example, it uses mutex_init(&data->lock) in adt7470_probe() and locks it
with mutex_lock(&data->lock) in sysfs attribute operations like
pwm_auto_temp_store().
Does this bypass the centralized hwmon core serialization mechanism and risk
logical race conditions with the thermal subsystem? Should this be updated
to follow the hwmon subsystem guidelines which mandate using hwmon_lock()
and hwmon_unlock() for attributes not registered via the info parameter?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 6/6] hwmon: (adt7470) Add thermal zone sensor support
From: sashiko-bot @ 2026-07-17 21:09 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca; +Cc: robh, linux-hwmon, devicetree, conor+dt
In-Reply-To: <20260717-adt7470_thermalzone-v2-6-a55147958fad@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The background update thread holds a private mutex during a multi-second sleep, which will severely stall the thermal subsystem polling.
--
--- Patch [6]: [PATCH v2 6/6] hwmon: (adt7470) Add thermal zone sensor support ---
commit c1655de2721e60975758432b0053b21f699a5803
Author: Luiz Angelo Daros de Luca <luizluca@gmail.com>
hwmon: (adt7470) Add thermal zone sensor support
This commit exposes the ADT7470 external temperature sensors to the thermal
framework using the HWMON_C_REGISTER_TZ flag.
> diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
> index aaae14a421cd8..595a8f934d60a 100644
> --- a/drivers/hwmon/adt7470.c
> +++ b/drivers/hwmon/adt7470.c
> @@ -1251,6 +1251,8 @@ static const struct hwmon_ops adt7470_hwmon_ops = {
> };
>
> static const struct hwmon_channel_info * const adt7470_info[] = {
> + HWMON_CHANNEL_INFO(chip,
> + HWMON_C_REGISTER_TZ),
[Severity: High]
Could exposing this sensor to the thermal framework cause a regression by
stalling the thermal workqueue?
The thermal subsystem will automatically poll this sensor via adt7470_read(),
which acquires data->lock.
Concurrently, the driver's background kthread adt7470_update_thread() holds
this exact lock while executing msleep_interruptible() for up to 2 seconds
in adt7470_read_temperatures():
drivers/hwmon/adt7470.c:adt7470_update_thread() {
...
mutex_lock(&data->lock);
adt7470_read_temperatures(data);
mutex_unlock(&data->lock);
...
}
drivers/hwmon/adt7470.c:adt7470_read_temperatures() {
...
res = msleep_interruptible((data->num_temp_sensors >= 0 ?
data->num_temp_sensors * 200 :
TEMP_COLLECTION_TIME));
...
}
Will the thermal workqueue block for up to 2 seconds when trying to read the
temperature, risking a stall in thermal management for other zones sharing
the same workqueue?
> HWMON_CHANNEL_INFO(temp,
> HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX | HWMON_T_ALARM,
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2 4/6] hwmon: (adt7470) Add ADT7470_PWM_MAX macro
From: sashiko-bot @ 2026-07-17 21:05 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca; +Cc: conor+dt, devicetree, linux-hwmon, robh
In-Reply-To: <20260717-adt7470_thermalzone-v2-4-a55147958fad@gmail.com>
> Instead of a magic 255, use a macro to refer to it.
>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: hwmon: add binding for adi,adt7470
From: sashiko-bot @ 2026-07-17 21:04 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca; +Cc: linux-hwmon, devicetree, robh, conor+dt
In-Reply-To: <20260717-adt7470_thermalzone-v2-1-a55147958fad@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding defines PWM output and thermal sensor provider capabilities but fails to include `#pwm-cells` and `#thermal-sensor-cells` in the `required` list.
--
--- Patch [1]: [PATCH v2 1/6] dt-bindings: hwmon: add binding for adi,adt7470 ---
commit 6372aff696282f1ac0ec9a8f1372c186734704a2
Author: Luiz Angelo Daros de Luca <luizluca@gmail.com>
dt-bindings: hwmon: add binding for adi,adt7470
The ADT7470 hardware monitoring chip supports PWM fan control and temperature
monitoring. This commit introduces the YAML device tree binding schema for it,
defining PWM and thermal sensor provider capabilities.
> diff --git a/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
> new file mode 100644
> index 0000000000000..14bb6359c91f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
[ ... ]
> +properties:
> + compatible:
> + const: adi,adt7470
> +
> + reg:
> + maxItems: 1
> +
> + "#pwm-cells":
> + const: 2
> + description: |
> + Number of cells in a PWM specifier.
> + - The first cell is the PWM channel (0 to 3).
> + - The second cell is the PWM period in nanoseconds.
> +
> + "#thermal-sensor-cells":
> + const: 1
> + description: |
> + Number of cells required to uniquely identify the temperature sensors.
> + Valid index values are 0 to 9, corresponding to temp1 through temp10.
> +
> +required:
> + - compatible
> + - reg
[Severity: Medium]
Should #pwm-cells and #thermal-sensor-cells be included in this required list?
Because this binding defines the device as a PWM output and thermal sensor
provider, omitting these cell properties from the required list allows
incomplete device tree nodes to silently pass schema validation.
If an adt7470 node is created without them, dependent drivers attempting to
reference it as a provider may fail at runtime when parsing the provider
specifier.
Could both #pwm-cells and #thermal-sensor-cells be added to the required
array to enforce complete node validation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 0/2] SM8450 QoL changes (dts)
From: David Heidelberg @ 2026-07-17 21:04 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Esteban Urrutia
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
Dmitry Baryshkov
In-Reply-To: <178425854592.1084804.16144771627314071470.b4-ty@kernel.org>
On 17/07/2026 05:23, Bjorn Andersson wrote:
>
> On Sat, 11 Jul 2026 23:12:26 -0400, Esteban Urrutia wrote:
>> These patches focus on correcting some details on the DTS for the SM8450
>> SoC.
>>
>>
>
> Applied, thanks!
>
> [1/2] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
> commit: 0ed8261e0ebdac5f1f08dcbfc209efe36937ed2d
> [2/2] arm64: dts: qcom: sm8450: Add mode-switch property to qmpphy
> commit: 8a2b4481b66c802af293e55eee07406971d5aa7b
>
> Best regards,
I'm afraid there is v3 of this patchset :(
https://lore.kernel.org/all/20260713-sm8450-qol-dispcc-v3-0-56fd05822270@proton.me/
David
^ permalink raw reply
* [PATCH v2 6/6] hwmon: (adt7470) Add thermal zone sensor support
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm
In-Reply-To: <20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com>
Expose the ADT7470 external temperature sensors to the thermal
framework using HWMON_C_REGISTER_TZ.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
drivers/hwmon/adt7470.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index aaae14a421cd..595a8f934d60 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -1251,6 +1251,8 @@ static const struct hwmon_ops adt7470_hwmon_ops = {
};
static const struct hwmon_channel_info * const adt7470_info[] = {
+ HWMON_CHANNEL_INFO(chip,
+ HWMON_C_REGISTER_TZ),
HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX | HWMON_T_ALARM,
HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX | HWMON_T_ALARM,
--
2.55.0
^ permalink raw reply related
* [PATCH v2 5/6] hwmon: (adt7470) Register as a PWM provider
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm
In-Reply-To: <20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com>
hwmon: (adt7470) Register as a PWM provider
The ADT7470 features four PWM outputs that can be used to control fans.
Previously, these were only accessible through the legacy hwmon sysfs
interface.
Register the ADT7470 as a generic PWM provider. This enables standard
Device Tree PWM consumers, such as "pwm-fan", to use the device through
the "#pwm-cells" property.
When a PWM consumer applies a new PWM state, the driver automatically
switches the corresponding PWM channel to manual mode so that the
requested duty cycle takes effect. The duty cycle specified by the PWM
framework is internally converted to the 0-255 scale expected by the
hardware registers.
The legacy sysfs interface remains unaffected and operates in parallel.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
drivers/hwmon/Kconfig | 1 +
drivers/hwmon/adt7470.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 68 insertions(+)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08c29685126a..8838b6714e60 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -224,6 +224,7 @@ config SENSORS_ADT7462
config SENSORS_ADT7470
tristate "Analog Devices ADT7470"
depends on I2C
+ depends on PWM || PWM=n
select REGMAP_I2C
help
If you say yes here you get support for the Analog Devices
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index d881609c99aa..aaae14a421cd 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -22,6 +22,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/util_macros.h>
+#include <linux/pwm.h>
/* Addresses to scan */
static const unsigned short normal_i2c[] = { 0x2C, 0x2E, 0x2F, I2C_CLIENT_END };
@@ -864,6 +865,57 @@ static int adt7470_pwm_write(struct device *dev, u32 attr, int channel, long val
return err;
}
+static int adt7470_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct adt7470_data *data = pwmchip_get_drvdata(chip);
+ unsigned int pwm_auto_reg_mask;
+ int err;
+ u8 val;
+
+ if (pwm->hwpwm % 2)
+ pwm_auto_reg_mask = ADT7470_PWM2_AUTO_MASK;
+ else
+ pwm_auto_reg_mask = ADT7470_PWM1_AUTO_MASK;
+
+ if (state->enabled && state->period > 0)
+ val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * 255, state->period);
+ else
+ val = 0;
+
+ mutex_lock(&data->lock);
+
+ if (data->pwm[pwm->hwpwm] == val &&
+ data->pwm_automatic[pwm->hwpwm] == 0) {
+ mutex_unlock(&data->lock);
+ return 0;
+ }
+
+ /* Put the PWM channel in manual mode before updating it. */
+ err = regmap_update_bits(data->regmap,
+ ADT7470_REG_PWM_CFG(pwm->hwpwm),
+ pwm_auto_reg_mask, 0);
+ if (err < 0)
+ goto out;
+
+ data->pwm_automatic[pwm->hwpwm] = 0;
+
+ err = regmap_write(data->regmap,
+ ADT7470_REG_PWM(pwm->hwpwm), val);
+ if (err < 0)
+ goto out;
+
+ data->pwm[pwm->hwpwm] = val;
+out:
+ mutex_unlock(&data->lock);
+
+ return err;
+}
+
+static const struct pwm_ops adt7470_pwm_ops = {
+ .apply = adt7470_pwm_apply,
+};
+
static ssize_t pwm_max_show(struct device *dev,
struct device_attribute *devattr, char *buf)
{
@@ -1299,6 +1351,21 @@ static int adt7470_probe(struct i2c_client *client)
if (IS_ERR(hwmon_dev))
return PTR_ERR(hwmon_dev);
+ if (IS_REACHABLE(CONFIG_PWM)) {
+ struct pwm_chip *chip;
+
+ chip = devm_pwmchip_alloc(dev, ADT7470_PWM_COUNT, 0);
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ chip->ops = &adt7470_pwm_ops;
+ pwmchip_set_drvdata(chip, data);
+
+ err = devm_pwmchip_add(dev, chip);
+ if (err)
+ return dev_warn_probe(dev, err, "failed to register PWM chip\n");
+ }
+
data->auto_update = kthread_run(adt7470_update_thread, client, "%s",
dev_name(hwmon_dev));
if (IS_ERR(data->auto_update))
--
2.55.0
^ permalink raw reply related
* [PATCH v2 4/6] hwmon: (adt7470) Add ADT7470_PWM_MAX macro
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm
In-Reply-To: <20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com>
Instead of a magic 255, use a macro to refer to it.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
drivers/hwmon/adt7470.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index 77e7be692790..d881609c99aa 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -100,6 +100,7 @@ static const unsigned short normal_i2c[] = { 0x2C, 0x2E, 0x2F, I2C_CLIENT_END };
#define ADT7470_REG_FAN_MAX(x) (ADT7470_REG_FAN_MAX_BASE_ADDR + ((x) * 2))
#define ADT7470_PWM_COUNT 4
+#define ADT7470_PWM_MAX 255
#define ADT7470_REG_PWM(x) (ADT7470_REG_PWM_BASE_ADDR + (x))
#define ADT7470_REG_PWM_MAX(x) (ADT7470_REG_PWM_MAX_BASE_ADDR + (x))
#define ADT7470_REG_PWM_MIN(x) (ADT7470_REG_PWM_MIN_BASE_ADDR + (x))
@@ -829,7 +830,7 @@ static int adt7470_pwm_write(struct device *dev, u32 attr, int channel, long val
switch (attr) {
case hwmon_pwm_input:
- val = clamp_val(val, 0, 255);
+ val = clamp_val(val, 0, ADT7470_PWM_MAX);
mutex_lock(&data->lock);
data->pwm[channel] = val;
err = regmap_write(data->regmap, ADT7470_REG_PWM(channel),
@@ -887,7 +888,7 @@ static ssize_t pwm_max_store(struct device *dev,
if (kstrtol(buf, 10, &temp))
return -EINVAL;
- temp = clamp_val(temp, 0, 255);
+ temp = clamp_val(temp, 0, ADT7470_PWM_MAX);
mutex_lock(&data->lock);
data->pwm_max[attr->index] = temp;
@@ -922,7 +923,7 @@ static ssize_t pwm_min_store(struct device *dev,
if (kstrtol(buf, 10, &temp))
return -EINVAL;
- temp = clamp_val(temp, 0, 255);
+ temp = clamp_val(temp, 0, ADT7470_PWM_MAX);
mutex_lock(&data->lock);
data->pwm_min[attr->index] = temp;
--
2.55.0
^ permalink raw reply related
* [PATCH v2 3/6] hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm, sashiko-bot
In-Reply-To: <20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com>
When userspace configures 'auto_update_interval' to 0 via sysfs, the
background kthread executes schedule_timeout_interruptible(0), which
returns immediately.
If 'num_temp_sensors' is concurrently or previously set to 0, the
msleep_interruptible() delay inside adt7470_read_temperatures() also
becomes 0. This combination forces the background thread into a tight,
unbounded busy-loop, hogging the CPU and flooding the I2C bus with a
continuous stream of transactions.
Fix this vulnerability by raising the lower limit of the clamp_val in
auto_update_interval_store() from 0 to 500 milliseconds. This guarantees
a reasonable minimum sleep window between sensor updates, protecting the
system from intentional or accidental I2C bus denial of service.
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org
Fixes: 89fac11cb3e7 ("adt7470: make automatic fan control really work")
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
drivers/hwmon/adt7470.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index 481d51617f4b..77e7be692790 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -509,7 +509,7 @@ static ssize_t auto_update_interval_store(struct device *dev,
if (kstrtol(buf, 10, &temp))
return -EINVAL;
- temp = clamp_val(temp, 0, 60000);
+ temp = clamp_val(temp, 500, 60000);
mutex_lock(&data->lock);
data->auto_update_interval = temp;
--
2.55.0
^ permalink raw reply related
* [PATCH v2 2/6] hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm, sashiko-bot
In-Reply-To: <20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com>
During adt7470_read_temperatures(), the driver temporarily switches
the PWM channels to manual mode, performs the temperature collection,
and then restores the original configuration registers.
However, if an I2C transaction fails at any point after entering manual
mode, the function aborts and returns immediately. This leaves the
configuration registers un-restored, permanently trapping the fans in
manual mode.
Introduce a recovery path to ensure that the original PWM configuration
registers are always restored, even when intermediate I2C operations
fail.
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org
Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap")
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
drivers/hwmon/adt7470.c | 40 +++++++++++++++++++++++++++++-----------
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index 664349756dc2..481d51617f4b 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -205,11 +205,12 @@ static inline int adt7470_write_word_data(struct adt7470_data *data, unsigned in
/* Probe for temperature sensors. Assumes lock is held */
static int adt7470_read_temperatures(struct adt7470_data *data)
{
- unsigned long res;
+ struct device *dev = regmap_get_device(data->regmap);
+ u8 pwm[ADT7470_FAN_COUNT];
unsigned int pwm_cfg[2];
- int err;
+ unsigned long res;
+ int err, err2;
int i;
- u8 pwm[ADT7470_FAN_COUNT];
/* save pwm[1-4] config register */
err = regmap_read(data->regmap, ADT7470_REG_PWM_CFG(0), &pwm_cfg[0]);
@@ -233,19 +234,19 @@ static int adt7470_read_temperatures(struct adt7470_data *data)
err = regmap_update_bits(data->regmap, ADT7470_REG_PWM_CFG(2),
ADT7470_PWM_AUTO_MASK, 0);
if (err < 0)
- return err;
+ goto out_restore;
/* write pwm control to whatever it was */
err = regmap_bulk_write(data->regmap, ADT7470_REG_PWM(0), &pwm[0],
ADT7470_PWM_COUNT);
if (err < 0)
- return err;
+ goto out_restore;
/* start reading temperature sensors */
err = regmap_update_bits(data->regmap, ADT7470_REG_CFG,
ADT7470_T05_STB_MASK, ADT7470_T05_STB_MASK);
if (err < 0)
- return err;
+ goto out_restore;
/* Delay is 200ms * number of temp sensors. */
res = msleep_interruptible((data->num_temp_sensors >= 0 ?
@@ -256,13 +257,30 @@ static int adt7470_read_temperatures(struct adt7470_data *data)
err = regmap_update_bits(data->regmap, ADT7470_REG_CFG,
ADT7470_T05_STB_MASK, 0);
if (err < 0)
- return err;
+ goto out_restore;
+out_restore:
/* restore pwm[1-4] config registers */
- err = regmap_write(data->regmap, ADT7470_REG_PWM_CFG(0), pwm_cfg[0]);
- if (err < 0)
- return err;
- err = regmap_write(data->regmap, ADT7470_REG_PWM_CFG(2), pwm_cfg[1]);
+ err2 = regmap_write(data->regmap, ADT7470_REG_PWM_CFG(0), pwm_cfg[0]);
+ if (err2 < 0) {
+ dev_warn_ratelimited(dev,
+ "failed to restore PWM{1,2} config (%d)\n",
+ err2);
+
+ if (!err)
+ err = err2;
+ }
+
+ err2 = regmap_write(data->regmap, ADT7470_REG_PWM_CFG(2), pwm_cfg[1]);
+ if (err2 < 0) {
+ dev_warn_ratelimited(dev,
+ "failed to restore PWM{3,4} config (%d)\n",
+ err2);
+
+ if (!err)
+ err = err2;
+ }
+
if (err < 0)
return err;
--
2.55.0
^ permalink raw reply related
* [PATCH v2 1/6] dt-bindings: hwmon: add binding for adi,adt7470
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm
In-Reply-To: <20260717-adt7470_thermalzone-v2-0-a55147958fad@gmail.com>
The Analog Devices ADT7470 is a temperature monitor and PWM fan
controller. It supports up to 10 external temperature sensors and
up to 4 PWM fan outputs.
Add the YAML device tree binding documentation for it. This includes
support for the thermal framework by defining the "#thermal-sensor-cells"
property, and support for the PWM subsystem by defining the "#pwm-cells"
property.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
.../devicetree/bindings/hwmon/adi,adt7470.yaml | 62 ++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
new file mode 100644
index 000000000000..14bb6359c91f
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,adt7470.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADT7470 hwmon sensor
+
+maintainers:
+ - Luiz Angelo Daros de Luca <luizluca@gmail.com>
+
+description: |
+ The ADT7470 is a temperature monitor and multiple PWM outputs.
+ It supports monitoring up to 10 external temperature sensors and controlling
+ up to four fans.
+
+properties:
+ compatible:
+ const: adi,adt7470
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 2
+ description: |
+ Number of cells in a PWM specifier.
+ - The first cell is the PWM channel (0 to 3).
+ - The second cell is the PWM period in nanoseconds.
+
+ "#thermal-sensor-cells":
+ const: 1
+ description: |
+ Number of cells required to uniquely identify the temperature sensors.
+ Valid index values are 0 to 9, corresponding to temp1 through temp10.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adt7470: hwmon@2f {
+ compatible = "adi,adt7470";
+ reg = <0x2f>;
+ #pwm-cells = <2>;
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
+ fan0 {
+ compatible = "pwm-fan";
+ /* Connects to PWM channel 0 with a 50000 ns (20 kHz) period */
+ pwms = <&adt7470 0 50000>;
+ cooling-levels = <0 100 150 255>;
+ };
--
2.55.0
^ permalink raw reply related
* [PATCH v2 0/6] hwmon: (adt7470) Add thermal zone and PWM provider support
From: Luiz Angelo Daros de Luca @ 2026-07-17 20:59 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong,
Uwe Kleine-König
Cc: linux-hwmon, devicetree, linux-kernel, Luiz Angelo Daros de Luca,
linux-pwm, sashiko-bot
The ADT7470 is a temperature monitor and PWM fan controller capable of
monitoring up to 10 external temperature sensors and controlling up to 4
PWM outputs.
Currently, the driver exposes these sensors and PWM controls solely via
the standard hwmon sysfs interface. This patch series integrates the
ADT7470 driver with the kernel's thermal and PWM subsystems. This allows
its temperature sensors to be referenced by Device Tree thermal zones,
and its PWM channels to be consumed by generic Device Tree nodes (such
as "pwm-fan").
Patch 1 adds the YAML device tree binding documentation.
Patch 2 and 3 fix two pre-existing bugs found while testing this series
(fans stuck in manual mode after an I2C error, and a
busy-loop/I2C-flooding condition when auto_update_interval or
num_temp_sensors is 0).
Patch 4 performs a minor refactoring to introduce the ADT7470_PWM_MAX
macro.
Patch 5 registers the 4 PWM channels as a generic PWM provider.
Patch 6 registers the external temperature sensors as optional thermal
zones.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
Changes in v2:
- Fixed 2 previous bugs uncovered by Sashiko-bot during review.
- Dropped the thermal cooling device registration for the PWM channels.
- Implemented generic PWM provider support using the PWM subsystem.
- Updated Kconfig to safely handle the PWM subsystem dependency (depends on PWM || PWM=n).
- Updated Device Tree bindings to require #pwm-cells instead of #cooling-cells.
- Link to v1: https://patch.msgid.link/20260716-adt7470_thermalzone-v1-0-cc55ef35edde@gmail.com
To: Guenter Roeck <linux@roeck-us.net>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: de Luca <luizluca@gmail.com>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
To: Andrew Morton <akpm@linux-foundation.org>
To: "Darrick J. Wong" <djwong@us.ibm.com>
To: Uwe Kleine-König <ukleinek@kernel.org>
Cc: linux-hwmon@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
---
Luiz Angelo Daros de Luca (6):
dt-bindings: hwmon: add binding for adi,adt7470
hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors
hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread
hwmon: (adt7470) Add ADT7470_PWM_MAX macro
hwmon: (adt7470) Register as a PWM provider
hwmon: (adt7470) Add thermal zone sensor support
.../devicetree/bindings/hwmon/adi,adt7470.yaml | 62 +++++++++++
drivers/hwmon/Kconfig | 1 +
drivers/hwmon/adt7470.c | 118 ++++++++++++++++++---
3 files changed, 166 insertions(+), 15 deletions(-)
---
base-commit: ca078d004cf58137bcf8cb24a8b271397431ba58
change-id: 20260716-adt7470_thermalzone-59a102278d72
Best regards,
--
Luiz Angelo Daros de Luca <luizluca@gmail.com>
^ 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