* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: David Lechner @ 2026-06-16 15:21 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <DJA1J8D91ESA.2XU7OCVKN7LXU@gmail.com>
On 6/15/26 7:18 PM, Kurt Borja wrote:
> Hi David,
>
> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
>> This adds support for TI ADS112C14 and ADS122C14 ADC chips.
>>
>> The closest thing we've seen to this in the kernel already is ads124s08.
>> However, that has a completely different register map and the DT
>> bindings are incomplete and the driver is extremely basic. So I've just
>> started from scratch here.
>>
>> We've also had a similar submission recently for ADS1220 [1]. That chip
>> is in a similar situation to ads124s08 in that it has a different
>> register map (but the submitted DT bindings are better than the ones for
>> ads124s08, even if still a bit incomplete). And literally as I was
>> writing the previous sentence, another series [2] was sent for yet
>> another similar family of chips (ADS1262). That one is even more complex
>> in the feature set than the ones I am working on. I was going to polish
>> up the driver a bit more before submitting it, but now it seems more
>> urgent to coordinate with the other two series to align on how we would
>> like to handle all of these.
>>
>> [1]: https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>> [2]: https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
>>
>> All of these chips have in common that they are designed for use with
>> RTDs and thermocouples and so they look very similar to each other in
>> terms of wiring and feature set, even if the register maps are
>> different. They are in the gray area where we could either keep them
>> separate because they are just different enough, or we could do like
>> we've done before with ad_sigma_delta and have a bit of an abstraction
>> layer for the register differences and otherwise try to share as much
>> code as possible. Normally, I would lean towards keeping them separate,
>> but in this case, I'm considering trying to share code because the
>> devicetree bindings for the inputs is complex and is going to be mostly
>> the same across all of these chips.
>
> The channel configuration is indeed very similar for the three chips.
> All three have IDAC, BOC and VREF configurations.
Hmm... I forgot to include the burnout current in the DT bindings. Following
the channel = "conditions for measurement" pattern that I have set out here
I guess that would mean that we would need to have the same inputs twice
when using the burnout. One "channel" would be the one used to do a "precision"
measurement and the other would be the one to do open/short circuit detection.
i2c {
#address-cells = <1>;
#size-cells = <0>;
adc@40 {
compatible = "ti,ads112c14";
reg = <0x40>;
avdd-supply = <&avdd>;
dvdd-supply = <&dvdd>;
refp-supply = <&avdd>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0>;
diff-channels = <1>, <2>;
excitation-channels = <0>, <3>;
excitation-current-microamp = <500>;
current-chopping;
ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
label = "rtd-precision";
};
channel@1 {
reg = <0>;
diff-channels = <1>, <2>;
excitation-channels = <0>, <3>;
excitation-current-microamp = <500>;
burnout-current-nanoamp = <1000>;
ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
label = "rtd-diagnostic";
};
};
};
>
>>
>> If we decide to go the route of sharing code, we could still merge this
>> series as-is and then do the refactoring to add the abstraction layer in
>> a follow-up series that also adds support for the first of the other
>> chips.
>
> Do you have a proposal of how such an abstraction would look like? I do
> like the idea of abstracting the firmware parsing, scales and shared
> calculations.
As mentioned, it would look a bit like the ad_sigma_delta ADC driver.
Basically, each chip (family with same registers) would still have it's
own driver that include the chip-specific const info structs. In this
case, these would also include function pointers for all of the functions
that need to access registers. And there will be lots of supports_... bool
flags for the shared code to use.
>
>>
>> This series includes just basic support for reading single measurements
>> from the ADC and gain selection via the scale attribute. I plan to
>> follow this up with additional series to add support for buffered reads,
>> filtering/oversampling configuration, event support, gpio controller
>> support and perhaps a few other things that are slipping my mind right
>> now.
>>
>> The most interesting part about this (that I alluded to above) is the
>> way channels are handled. These are multipling ADCs with differential
>> and single-ended inputs. But what sets them apart from other similar
>> chips is that since they are designed for use with RTDs, there can also
>> be a current output required to excite the RTD and this current output
>> might be different for different channels. So the way I conceptualized
>> the channels is that the devicetree specifies the conditions needed
>> to take a particular measurement rather than being purely a physical
>> channel.
>>
>> This makes things more flexible, but does make the driver a bit more
>> complex. For example, knowing when the current output needs to be
>> enabled or disabled. For now, I have chosen a lazy-enable where they
>> are not turned on until the first measurement is taken that requires
>> them, but then they stay on until another measurement is taken that
>> doesn't require them. This can lead to some oddness with the diagnostic
>> channels that may be measuring something that indirectly requires the
>> current output (i.e. the external reference voltage when it is connected
>> to a resistor rather than a power supply). This means you need to take
>> a measurement that requires the current output to be enabled before the
>> diagnostic channels will give accurate readings.
>
> This is the same approach I took around the BOC, it feels kinda hacky
> but it makes sense. Just an idea I thought about just now: What if we
> have an additional write-only "_enable" sysfs attribute for these
> channels?
I would not want to make a write-only attribute, we always want to be
able to read back what the current state is.
Do you mean an _enable for just the BOC? I think I would do it like I
suggested above instead.
>
> The approach I took for the IDAC was to have a single configuration that
> it's enabled for all channels. This makes some sense in my device when
> thinking about optimal software sequencial reads, because of the
> register layout, but I also see the value in having per-channel IDAC
> configuration. I think I will take your approach, so we have the same
> channel configuration around this.
There are only two IDACs but on chips with 8 AIN pins we could have two
RTDs wired up and if both require 2 IDACs, then we can't have a fixed
setting for the IDACs. This is why I made it per-channel.
>
> Have you thought about how to implement the BOC? In the ADS1262 the
> feature can be found "Sensor Bias". What I did was add per channel DT
> properties for this too.
See above.
>
> Another question. When you implement power management in the future,
> will you enable autosuspend? IDAC currents will be lost if autosuspend
> is enabled. Is this acceptable? In my case I did enable autosuspend, but
> I have some doubts about this.
I don't like to implement power management unless I have an application
that actually requires it. Otherwise, I consider it premature optimization.
It is difficult to know if we would be implementing it in a way that is
actually useful for a real-world use case. These chips seem like they
would mostly be used in an industrial setting, not in battery powered
applications, so I'm not sure anyone is going to worry about saving a few
milliamps.
>
>>
>> I have also pushed a branch to [3] that contains the start of some
>> documentation for this driver that can give some more insight into how
>> the implementation works. It still needs some work and also documents
>> some things that haven't been implemented yet, so I haven't included it
>> in this series yet.
>>
>> [3]: https://github.com/dlech/linux/blob/b4/iio-adc-ti-ads122c14/Documentation/iio/ads112c14.rst
>>
>> Signed-off-by: David Lechner <dlechner@baylibre.com>
>> ---
>> David Lechner (TI) (4):
>> dt-bindings: iio: adc: add ti,ads122c14
>> iio: adc: add ti-ads112c14 driver
>> iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel
>> iio: adc: ti-ads112c14: add measurement channel support
>>
>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++
>> MAINTAINERS | 8 +
>> drivers/iio/adc/Kconfig | 12 +
>> drivers/iio/adc/Makefile | 1 +
>> drivers/iio/adc/ti-ads112c14.c | 1053 ++++++++++++++++++++
>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>> 6 files changed, 1309 insertions(+)
>> ---
>> base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
>> change-id: 20260514-iio-adc-ti-ads122c14-d0b92479334e
>>
>> Best regards,
>> --
>> David Lechner (TI) <dlechner@baylibre.com>
>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner @ 2026-06-16 15:22 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <DJA1PXNS9SFP.VAURJH1MR9BK@gmail.com>
On 6/15/26 7:26 PM, Kurt Borja wrote:
> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
>> Add new bindings for ti,ads122c14 and similar devices.
>>
>> This is an ADC that is primarily intended for use with temperature
>> sensors. There are a few unusual properties because of this. In
>> particular, the reference voltage source and current output requirements
>> can be different for each measurement, so these are included in the
>> channel bindings.
>>
>> The REFP/REFN reference voltage is usually just connected to a resistor
>> that is being driven by the ADC's current outputs, so there is special
>> property for this case rather than requiring a regulator to be defined
>> to represent that.
>>
>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>> have preferred an enum of strings).
>>
>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>> ---
>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
>> MAINTAINERS | 7 +
>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>> 3 files changed, 242 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>> new file mode 100644
>> index 000000000000..dc7f37cad772
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>> @@ -0,0 +1,224 @@
>
> [...]
>
>> +patternProperties:
>> + ^channel@[0-7]$:
>> + $ref: adc.yaml
>> +
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + reg:
>> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
>> +
>> + single-channel:
>> + maximum: 7
>> +
>> + diff-channels:
>> + items:
>> + maximum: 7
>> +
>> + bipolar:
>> + description:
>> + Set this flag if the differential input can be negative.
>> +
>> + excitation-channels:
>
> I noticed this doesn't have the "ti," prefix. Is your plan to add this
> to adc.yaml?
I hadn't really though about it. I guess it could make sense.
>
> Also, do you think excitation-pins might be a better name?
I used -channels to match e.g. diff-channels. The same values apply to
both properties.
>
>> + description: AINx pins used as current output.
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 1
>> + maxItems: 2
>> + items:
>> + maximum: 7
>> +
>> + excitation-current-microamp:
>> + description: The current output of the excitation channels in microamps.
>> + minimum: 1
>> + maximum: 1000
>> +
>> + current-chopping:
>
> If you agree with the above comment, I think this too should be added.
> In that case, can we call this something like
> excitation-current-rotation for less ambiguity?
I think excitation-channel-rotation would be fine.
>
> I say this because my device has an "IDAC rotation mode", but it also has
> a "Chop Mode" which rotates analog inputs and averages consecutive
> conversions.
And this one sounds like it could be named input-channel-rotation. Would
this also need a 2nd set of single-channel or diff-channels to the extra
inputs?
>
>> + $ref: /schemas/types.yaml#/definitions/flag
>> + description:
>> + If provided, the two excitation channels are to be used with current
>> + chopping enabled.
>> +
>> + ti,vref-source:
>> + description: |
>> + Indicates the source for the reference voltage for this channel.
>> + 0 - Internal 2.5V reference
>> + 1 - Internal 1.25V reference
>> + 2 - External reference (REFP-REFN)
>> + 3 - AVDD as reference
>> +
>> + For convenience, macros for these values are available in
>> + dt-bindings/iio/adc/ti,ads112c14.h.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + maximum: 3
>> + default: 0
>> +
>> + dependencies:
>> + excitation-channels: [ excitation-current-microamp ]
>> + excitation-current-microamp: [ excitation-channels ]
>> + current-chopping: [ excitation-channels ]
>> +
>> + oneOf:
>> + - required: [ single-channel ]
>> + - required: [ diff-channels ]
>
> [...]
>
^ permalink raw reply
* Re: [PATCH 4/4] iio: adc: ti-ads112c14: add measurement channel support
From: David Lechner @ 2026-06-16 15:30 UTC (permalink / raw)
To: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260615-iio-adc-ti-ads122c14-v1-4-e6bdadf7cb2b@baylibre.com>
On 6/15/26 5:00 PM, David Lechner (TI) wrote:
> Add support for parsing devicetree properties for measurement channels
> and doing direct reads on these.
>
> There are quite a lot of conditions that have to be met for each
> measurement to be made, so quite a bit of state and algorithms are
> required to handle it.
>
> Channels are created dynamically since the number of possibilities is
> unreasonably large.
>
...
> static void ads112c14_populate_tables(struct ads112c14_data *data)
> {
> u32 vref_uV, fsr_bits;
> - int i;
> +
> + for (u32 i = 0; i < data->num_measurements; i++) {
> + struct ads112c14_measurement *measurement = &data->measurements[i];
> +
> + switch (measurement->vref_source) {
> + case ADS112C14_VREF_SOURCE_EXTERNAL:
> + if (data->ext_ref_ohms)
> + vref_uV = measurement->idac_current_uA *
> + measurement->iadc_count * data->ext_ref_ohms;
One thing I am considering is that if we have a resistor between
REFP and REFN rather than a voltage supply, then we should consider
the channel IIO_RESISTANCE rather than IIO_VOLTAGE.
In this case, the user doesn't care about voltage at all, but rather
the ratio of the REFP-REFN resistor to the measured resistance.
^ permalink raw reply
* Re: [PATCH 6/7] riscv: dts: eswin: add I2C controller support
From: Conor Dooley @ 2026-06-16 15:31 UTC (permalink / raw)
To: Pinkesh Vaghela
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, Min Lin, Yulin Lu,
Samuel Holland, Darshan Prajapati, Pritesh Patel
In-Reply-To: <SJ2PR04MB8896A5877CCFC177FA5D5A9583E52@SJ2PR04MB8896.namprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
On Tue, Jun 16, 2026 at 11:57:33AM +0000, Pinkesh Vaghela wrote:
> On Mon, Jun 15, 2026 at 10:05 PM +0530, Conor Dooley wrote:
> > On Mon, Jun 15, 2026 at 05:50:15PM +0530, Pinkesh Vaghela wrote:
> > > + i2c0: i2c@50950000 {
> > > + compatible = "snps,designware-i2c";
> >
> > Missing a soc-specific compatible here for all i2c controllers.
>
> We are using generic DesignWare I2C driver for all I2C controllers with
> no changes required in the driver. Do we still need to add soc-specific
> compatible for all i2c controllers?
Yes. Just use "snps,designware-i2c" as a fallback.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Luca Leonardo Scorcia @ 2026-06-16 15:32 UTC (permalink / raw)
To: Rob Herring
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260616133918.GA2335264-robh@kernel.org>
> > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
>
> Nothing is using this so it is a dead file that doesn't get tested.
Hi, it's not referenced as the dtsi inclusion was removed in the
original patch from 2019 for an easier merging of support for mt8516
pumpkin boards [1][2].
If you prefer in the next revision I can add another patch to readd it
to the existing pumpkin board.
I am working on a few boards with MT8167 (Xiaomi Mi Smart Clock,
Lenovo Smart Clock 2, Sony Playstation Classic) that reference it and
these have been used to test it locally too.
[1] https://lore.kernel.org/linux-mediatek/20190323211612.860-25-fparent@baylibre.com/
[2] https://lore.kernel.org/linux-mediatek/20200229170401.1287324-2-fparent@baylibre.com/
Thank you
Luca
^ permalink raw reply
* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Conor Dooley @ 2026-06-16 15:35 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+4EquYcUHEnoq0N_p7vCmDpPONEhVrmAfO1eX_RNMYbQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
On Mon, Jun 15, 2026 at 07:09:39PM +0200, Luca Leonardo Scorcia wrote:
> Hi,
> yes, sorry about that, series v6 has been superseded by v7 (I replied
> to the thread and marked it as archived in patchwork, please let me
> know if I have to do something else to mark it as obsolete).
> Sashiko was correct, the regulators node is required for this device.
I have no idea what regulator node you're referring to here or what
patchwork. Please don't delete context when you reply.
If it's the devicetree patchwork I don't you need to do anything.
> Sashiko also has suggestions for v7, a few pre existing issues and a
> few nits here and there but some are actual improvements. One bit that
> caught my eye is the use of the modeset register in the
> mt6392_ldo_get_mode function. I have to double check that with the
> data sheet and the android kernel sources. Not sure if I can do that
> before next week though.
>
> Is there any way I can trigger a Sashiko review before sending patches
> to the ML?
I don't know sorry.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access
From: Frank Li @ 2026-06-16 15:36 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel, Frieder Schrempf
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-3-cb7f3698c3e6@kontron.de>
On Tue, Jun 16, 2026 at 01:52:18PM +0200, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> The ELE S400 API provides read and write access to the OCOTP fuse
> registers. This adds the necessary API functions imx_se_read_fuse()
> and imx_se_write_fuse() to be used by other drivers such as the
> OCOTP S400 NVMEM driver.
>
> This is ported from the downstream vendor kernel.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> ---
> drivers/firmware/imx/ele_base_msg.c | 122 ++++++++++++++++++++++++++++++++++++
> drivers/firmware/imx/ele_base_msg.h | 6 ++
> include/linux/firmware/imx/se_api.h | 3 +
> 3 files changed, 131 insertions(+)
>
...
> +++ b/include/linux/firmware/imx/se_api.h
> @@ -11,4 +11,7 @@
> #define SOC_ID_OF_IMX8ULP 0x084d
> #define SOC_ID_OF_IMX93 0x9300
>
> +int imx_se_read_fuse(void *se_if_data, uint16_t fuse_id, u32 *value);
> +int imx_se_write_fuse(void *se_if_data, uint16_t fuse_id, u32 value);
> +
This API should implement in fuse drivers. Other consume should use standard
fuse API to get value. If put here, it may bypass fuse driver.
Frank
> #endif /* __SE_API_H__ */
>
> --
> 2.54.0
>
>
^ permalink raw reply
* Re: [PATCH 2/4] iio: adc: add ti-ads112c14 driver
From: David Lechner @ 2026-06-16 15:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <ajD8Gxkp66kkDflE@ashevche-desk.local>
On 6/16/26 2:32 AM, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 05:00:00PM -0500, David Lechner (TI) wrote:
>> Add a new driver for the TI ADS112C14/ADS122C14 ADC chips.
>>
>> This first step is adding a very basic driver that only supports power
>> on/reset and reading the system monitor channels.
>>
>> ADS112C14_SYS_MON_CHANNEL_SHORT is the last channel rather than being in
>> logical order by address to keep the voltage channels together and in
>> case we find we need to add variants of this channel with different
>> voltage reference later.
>
> ...
>> +static int ads112c14_read_label(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan, char *label)
>> +{
>> + const char *label_source;
>
> I don't see the need of having this. Can't be returned directly?
Then this would have to be split into two functions. One to return
it directly and one to do the sysfs_emit(). I don't think it is
worth it.
>
>> + /* System monitor channels. */
>> + switch (chan->channel) {
>> + case ADS112C14_SYS_MON_CHANNEL_TEMP:
>> + label_source = "Internal temperature sensor";
>> + break;
>> + case ADS112C14_SYS_MON_CHANNEL_EXT_REF:
>> + label_source = "External reference";
>> + break;
>> + case ADS112C14_SYS_MON_CHANNEL_AVDD:
>> + label_source = "AVDD";
>> + break;
>> + case ADS112C14_SYS_MON_CHANNEL_DVDD:
>> + label_source = "DVDD";
>> + break;
>> + case ADS112C14_SYS_MON_CHANNEL_SHORT:
>> + label_source = "Internal short";
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + return sysfs_emit(label, "%s\n", label_source);
>> +}
>
>> + /*
>> + * The reset may cause an -EREMOTEIO error because of failing to get the
>> + * I2C ACK at the end of the message. The device still gets reset.
>> + */
>> + if (ret != -EREMOTEIO)
>> + return ret;
>
> I would do it separately as
>
> if (ret == -EREMOTEIO)
> /* ...big comment here... */
> return 0;
We should not return early here. We just continue with the rest
of the function as normal. So I think the way I had it was
simplest. Otherwise we would need a goto or something like that.
> if (ret) // which is regular pattern and doesn't need any comment.
> return ret;
>
>> + fsleep(ADS112C14_DELAY_RESET_us);
>> +
>> + ret = regmap_read(data->regmap, ADS112C14_REG_STATUS_MSB, ®_val);
>> + if (ret)
>> + return ret;
>> +
>> + if (FIELD_GET(ADS112C14_STATUS_MSB_RESETN, reg_val))
>> + return dev_err_probe(dev, -EIO, "reset failed\n");
>> +
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: Add GPIO-locked fixed clock
From: Conor Dooley @ 2026-06-16 15:39 UTC (permalink / raw)
To: Brian Masney
Cc: V.Yurkov.EXT, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-clk,
devicetree, Vyacheslav Yurkov
In-Reply-To: <ajB2PhmxvdtsXNnm@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]
On Mon, Jun 15, 2026 at 06:01:34PM -0400, Brian Masney wrote:
> Hi Vyacheslav,
>
> On Wed, Jun 03, 2026 at 11:16:42AM +0000, Vyacheslav Yurkov via B4 Relay wrote:
> > From: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> >
> > Some hardware designs provide fixed-frequency clocks generated outside
> > software control, such as by FPGA-resident PLLs. While the clock rate is
> > fixed, a separate GPIO signal indicates whether the clock source is
> > locked and producing a valid output.
> >
> > Describe a GPIO-locked fixed clock provider that exposes a fixed-rate
> > clock whose availability depends on one or more GPIO lock-status
> > signals.
> >
> > Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
> > Signed-off-by: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> > ---
> > .../bindings/clock/gpio-locked-fixed-clock.yaml | 70 ++++++++++++++++++++++
> > 1 file changed, 70 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml
> > new file mode 100644
> > index 000000000000..9106b800b673
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml
> > @@ -0,0 +1,70 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/gpio-locked-fixed-clock.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO Locked Fixed Clock
> > +
> > +maintainers:
> > + - Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> > +
> > +description: |
> > + Provides a clock output whose availability depends on a set of
> > + prerequisite conditions. These conditions include the presence of
> > + one or more parent clocks and the asserted state of one or more
> > + GPIO lock indicators. An example of such clocks is FPGA clock that
> > + are outside CPU control, with the lock status exposed through GPIO
> > + signal.
> > +
> > + The output clock is considered available only when all configured
> > + prerequisites are satisfied.
>
> I'm stepping outside my usual review of just the clk drivers. Krzysztof
> in v1 and v2 asked for more detailed hardware explanation. This feels to
> me like this is a policy that says to not use these clocks until the
> GPIO says they are ready. My gut feeling is that details like this
> should live in a clk driver instead of a dt-binding.
>
> Alternatively, if this is generic enough, then could
> Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml be
> extended?
FWIW this came up in an earlier revision:
https://lore.kernel.org/all/20260407-fling-scouring-dbe2141cc79b@spud/
IMO it's an inverted gpio-gate-clock, where the gpio is an input rather
than an output. I suppose you could extend gpio-gate-clock with it and
have mutually exclusive enable-gpios and status-gpios?
>
> Brian
>
>
> > +
> > +properties:
> > + compatible:
> > + const: gpio-locked-fixed-clock
> > +
> > + "#clock-cells":
> > + const: 0
> > +
> > + clocks:
> > + description: Input clocks whose validity is monitored by this provider.
> > +
> > + clock-output-names:
> > + description: Names of the clock provided by this controller.
> > + maxItems: 1
> > +
> > + locked-gpios:
> > + description: |
> > + GPIOs to check the lock state.
> > + minItems: 1
> > + maxItems: 32
> > +
> > +required:
> > + - compatible
> > + - "#clock-cells"
> > +
> > +anyOf:
> > + - required:
> > + - clocks
> > + - required:
> > + - locked-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + clk_gpio_locked: gpio-locked-fixed-clock {
> > + compatible = "gpio-locked-fixed-clock";
> > + #clock-cells = <0>;
> > +
> > + clocks = <&clk0 0>, <&pll 0>;
> > +
> > + locked-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>,
> > + <&gpio0 5 GPIO_ACTIVE_HIGH>,
> > + <&gpio1 2 GPIO_ACTIVE_LOW>;
> > +
> > + clock-output-names = "clkout0";
> > + };
> >
> > --
> > 2.34.1
> >
> >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Conor Dooley @ 2026-06-16 15:41 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260616-mt6323-adc-v3-1-1c27c588185d@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
On Tue, Jun 16, 2026 at 05:15:39PM +0300, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
> temperature, and other internal measurements. The IP block is not
> register-compatible with mt6359
Cut this sentence here, whether or not it uses the same driver may
differ per OS.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Add the devicetree binding documentation and the associated header file
> defining the ADC channel constants.
>
> Also change the description to 'MT6350 series and similar' because
> the binding already includes more than mt635x series PMICs.
>
> Finally, add the MAINTAINERS entry for the header with ADC constants.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: iio: st,st-sensors: add st,fullscale-milligauss
From: Conor Dooley @ 2026-06-16 15:41 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij,
linux-iio, linux-kernel, llvm, devicetree
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-2-063edcf74e60@herrie.org>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: Conor Dooley @ 2026-06-16 15:42 UTC (permalink / raw)
To: Siratul Islam
Cc: jic23, robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260616114942.37241-3-siratul.islam@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/10] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
From: Conor Dooley @ 2026-06-16 15:44 UTC (permalink / raw)
To: Biju
Cc: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, devicetree,
linux-kernel, linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260616104459.410743-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]
On Tue, Jun 16, 2026 at 11:44:43AM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document Renesas RZ/G3L (r9a08g046) USB PHY controller bindings.
> The RZ/G3L USB PHY block is similar to RZ/G3S but differs in that each
> port has its own OTG controller, whereas RZ/G3S only has one on port 1.
> To reflect this, RZ/G3L uses a regulators sub-node with per-port vbus0
> and vbus1 entries instead of the single regulator-vbus property used
> by other compatible SoCs.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v1->v2:
> * Updated commit description.
> * Added enum instead of const in the compatible section.
> * Dropped regulator1-vbus and added a regulators group node.
> * Updated schema check.
> ---
> .../reset/renesas,rzg2l-usbphy-ctrl.yaml | 49 +++++++++++++++++--
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> index c83469a1b379..12da48d069e5 100644
> --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> @@ -16,13 +16,17 @@ description:
> properties:
> compatible:
> oneOf:
> + - items:
> + - enum:
> + - renesas,r9a08g045-usbphy-ctrl # RZ/G3S
> + - renesas,r9a08g046-usbphy-ctrl # RZ/G3L
Looks fine, other than the fact that the "- items: - enum:" construct is
the same as just having "- enum".
pw-bot: changes-requested
Fix that problem, and
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v5 1/6] dt-bindings: iio: add Open Sensor Fusion device
From: Conor Dooley @ 2026-06-16 15:53 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-2-kimjinseob88@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6337 bytes --]
On Tue, Jun 16, 2026 at 04:22:37PM +0900, Jinseob Kim wrote:
> Add the generic Open Sensor Fusion device binding for a serdev-attached
> IIO sensor aggregation hub, and document the opensensorfusion vendor
> prefix.
>
> The opensensorfusion,osf compatible describes the generic Open Sensor
> Fusion host interface. OSF GREEN is not the Linux compatible identity.
> Likewise, OSF0 is the current wire magic and a wire-format detail, not
> the Linux driver identity.
>
> The fixed OSF frame header carries protocol_major and protocol_minor at
> fixed offsets. This driver currently supports protocol_major 0.
> protocol_minor changes are intended to remain backward-compatible within
> that fixed header layout. Incompatible wire-format changes require a new
> protocol_major. If a future device cannot expose compatible version
> discovery through the fixed header layout, it will need a different
> compatible.
>
> Require vcc-supply so the driver can enable device power before starting
> communication.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> ---
> .../bindings/iio/opensensorfusion,osf.yaml | 59 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 13 ++++
> 3 files changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> new file mode 100644
> index 000000000..012a07fd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Open Sensor Fusion Sensor Aggregation Hub
> +
> +maintainers:
> + - Jinseob Kim <kimjinseob88@gmail.com>
> +
> +description: |
> + Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
> + protocol data stream over its host interface and may report capabilities and
s/may report/reports/ because mandatory reporting, even if nothing is
actually there, is a requirement for having a compatible describing the
"bus".
> + samples for multiple sensor classes. The Linux driver discovers the actual
s/The Linux driver discovers the actual sensor channels/The actual sensor channels are discovered"
Because although maybe only linux will use this it should not be
specific.
> + sensor channels from OSF capability reports instead of describing those
> + sensors in Device Tree.
> +
> + Open Sensor Fusion is not a generic industry standard. Public project
I would drop this first sentence to be honest.
> + documentation is available at:
> +
> + https://github.com/opensensorfusion
> +
> + The compatible describes the generic Open Sensor Fusion host interface. It
> + is not an OSF GREEN board identity, and it does not encode the OSF0 wire
> + magic. OSF0, protocol_major, and protocol_minor are wire-protocol details
> + exchanged in OSF frames.
I think I move this to the first paragraph and would say something like
| This binding documents the generic Open Sensor Fusion host interface.
|
| Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
| protocol data stream over its host interface and reports capabilities and
| samples for multiple sensor classes. The actual sensor channels are discovered
| at runtime from OSF capability reports instead of describing them in Device
| Tree.
|
| The protocol version is discovered at runtime.
Does that sound about right?
> +
> +allOf:
> + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + const: opensensorfusion,osf
> +
> + vcc-supply:
> + description:
> + Regulator supplying power to the Open Sensor Fusion device.
> +
> +required:
> + - compatible
> + - vcc-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + vcc_sensor: regulator-0 {
> + compatible = "regulator-fixed";
> + regulator-name = "sensor-vcc";
> + };
Drop this node, the tooling fakes one when running the checks. Only keep
nodes that actually form your device here. Same way you don't need to
actually fill out the serial port.
pw-bot: changes-requested
> +
> + serial {
> + sensor {
> + compatible = "opensensorfusion,osf";
> + vcc-supply = <&vcc_sensor>;
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66a..88172d4a4 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1237,6 +1237,8 @@ patternProperties:
> description: OpenPandora GmbH
> "^openrisc,.*":
> description: OpenRISC.io
> + "^opensensorfusion,.*":
> + description: Open Sensor Fusion
> "^openwrt,.*":
> description: OpenWrt
> "^option,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c2c6d7927..2ddefc42d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20011,6 +20011,19 @@ F: Documentation/devicetree/
> F: arch/*/boot/dts/
> F: include/dt-bindings/
>
> +OPEN SENSOR FUSION IIO DRIVER
> +M: Jinseob Kim <kimjinseob88@gmail.com>
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> +F: Documentation/iio/open-sensor-fusion.rst
> +F: drivers/iio/opensensorfusion/Kconfig
> +F: drivers/iio/opensensorfusion/Makefile
> +F: drivers/iio/opensensorfusion/osf_core.*
> +F: drivers/iio/opensensorfusion/osf_iio.*
> +F: drivers/iio/opensensorfusion/osf_protocol.*
> +F: drivers/iio/opensensorfusion/osf_serdev.c
> +F: drivers/iio/opensensorfusion/osf_stream.*
At this stage, only add the binding. The rest should be added when the
files are.
Cheers,
Conor.
> +
> OPENCOMPUTE PTP CLOCK DRIVER
> M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> L: netdev@vger.kernel.org
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: adm1275: ROHM BD12790 hot-swap controller
From: Conor Dooley @ 2026-06-16 15:54 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Wensheng Wang, Ashish Yadav, Kim Seer Paller, Cedric Encarnacion,
Chris Packham, Yuxi Wang, Charles Hsu, ChiShih Tsai, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <ae80a037fa3b03ef5cfb446bf3e9c44efd4f04ec.1781591132.git.mazziesaccount@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: Guenter Roeck @ 2026-06-16 15:55 UTC (permalink / raw)
To: sashiko-reviews, hehuan1; +Cc: robh, devicetree, linux-hwmon, conor+dt
In-Reply-To: <20260611091748.A6EAC1F00898@smtp.kernel.org>
On 6/11/26 02:17, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The IRQ is requested before the PM runtime cleanup action is registered, leading to a possible use-after-disable of the hardware clock in the ISR on driver removal.
> - [Medium] The interrupt handler `eic7700_pvt_hard_isr` does not check the hardware interrupt status bit to verify if the device actually generated the interrupt.
> --
>
> commit 0f4c8aefb83780ee09652639eb2843f01c2baf38
> Author: Huan He <hehuan1@eswincomputing.com>
>
> hwmon: Add Eswin EIC7700 PVT sensor driver
>
> Add support for ESWIN EIC7700 Voltage and Temperature sensor. The driver
> supports temperature and voltage monitoring with polynomial conversion,
> and provides sysfs interface for sensor data access.
>
>> diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
>> new file mode 100644
>> index 0000000000000..3b3aed74c3941
>> --- /dev/null
>> +++ b/drivers/hwmon/eic7700-pvt.c
>
> [ ... ]
>
>> +static irqreturn_t eic7700_pvt_hard_isr(int irq, void *data)
>> +{
>> + struct pvt_hwmon *pvt = data;
>> + int active;
>> + u32 val;
>> +
>> + if (IS_ENABLED(CONFIG_PM)) {
>> + active = pm_runtime_get_if_active(pvt->dev);
>> + if (active <= 0)
>> + return IRQ_NONE;
>> + }
>> +
>> + eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
>> + /*
>> + * Read the data, update the cache and notify a waiter of this event.
>> + */
>> + val = readl(pvt->regs + PVT_DATA);
>> + WRITE_ONCE(pvt->data_cache, FIELD_GET(PVT_DATA_OUT, val));
>> + complete(&pvt->conversion);
>
> [Severity: Medium]
> Does this unconditionally process the interrupt without checking if the device
> actually generated it?
>
> If a spurious interrupt occurs, the ISR will prematurely clear the interrupt,
> read whatever stale value is in PVT_DATA, and call complete(&pvt->conversion).
> This will cause the waiting thread in eic7700_pvt_read_data() to wake up early
> and return stale or garbage data to userspace.
>
> Should the ISR read the status register and return IRQ_NONE if its device did
> not assert the interrupt?
>
> [ ... ]
>
>> + ret = eic7700_pvt_request_irq(pvt);
>> + if (ret) {
>> + if (!IS_ENABLED(CONFIG_PM))
>> + clk_disable_unprepare(pvt->clk);
>> + return ret;
>> + }
>> +
>> + pm_runtime_enable(&pdev->dev);
>> + pm_runtime_set_autosuspend_delay(&pdev->dev, 3000);
>> + pm_runtime_use_autosuspend(&pdev->dev);
>> + pm_runtime_get_noresume(&pdev->dev);
>> +
>> + ret = devm_add_action_or_reset(pvt->dev, eic7700_pvt_disable_pm_runtime,
>> + pvt);
>
> [Severity: High]
> Can this devres setup lead to accessing unclocked registers during device
> removal?
>
> Because devres executes teardown callbacks in reverse order of their
> registration, eic7700_pvt_disable_pm_runtime() will run before the IRQ
> is freed by devm_request_threaded_irq()'s teardown.
>
> During removal, eic7700_pvt_disable_pm_runtime() disables the clock:
>
> eic7700_pvt_disable_pm_runtime() {
> ...
> if (!pm_runtime_status_suspended(pvt->dev)) {
> clk_disable_unprepare(pvt->clk);
> pm_runtime_set_suspended(pvt->dev);
> }
> }
>
> If an interrupt fires concurrently and the ISR executes past the
> pm_runtime_get_if_active() check before the clock is disabled, the ISR
> will attempt to access hardware registers while unclocked, which can lead
> to an external abort or kernel panic:
>
> eic7700_pvt_hard_isr() {
> ...
> eic7700_pvt_update(pvt->regs + PVT_INT, ...);
> }
>
> Should the PM runtime cleanup action be registered before the IRQ is requested?
>
If not solved, these questions will at least have to be answered.
Thanks,
Guenter
>> + if (ret) {
>> + pm_runtime_put_noidle(&pdev->dev);
>> + return dev_err_probe(&pdev->dev, ret,
>> + "Can't register PM cleanup\n");
>> + }
>
^ permalink raw reply
* Re: [PATCH 4/4] iio: adc: ti-ads112c14: add measurement channel support
From: David Lechner @ 2026-06-16 15:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <ajELGxonxsQp-Ut2@ashevche-desk.local>
On 6/16/26 3:36 AM, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 05:00:02PM -0500, David Lechner (TI) wrote:
>> Add support for parsing devicetree properties for measurement channels
>> and doing direct reads on these.
>>
>> There are quite a lot of conditions that have to be met for each
>> measurement to be made, so quite a bit of state and algorithms are
>> required to handle it.
>>
>> Channels are created dynamically since the number of possibilities is
>> unreasonably large.
>
>> + /* measurement channels */
>> + if (chan->channel < 100) {
>> + struct ads112c14_measurement *measurement =
>> + &data->measurements[chan->scan_index];
>
>> + if (!measurement->label)
>> + return -EINVAL;
>
> Hmm... Can it be true?
Yes. For some channels, label comes from the devicetree, which
may not have provided a label.
>
>> + return sysfs_emit(label, "%s\n", measurement->label);
>> + }
>
...
>> + if (fwnode_property_present(child, "single-channel")) {
>> + ret = fwnode_property_read_u32(child, "single-channel", &spec->channel);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read single-channel property\n");
>> +
>> + if (spec->channel >= 8)
>> + return dev_err_probe(dev, -EINVAL,
>> + "single-channel value must be between 0 and 7\n");
>> + } else if (fwnode_property_present(child, "diff-channels")) {
>> + ret = fwnode_property_read_u32_array(child, "diff-channels", pair, ARRAY_SIZE(pair));
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read diff-channels property\n");
>> +
>> + if (pair[0] >= 8 || pair[1] >= 8)
>> + return dev_err_probe(dev, -EINVAL,
>> + "diff-channels values must be between 0 and 7\n");
>> +
>> + spec->channel = pair[0];
>> + spec->channel2 = pair[1];
>> + spec->differential = 1;
>> + } else {
>> + return dev_err_probe(dev, -EINVAL,
>> + "channel node missing channel type property\n");
>> + }
>
> Looking how it's going to spread (I mean the above pattern), perhaps it's a time to introduce bunch of
>
> fwnode_property_read_*_optional()
>
> and the respective device_property_read_*_optional()?
>
> Let's start from u32 case only, as it will be most used anyway.
I don't think that would be really any different from device_property_read_*
and checking for -EINVAL or ignoring the error completely. TBH, I really like
it this way with fwnode_property_present().
>
>> + if (fwnode_property_present(child, "excitation-channels")) {
>> + ret = fwnode_property_count_u32(child, "excitation-channels");
>> + if (ret < 0)
>> + return dev_err_probe(dev, ret,
>> + "failed to read excitation-channels property\n");
>> +
>> + if (ret < 1 || ret > 2)
>> + return dev_err_probe(dev, -EINVAL,
>> + "excitation-channels property must have 1 or 2 values\n");
>> +
>> + measurement->iadc_count = ret;
>> + pair[1] = 0;
>> +
>> + ret = fwnode_property_read_u32_array(child, "excitation-channels", pair, measurement->iadc_count);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read excitation-channels property\n");
>> +
>> + if (pair[0] >= 8 || pair[1] >= 8)
>> + return dev_err_probe(dev, -EINVAL,
>> + "excitation-channels values must be between 0 and 7\n");
>> +
>> + measurement->idac1_mux = pair[0];
>> + measurement->idac2_mux = measurement->iadc_count > 1 ? pair[1] : 0;
>> +
>> + ret = fwnode_property_read_u32(child, "excitation-current-microamp",
>> + &measurement->idac_current_uA);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read excitation-current-microamp property\n");
>> +
>> + measurement->current_chop = fwnode_property_read_bool(child, "current-chopping");
>> + }
>> +
>> + measurement->bipolar = fwnode_property_read_bool(child, "bipolar");
>> +
>> + fwnode_property_read_u32(child, "ti,vref-source", &measurement->vref_source);
>> + if (measurement->vref_source > ADS112C14_VREF_SOURCE_AVDD)
>> + return dev_err_probe(dev, -EINVAL,
>> + "invalid vref-source value\n");
>> +
>> + if (measurement->vref_source == ADS112C14_VREF_SOURCE_AVDD)
>> + *need_avdd_ref = true;
>> + if (measurement->vref_source == ADS112C14_VREF_SOURCE_EXTERNAL)
>> + *need_ext_ref = true;
>> +
>> + spec->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE);
>> + spec->info_mask_separate_available = BIT(IIO_CHAN_INFO_SCALE);
>> +
>> + i++;
>> + }
>> +
>> + memcpy(channels + i, ads112c14_sys_mon_channels, sizeof(ads112c14_sys_mon_channels));
>> +
>> + indio_dev->channels = channels;
>> + indio_dev->num_channels = i + ARRAY_SIZE(ads112c14_sys_mon_channels);
>> +
>> + return 0;
>> +}
>
> ...
>
>> +static void ads112c14_populate_scale_available(int scale_avail[][2],
>> + u32 vref_uV, u32 fsr_bits)
>> +{
>> + for (u32 i = 0; i < ARRAY_SIZE(ads112c14_pga_gains_x10); i++) {
>> + int *entry = scale_avail[i];
>> + u32 gain_x10 = ads112c14_pga_gains_x10[i];
>> +
>> + entry[0] = div_u64_rem(div64_u64((u64)(NANO * 10 /
>> + (MICRO / MILLI)) * vref_uV,
>> + (u64)gain_x10 * BIT(fsr_bits)),
>
> Hmm... This differs from the previous implementation. Why?
Probably fixed it during testing and missed that I needed to fix
the original patch too.
>
>> + NANO, &entry[1]);
>> + }
>> +}
>
> ...
>
>> + if (device_property_present(dev, "refp-refn-resistor-ohms")) {
>> + if (refp_uV != 0 || refn_uV != 0)
>> + return dev_err_probe(dev, -EINVAL,
>> + "refp-refn-resistor-ohms property should not be present when refp-supply or refn-supply is present\n");
>> +
>> + ret = device_property_read_u32(dev, "refp-refn-resistor-ohms",
>> + &data->ext_ref_ohms);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read refp-refn-resistor-ohms property\n");
>
> Using
>
> const char *propname;
> ...
> propname = "refp-refn-resistor-ohms";
>
> makes this
>
> if (device_property_present(dev, propname)) {
> if (refp_uV != 0 || refn_uV != 0)
> return dev_err_probe(dev, -EINVAL,
> "%s property should not be present when refp-supply or refn-supply is present\n",
> propname);
>
> ret = device_property_read_u32(dev, propname, &data->ext_ref_ohms);
> if (ret)
> return dev_err_probe(dev, ret, "failed to read %s property\n", propname);
>
> Also the rest can be improved in the similar way.
Hmm... maybe less error prone, but makes the code harder to read IMHO.
Will think about it.
>
>> + } else {
>> + if (need_ext_ref && data->ext_ref_uV == 0)
>> + return dev_err_probe(dev, -EINVAL,
>> + "external reference measurements require either refp-supply or refp-refn-resistor-ohms property\n");
>> + }
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: hwmon: ina2xx: add ina232 compatible
From: Guenter Roeck @ 2026-06-16 15:58 UTC (permalink / raw)
To: Loic Poulain
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Krzysztof Kozlowski, linux-hwmon, devicetree,
linux-kernel, linux-arm-msm, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-1-e4375ce652d0@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 04:05:24PM +0200, Loic Poulain wrote:
> From: Martino Facchin <m.facchin@arduino.cc>
>
> The INA232 is a current/power monitor from Texas Instruments sharing
> the same register map as the other INA2xx.
>
> Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Applied to hwmon-next. The branch will be updated after the commit window
closes.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 2/3] hwmon: ina2xx: support ina232
From: Guenter Roeck @ 2026-06-16 15:59 UTC (permalink / raw)
To: Loic Poulain
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Krzysztof Kozlowski, linux-hwmon, devicetree,
linux-kernel, linux-arm-msm, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-2-e4375ce652d0@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 04:05:25PM +0200, Loic Poulain wrote:
> From: Martino Facchin <m.facchin@arduino.cc>
>
> The INA232 is a current/power monitor. It shares the same register
> layout as the INA2xx and uses the INA226 default configuration, but
> differs in its electrical characteristics:
>
> Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: aspeed,ast2700-soc1: Add JTAGM1TRST group
From: Conor Dooley @ 2026-06-16 15:59 UTC (permalink / raw)
To: Billy Tsai
Cc: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-aspeed, openbmc, linux-gpio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260616-pinctrl-fix-v1-1-621036e45c7c@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v9 0/3] riscv: Use GCR.U timer device as clocksource
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu, Conor Dooley
This series adds bindings for the GCR.U timer device and corresponding
driver support. Accessing the memory mapped shadow of the mtime register
in the GCR.U region should be faster
than trapping to M mode each time the timer needs to be read.
The timer device does not implement any interrupts, therefore the
timer-riscv clockevent implementation should suffice.
We tested the patchset both on QEMU and the Boston board with the P8700 bitfile:
- v7, v8 testing:
- Coremark and timer kselftests on QEMU emulating an 8 core CPU
- Coremark and timer kselftests on the Boston board with a single core CPU.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com>
Signed-off-by: Chao-ying Fu <cfu@mips.com>
---
Changes in v9:
- Fix timer base address in dt-bindings
- Link to v8: https://lore.kernel.org/r/20260610-riscv-time-mmio-v8-0-a865206675c6@htecgroup.com
Changes in v8:
- Make the 64 bit timer mmio reads and the main timer driver depend on CONFIG_64BIT
- Add timer_of_cleanup to the driver code
- Link to v7: https://lore.kernel.org/r/20260311-riscv-time-mmio-v7-0-016845a0f808@htecgroup.com
Changes in v7:
- Replace the previous implementation with a new timer driver for mips,p8700-gcru
- Add a patch for 64bit reads for timer mmio
- Link to v6: https://lore.kernel.org/r/20250806-riscv-time-mmio-v6-0-2df0e8219998@htecgroup.com
Changes in v6:
- Rename mti,gcru to mips,p8700-gcru
- Link to v5: https://lore.kernel.org/r/20250711-riscv-time-mmio-v5-0-9ed1f825ad5e@htecgroup.com
Changes in v5:
- Fixed build issues on 32-bit RISC-V and sparse warnings
- Remove clint_time_val and clint.h, replace with riscv_time_val
- Depend on RISCV_TIMER in Kconfig
Changes in v4:
- Remove "select" from mti,gcru.yaml.
- Refactor the driver to use function pointers instead of static keys.
Previous versions:
v1: https://lore.kernel.org/lkml/20241227150056.191794-1-arikalo@gmail.com/#t
v2: https://lore.kernel.org/linux-riscv/20250409143816.15802-1-aleksa.paunovic@htecgroup.com/
v3: https://lore.kernel.org/linux-riscv/DU0PR09MB61968695A2A3146EE83B7708F6BA2@DU0PR09MB6196.eurprd09.prod.outlook.com/
v4: https://lore.kernel.org/r/20250514-riscv-time-mmio-v4-0-cb0cf2922d66@htecgroup.com
v5: https://lore.kernel.org/r/20250711-riscv-time-mmio-v5-0-9ed1f825ad5e@htecgroup.com
v6: https://lore.kernel.org/r/20250806-riscv-time-mmio-v6-0-2df0e8219998@htecgroup.com
v7: https://lore.kernel.org/r/20260311-riscv-time-mmio-v7-0-016845a0f808@htecgroup.com
v8: https://lore.kernel.org/r/20260610-riscv-time-mmio-v8-0-a865206675c6@htecgroup.com
---
Aleksa Paunovic (3):
dt-bindings: timer: mips,p8700-gcru
riscv: clocksource: Add readq options to clocksource mmio
riscv: clocksource: Add p8700-gcru driver
.../devicetree/bindings/timer/mips,p8700-gcru.yaml | 38 +++++++++++++++++
drivers/clocksource/Kconfig | 9 +++++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/mmio.c | 14 +++++++
drivers/clocksource/timer-p8700.c | 47 ++++++++++++++++++++++
include/linux/clocksource.h | 4 ++
6 files changed, 113 insertions(+)
---
base-commit: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d
change-id: 20250424-riscv-time-mmio-5628e0fca8af
Best regards,
--
Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
^ permalink raw reply
* [PATCH v9 1/3] dt-bindings: timer: mips,p8700-gcru
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu, Conor Dooley
In-Reply-To: <20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com>
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>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/timer/mips,p8700-gcru.yaml | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..e6f25e769f461d58c87194fba3540eee13cb322b
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/mips,p8700-gcru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GCR.U timer device for the MIPS P8700 platform
+
+maintainers:
+ - Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
+
+description:
+ The GCR.U memory region contains memory mapped shadow copies of
+ mtime and hrtime Global Configuration Registers,
+ which software can choose to make accessible from user mode.
+
+properties:
+ compatible:
+ const: mips,p8700-gcru
+
+ reg:
+ items:
+ - description: Read-only shadow copy of the RISC-V mtime register.
+ - description: Read-only shadow copy of the P8700 high resolution timer register.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@1617f050 {
+ compatible = "mips,p8700-gcru";
+ reg = <0x1617f050 0x8>,
+ <0x1617f090 0x8>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v9 2/3] riscv: clocksource: Add readq options to clocksource mmio
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu
In-Reply-To: <20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com>
From: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Add read functions for 64-bit register size to the generic
mmio clocksource, covering both up and down counters.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
---
drivers/clocksource/mmio.c | 14 ++++++++++++++
include/linux/clocksource.h | 4 ++++
2 files changed, 18 insertions(+)
diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
index 9de75153183124cc8997c6ab61d0c01d9b2637bc..f3b6f7e93ffbf0ed68e56c58c3d9f711d2193caa 100644
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -17,6 +17,20 @@ static inline struct clocksource_mmio *to_mmio_clksrc(struct clocksource *c)
return container_of(c, struct clocksource_mmio, clksrc);
}
+#if defined(CONFIG_64BIT) && defined(readq_relaxed)
+
+u64 clocksource_mmio_readq_up(struct clocksource *c)
+{
+ return (u64)readq_relaxed(to_mmio_clksrc(c)->reg);
+}
+
+u64 clocksource_mmio_readq_down(struct clocksource *c)
+{
+ return ~(u64)readq_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
+}
+
+#endif
+
u64 clocksource_mmio_readl_up(struct clocksource *c)
{
return (u64)readl_relaxed(to_mmio_clksrc(c)->reg);
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 65b7c41471c390463770c2da13694e58e83b84ea..39e0df5a0ab52cbb7016b53a4d7500f2697e2797 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -276,6 +276,10 @@ static inline void clocksource_arch_init(struct clocksource *cs) { }
extern int timekeeping_notify(struct clocksource *clock);
+#if defined(CONFIG_64BIT) && defined(readq_relaxed)
+extern u64 clocksource_mmio_readq_up(struct clocksource *c);
+extern u64 clocksource_mmio_readq_down(struct clocksource *c);
+#endif
extern u64 clocksource_mmio_readl_up(struct clocksource *);
extern u64 clocksource_mmio_readl_down(struct clocksource *);
extern u64 clocksource_mmio_readw_up(struct clocksource *);
--
2.43.0
^ permalink raw reply related
* [PATCH v9 3/3] riscv: clocksource: Add p8700-gcru driver
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu
In-Reply-To: <20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com>
From: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Add a clocksource driver for the P8700 GCRU.
Initialization uses helper functions
provided by clocksource/mmio.c and timer-of.c.
Since the GCRU does not support any kind of interrupts,
the default RISC-V clockevent implementation should suffice.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
---
drivers/clocksource/Kconfig | 9 ++++++++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-p8700.c | 47 +++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index ffcd23668763fe7707a4e917bf240caadbb09a8c..a775a301f3f08ca97699e46aaf3ccfaf99734e6b 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -672,6 +672,15 @@ config CLINT_TIMER
This option enables the CLINT timer for RISC-V systems. The CLINT
driver is usually used for NoMMU RISC-V systems.
+config P8700_TIMER
+ bool "MIPS P8700 timer driver"
+ depends on GENERIC_SCHED_CLOCK && RISCV && RISCV_SBI && 64BIT
+ select CLKSRC_MMIO
+ select TIMER_PROBE
+ select TIMER_OF
+ help
+ Enables support for MIPS P8700 timer driver.
+
config CSKY_MP_TIMER
bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
depends on CSKY
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index ec4452ee958f1a814c708aeba6412bea61d24892..fae9a58d6c8663a7c857b9ab7fdae05782b3551c 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_CLKSRC_LOONGSON1_PWM) += timer-loongson1-pwm.o
obj-$(CONFIG_EP93XX_TIMER) += timer-ep93xx.o
obj-$(CONFIG_RALINK_TIMER) += timer-ralink.o
obj-$(CONFIG_NXP_STM_TIMER) += timer-nxp-stm.o
+obj-$(CONFIG_P8700_TIMER) += timer-p8700.o
diff --git a/drivers/clocksource/timer-p8700.c b/drivers/clocksource/timer-p8700.c
new file mode 100644
index 0000000000000000000000000000000000000000..dd20b4e72fcdd77a6b33775f286d0945c2a2b659
--- /dev/null
+++ b/drivers/clocksource/timer-p8700.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 MIPS.
+ */
+
+#include <linux/sched_clock.h>
+#include <linux/delay.h>
+#include <linux/of_address.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/clocksource.h>
+
+#include "timer-of.h"
+
+static struct timer_of gcru_of = { .flags = TIMER_OF_BASE };
+static u64 __iomem *p8700_time_val __ro_after_init;
+
+static u64 notrace p8700_timer_sched_read(void)
+{
+ return (u64)readq_relaxed(p8700_time_val);
+}
+
+static int __init p8700_timer_init(struct device_node *node)
+{
+ int error = 0;
+
+ error = timer_of_init(node, &gcru_of);
+ if (error)
+ return error;
+
+ p8700_time_val = timer_of_base(&gcru_of);
+ /* Now init the mmio timer with the address we got from DT */
+ error = clocksource_mmio_init(p8700_time_val, "mips,p8700-gcru",
+ riscv_timebase, 450, 64,
+ clocksource_mmio_readq_up);
+ if (error) {
+ timer_of_cleanup(&gcru_of);
+ return error;
+ }
+
+ /* Sched clock */
+ sched_clock_register(p8700_timer_sched_read, 64, riscv_timebase);
+
+ return error;
+}
+
+TIMER_OF_DECLARE(p8700_timer, "mips,p8700-gcru", p8700_timer_init);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Guenter Roeck @ 2026-06-16 16:03 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu, Conor Dooley
In-Reply-To: <20260612030304.5165-2-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:02AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add devicetree binding documentation for the Silergy SQ24860 eFuse.
>
> The device is a PMBus hardware monitoring device which reports voltage,
> current, power, and temperature telemetry. The board-specific IMON
> resistor value is described with silergy,rimon-micro-ohms.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Applied to hwmon-next (after dropping the extra blank line above).
Thanks,
Guenter
^ 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