* Re: [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device
From: Kim Jinseob @ 2026-06-14 23:04 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Conor Dooley, linux-iio, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260614185551.10ca9e0f@jic23-huawei>
2026년 6월 15일 (월) 오전 2:55, Jonathan Cameron <jic23@kernel.org>님이 작성:
>
> On Wed, 10 Jun 2026 18:33:54 +0900
> Kim Jinseob <kimjinseob88@gmail.com> wrote:
> When a device needs power, the regulator is required, not optional from a binding
> point of view. If it is always one people can use a fixed regulator to represent it.
>
> Now from a driver point of view, the regulator framework in linux provides stub regulators
> for missing ones - on assumption they are always on. So we can just request the
> regulators in the driver. Keep it simple for now and use a
> devm_regulator_get_enable() in probe so we have power on for all the time
> the driver is loaded. Can do fancy stuff later when you have a board where the
> power is controlled.
Understood, thanks.
I will make vcc-supply a required property in the binding and use
devm_regulator_get_enable() in probe in the next revision, keeping the
power handling simple for now.
Jinseob
^ permalink raw reply
* Re: [PATCH v7 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Andi Shyti @ 2026-06-14 22:24 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260603-add-mcu-fan-khadas-vim4-v7-2-594ba8a965d8@aliel.fr>
Hi Ronald,
On Wed, Jun 03, 2026 at 08:05:24PM +0200, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> Add the T7 SOC compatible which fallback to AXG compatible.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v6 2/2] i2c: ls2x: Add clocks property parsing and adjust bus speed
From: Andi Shyti @ 2026-06-14 22:20 UTC (permalink / raw)
To: Hongliang Wang
Cc: Binbin Zhou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Wolfram Sang, linux-i2c, devicetree, loongarch, Huacai Chen,
stable
In-Reply-To: <20260608024533.32419-3-wanghongliang@loongson.cn>
Hi Hongliang,
On Mon, Jun 08, 2026 at 10:45:33AM +0800, Hongliang Wang wrote:
> The i2c-ls2x driver supports dts and acpi parameter passing.
>
> In dts, uses clock framework, by parsing clocks property to
> get i2c bus reference clock, and define the div of reference
> clock by device data.
>
> In acpi, by passing clocks property to describe i2c bus reference
> clock and clock-div property to describe the div of reference clock.
>
> Based on i2c bus reference clock(clock_a), i2c bus speed(clock_s)
> and div, calculate the prcescale of i2c divider register. The
> calculation formula is
>
> prcescale = (clock_a*10)/(div*clock_s)-1
>
> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
I think Huacai has not reviewed this patch, his review was only
for patch 1. Am I right?
Andi
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: adc: Add TI ADS126x ADC family
From: Kurt Borja @ 2026-06-14 21:57 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Krzysztof Kozlowski
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Nuno Sá, Andy Shevchenko,
linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <f13b9c55-770e-454c-9bfb-5847ff17813b@baylibre.com>
On Sun Jun 14, 2026 at 4:37 PM -05, David Lechner wrote:
> On 6/14/26 3:53 PM, Kurt Borja wrote:
>
> ...
>
>>> Not a separate device node. Fold into the parent... or explain in
>>> commit msg. You have entire commit msg to explain odd things.
>>>
>>> In that binding description you call it "independent", so it should have
>>> its own SPI chip select? Why "independent" and part of this binding?
>>> Maybe not independent, so basically part of this device?
>>
>> It's independent in the sense that it is a proper subdevice on the same
>> chip. It shares the serial interface but operates completely in
>> parallel.
>>
>> I decided to add a subnode because other devices might request their
>> io-channels and most importantly a different voltage reference might be
>> connected to it.
>>
>> I'll clarify this in the commmit message on the next version. Although
>> after seeing this submitted bindings [1], I wonder if it's a better
>> approach to do something like
>>
>> spi@0 {
>> mydevice@0 {
>> ...
>> adc@0 { ... };
>> adc@1 { ... };
>> };
>> };
>>
>> Any thoughts?
>
> I don't see how this relates to the linked patch at all. The linked
> patch looks just like a normal DAC binding.
Ah, wrong link. This is the correct one [1]. The suggestion just at the
end.
>
> What is the point of the 2nd ADC in this chip? Is it just to be able
> to do simultaneous sampling of two different measurements at the same
> time? We have other simultaneous sampling ADC chips and just model them
> as a single device.
It does simultaneous sampling of the same channel, as well as different
channels. Also the secondary ADC is only 24 bit instead of 32 bit, has a
different noise profile and has a different PGA configuration (goes up
to 128 gain, instead of 32).
Taken from the datasheet (Section 9.3.15):
Use ADC2 to perform main channel (ADC1) cross-checking
measurements (for example, diagnostics purposes and redundant
channel measurements), system background measurements, or
temperature compensation of the primary sensor (such as
thermocouple cold junction compensation). Using data rates of
10, 100, and 400 SPS for both ADCs, ADC2 performs virtual
parallel conversions with ADC1 on the same input channel.
>
> Since everything can be muxed to either ADC at runtime, I don't see
> any reason the devicetree should care about it. Forcing certain pins
> to be assigned to a certain ADC seems overly restrictive.
>
> And unless you have an application that specifically needs it, I
> wouldn't bother trying to implement the 2nd ADC in the IIO driver.
> I didn't see any hints in the datasheet as to when it would actually
> make sense to use this 2nd ADC. My first thought is that it might
> make sense to use the 2nd ADC for a 2nd buffer so that you can do
> 2 buffered reads at the same time. But without knowing why this chip
> was designed this way, I don't know if that is the right idea or not.
I myself don't have an application for this feature. But I don't see why
not adding support for this feature, given that I already implemented a
driver (Patch 5) and is capable, as you said, of 2 buffered reads at the
same time.
I do believe I have to explain all this better in commit messages
though.
>
>
>> Ack to the rest of comments.
>>
>> [1] https://lore.kernel.org/linux-iio/20260519-ad5529r-driver-v3-1-267c0731aa68@analog.com/
>>
[1] https://lore.kernel.org/linux-iio/25mh6grzh7zh3b4uytcqnusyv5zjuf6ia4if3ce3oqzqz56ehi@le72iqv7ye3d/
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add PMIC thermal support for Shikra CQ2390M SoM platform
From: Dmitry Baryshkov @ 2026-06-14 21:45 UTC (permalink / raw)
To: Jishnu Prakash
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Kamal Wadhwa, Rakesh Kota
In-Reply-To: <20260613-shikra_adc_support-v1-3-57d5e6c7f47d@oss.qualcomm.com>
On Sat, Jun 13, 2026 at 01:39:23PM +0530, Jishnu Prakash wrote:
> Add ADC channels for system thermistors, used for thermal mitigation.
> Add ADC thermal bridge nodes for pa/quiet/msm thermistors. Enable temperature
> alarm nodes for PM4125 and PM8005. Add thermal zones for temp-alarm devices
> and system thermistors exposed as thermal bridge nodes.
>
> Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 184 +++++++++++++++++++++++++++
> 1 file changed, 184 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> index dc3861489f64..c6c09d773abe 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> @@ -4,6 +4,7 @@
> */
>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/iio/qcom,spmi-vadc.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
>
> #include "shikra.dtsi"
> @@ -27,9 +28,184 @@ key-volume-up {
> linux,can-disable;
> };
> };
> +
> + pm4125_msm_therm_bridge: pm4125-msm-therm-bridge {
Generic node names, please. See, how other platforms name them.
> + compatible = "generic-adc-thermal";
> + io-channels = <&pm4125_adc ADC5_AMUX_THM3_100K_PU>;
> + io-channel-names = "sensor-channel";
> + #thermal-sensor-cells = <0>;
> + };
> +
> + pm4125_pa_therm_bridge: pm4125-pa-therm-bridge {
> + compatible = "generic-adc-thermal";
> + io-channels = <&pm4125_adc ADC5_AMUX_THM1_100K_PU>;
> + io-channel-names = "sensor-channel";
> + #thermal-sensor-cells = <0>;
> + };
> +
> + pm4125_quiet_therm_bridge: pm4125-quiet-therm-bridge {
> + compatible = "generic-adc-thermal";
> + io-channels = <&pm4125_adc ADC5_AMUX_THM2_100K_PU>;
> + io-channel-names = "sensor-channel";
> + #thermal-sensor-cells = <0>;
> + };
> +
> + thermal-zones {
> + pm4125-thermal {
> + polling-delay-passive = <100>;
> + polling-delay = <0>;
> + thermal-sensors = <&pm4125_tz>;
This should be a part of the pm4125.dtsi
> +
> + trips {
> + pm4125_trip0: trip0 {
> + temperature = <105000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + pm4125_trip1: trip1 {
> + temperature = <125000>;
> + hysteresis = <0>;
> + type = "hot";
> + };
> +
> + pm4125_trip2: trip2 {
> + temperature = <155000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> + };
> +
> + pm8005-thermal {
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + thermal-sensors = <&pm8005_tz>;
pm8005.dtsi
> +
> + trips {
> + pm8005_trip0: trip0 {
> + temperature = <105000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + pm8005_trip1: trip1 {
> + temperature = <125000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> +
> + pm8005_trip2: trip2 {
> + temperature = <145000>;
> + hysteresis = <0>;
> + type = "passive";
> + };
> + };
> + };
> +
> + sys-1-thermal {
> + polling-delay-passive = <2000>;
> + polling-delay = <0>;
> + thermal-sensors = <&pm4125_pa_therm_bridge>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
> + hysteresis = <1000>;
> + type = "passive";
Passive cooling at 125°C sounds very strange. Especially without any
cooling device attached.
> + };
> + };
> + };
> +
> + sys-2-thermal {
> + polling-delay-passive = <2000>;
> + polling-delay = <0>;
> + thermal-sensors = <&pm4125_quiet_therm_bridge>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
> + hysteresis = <1000>;
> + type = "passive";
> + };
> + };
> + };
> +
> + sys-3-thermal {
> + polling-delay-passive = <2000>;
> + polling-delay = <0>;
> + thermal-sensors = <&pm4125_msm_therm_bridge>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
> + hysteresis = <1000>;
> + type = "passive";
> + };
> + };
> + };
> + };
> +};
> +
> +&pm4125_adc {
> + pinctrl-0 = <&pm4125_adc_gpio5_default>, <&pm4125_adc_gpio6_default>;
> + pinctrl-names = "default";
> + status = "okay";
Empty line before status.
> +
> + channel@4d {
> + reg = <ADC5_AMUX_THM1_100K_PU>;
> + label = "pa_therm";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@4e {
> + reg = <ADC5_AMUX_THM2_100K_PU>;
> + label = "quiet_therm";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@4f {
> + reg = <ADC5_AMUX_THM3_100K_PU>;
> + label = "msm_therm";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@54 {
> + reg = <ADC5_GPIO3_100K_PU>;
> + label = "chgr_skin";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@55 {
> + reg = <ADC5_GPIO4_100K_PU>;
> + label = "gnss_therm";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + };
> };
>
> &pm4125_gpios {
> + pm4125_adc_gpio5_default: pm4125-adc-gpio5-state {
> + pins = "gpio5";
> + function = PMIC_GPIO_FUNC_NORMAL;
> + bias-high-impedance;
> + };
> +
> + pm4125_adc_gpio6_default: pm4125-adc-gpio6-state {
> + pins = "gpio6";
> + function = PMIC_GPIO_FUNC_NORMAL;
> + bias-high-impedance;
> + };
> +
> vol_up_n: vol-up-n-state {
> pins = "gpio9";
> function = PMIC_GPIO_FUNC_NORMAL;
> @@ -45,10 +221,18 @@ &pm4125_resin {
> status = "okay";
> };
>
> +&pm4125_tz {
> + status = "okay";
> +};
> +
> &pm8005_regulators {
> status = "disabled";
> };
>
> +&pm8005_tz {
> + status = "okay";
> +};
> +
> &rpm_requests {
> regulators {
> compatible = "qcom,rpm-pm2250-regulators";
>
> --
> 2.43.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: qcom: pm8005: Add temp alarm node
From: Dmitry Baryshkov @ 2026-06-14 21:42 UTC (permalink / raw)
To: Jishnu Prakash
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Kamal Wadhwa, Rakesh Kota
In-Reply-To: <20260613-shikra_adc_support-v1-2-57d5e6c7f47d@oss.qualcomm.com>
On Sat, Jun 13, 2026 at 01:39:22PM +0530, Jishnu Prakash wrote:
> Add temperature alarm node, used for PMIC thermal mitigation.
>
> Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/pm8005.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8005.dtsi b/arch/arm64/boot/dts/qcom/pm8005.dtsi
> index 0f0ab2da8305..180809a0ee73 100644
> --- a/arch/arm64/boot/dts/qcom/pm8005.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8005.dtsi
> @@ -11,6 +11,14 @@ pm8005_lsid0: pmic@4 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + pm8005_tz: temp-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400>;
> + interrupts = <0x4 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
> + #thermal-sensor-cells = <0>;
> + status = "disabled";
Missing thermal zone, also enable it by default.
> + };
> +
> pm8005_gpios: gpio@c000 {
> compatible = "qcom,pm8005-gpio", "qcom,spmi-gpio";
> reg = <0xc000>;
>
> --
> 2.43.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: qcom: pm4125: Add VADC and temp alarm nodes
From: Dmitry Baryshkov @ 2026-06-14 21:41 UTC (permalink / raw)
To: Jishnu Prakash
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Kamal Wadhwa, Rakesh Kota
In-Reply-To: <20260613-shikra_adc_support-v1-1-57d5e6c7f47d@oss.qualcomm.com>
On Sat, Jun 13, 2026 at 01:39:21PM +0530, Jishnu Prakash wrote:
> Add VADC node with some channels under it, for voltage and
> temperature readings. Add temperature alarm node, used for
> PMIC thermal mitigation.
>
> Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/pm4125.dtsi | 77 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm4125.dtsi b/arch/arm64/boot/dts/qcom/pm4125.dtsi
> index 542e8fe030da..7113504d5941 100644
> --- a/arch/arm64/boot/dts/qcom/pm4125.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm4125.dtsi
> @@ -65,6 +65,83 @@ pm4125_typec: typec@1500 {
> status = "disabled";
> };
>
> + pm4125_tz: temp-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400>;
> + interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_BOTH>;
> + io-channels = <&pm4125_adc ADC5_DIE_TEMP>;
> + io-channel-names = "thermal";
> + #thermal-sensor-cells = <0>;
> + status = "disabled";
Why would it be disabled by default?
> + };
> +
> + pm4125_adc: adc@3100 {
> + compatible = "qcom,spmi-adc5";
> + reg = <0x3100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Again, why?
> +
> + /* Channel nodes */
> + channel@0 {
> + reg = <ADC5_REF_GND>;
> + label = "ref_gnd";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@1 {
> + reg = <ADC5_1P25VREF>;
> + label = "vref_1p25";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@6 {
> + reg = <ADC5_DIE_TEMP>;
> + label = "die_temp";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@7 {
> + reg = <ADC5_USB_IN_I>;
> + label = "usb_in_i_uv";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@8 {
> + reg = <ADC5_USB_IN_V_16>;
> + label = "usb_in_v_div_16";
> + qcom,pre-scaling = <1 16>;
> + };
> +
> + channel@9 {
> + reg = <ADC5_CHG_TEMP>;
> + label = "chg_temp";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@4b {
> + reg = <ADC5_BAT_ID_100K_PU>;
> + label = "bat_id";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@83 {
> + reg = <ADC5_VPH_PWR>;
> + label = "vph_pwr";
> + qcom,pre-scaling = <1 3>;
> + };
> +
> + channel@84 {
> + reg = <ADC5_VBAT_SNS>;
> + label = "vbat_sns";
> + qcom,pre-scaling = <1 3>;
> + };
> + };
> +
> rtc@6000 {
> compatible = "qcom,pm8941-rtc";
> reg = <0x6000>, <0x6100>;
>
> --
> 2.43.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: adc: Add TI ADS126x ADC family
From: David Lechner @ 2026-06-14 21:37 UTC (permalink / raw)
To: Kurt Borja, Krzysztof Kozlowski
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Nuno Sá, Andy Shevchenko,
linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <DJ92JT0CPSXJ.1113K3KLSRHH4@gmail.com>
On 6/14/26 3:53 PM, Kurt Borja wrote:
...
>> Not a separate device node. Fold into the parent... or explain in
>> commit msg. You have entire commit msg to explain odd things.
>>
>> In that binding description you call it "independent", so it should have
>> its own SPI chip select? Why "independent" and part of this binding?
>> Maybe not independent, so basically part of this device?
>
> It's independent in the sense that it is a proper subdevice on the same
> chip. It shares the serial interface but operates completely in
> parallel.
>
> I decided to add a subnode because other devices might request their
> io-channels and most importantly a different voltage reference might be
> connected to it.
>
> I'll clarify this in the commmit message on the next version. Although
> after seeing this submitted bindings [1], I wonder if it's a better
> approach to do something like
>
> spi@0 {
> mydevice@0 {
> ...
> adc@0 { ... };
> adc@1 { ... };
> };
> };
>
> Any thoughts?
I don't see how this relates to the linked patch at all. The linked
patch looks just like a normal DAC binding.
What is the point of the 2nd ADC in this chip? Is it just to be able
to do simultaneous sampling of two different measurements at the same
time? We have other simultaneous sampling ADC chips and just model them
as a single device.
Since everything can be muxed to either ADC at runtime, I don't see
any reason the devicetree should care about it. Forcing certain pins
to be assigned to a certain ADC seems overly restrictive.
And unless you have an application that specifically needs it, I
wouldn't bother trying to implement the 2nd ADC in the IIO driver.
I didn't see any hints in the datasheet as to when it would actually
make sense to use this 2nd ADC. My first thought is that it might
make sense to use the 2nd ADC for a 2nd buffer so that you can do
2 buffered reads at the same time. But without knowing why this chip
was designed this way, I don't know if that is the right idea or not.
> Ack to the rest of comments.
>
> [1] https://lore.kernel.org/linux-iio/20260519-ad5529r-driver-v3-1-267c0731aa68@analog.com/
>
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: arm-smmu: Document GPU SMMU for Shikra SoC
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen
In-Reply-To: <20260615-shikra-gpu-v2-0-2f2d1347c3fb@oss.qualcomm.com>
From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Add specific compatible strings to document the GPU SMMU present
in the Shikra SoC.
Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index a701dec2fa0a..ad15fda5c25e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -108,6 +108,7 @@ properties:
- qcom,sc7280-smmu-500
- qcom,sc8180x-smmu-500
- qcom,sc8280xp-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm8150-smmu-500
@@ -543,6 +544,7 @@ allOf:
- enum:
- qcom,milos-smmu-500
- qcom,sar2130p-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm8550-smmu-500
- qcom,sm8650-smmu-500
- qcom,x1e80100-smmu-500
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] drm/msm/adreno: Add support for A704 GPU
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen,
Aditya Sherawat, Konrad Dybcio
In-Reply-To: <20260615-shikra-gpu-v2-0-2f2d1347c3fb@oss.qualcomm.com>
From: Aditya Sherawat <asherawa@qti.qualcomm.com>
Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
minimal changes. The only KMD facing difference is the chipid and the
zap firmware which is specified via devicetree.
Just add the new chipid to enable support for A704 GPU in Shikra.
Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
index 3e6f409d13a2..2de3ab010135 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
@@ -1454,7 +1454,7 @@ DECLARE_ADRENO_REGLIST_PIPE_LIST(a7xx_dyn_pwrup_reglist);
static const struct adreno_info a7xx_gpus[] = {
{
- .chip_ids = ADRENO_CHIP_IDS(0x07000200),
+ .chip_ids = ADRENO_CHIP_IDS(0x07000200, 0x07000400),
.family = ADRENO_6XX_GEN1, /* NOT a mistake! */
.fw = {
[ADRENO_FW_SQE] = "a702_sqe.fw",
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: display/msm/gpu: Add support for A704 GPU
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen,
Aditya Sherawat, Krzysztof Kozlowski
In-Reply-To: <20260615-shikra-gpu-v2-0-2f2d1347c3fb@oss.qualcomm.com>
From: Aditya Sherawat <asherawa@qti.qualcomm.com>
Adreno A704 GPU found Shikra SoC is an IP reuse of A702 GPU with very
minimal changes.
Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index dbbd8b814189..8e648bfb3b23 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -353,6 +353,7 @@ allOf:
- qcom,adreno-610.0
- qcom,adreno-619.1
- qcom,adreno-07000200
+ - qcom,adreno-07000400
then:
properties:
clocks:
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/3] drm/msm: Add support for Shikra GPU (A704)
From: Akhil P Oommen @ 2026-06-14 21:32 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu, Akhil P Oommen,
Aditya Sherawat, Krzysztof Kozlowski, Konrad Dybcio
Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
minimal changes. The only KMD facing difference is the chipid and the
zap firmware which is specified via devicetree.
Mesa side support is already merged:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41762
The dependencies for the devicetree patches are still on the mailing
lists. So I will send that separately.
-Akhil.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
Changes in v2:
- Add a new patch to document the GPU SMMU bindings
- Capture trailers
- Link to v1: https://lore.kernel.org/r/20260609-shikra-gpu-v1-0-9d0e09cab115@oss.qualcomm.com
---
Aditya Sherawat (2):
dt-bindings: display/msm/gpu: Add support for A704 GPU
drm/msm/adreno: Add support for A704 GPU
Bibek Kumar Patro (1):
dt-bindings: arm-smmu: Document GPU SMMU for Shikra SoC
Documentation/devicetree/bindings/display/msm/gpu.yaml | 1 +
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)
---
base-commit: 61087e3a8490908a65da4e2d33fb5de6eb888982
change-id: 20260609-shikra-gpu-5432bdeaf0f7
Best regards,
--
Akhil P Oommen <akhilpo@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Dmitry Baryshkov @ 2026-06-14 21:28 UTC (permalink / raw)
To: Atanas Filipov
Cc: linux-media, mchehab, bod, robh, krzk+dt, conor+dt, andersson,
konradybcio, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260612194417.1737009-3-atanas.filipov@oss.qualcomm.com>
On Fri, Jun 12, 2026 at 10:44:15PM +0300, Atanas Filipov wrote:
> Add the missing JPEG encoder hardware node in SM8550 DTS so the
> new qcom-jpeg V4L2 encoder driver can bind and operate on this
> platform.
>
> The node wires the resources expected by the binding and driver,
> including clocks, power domain, IOMMUs and interconnect paths.
>
> Signed-off-by: Atanas Filipov <atanas.filipov@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 42 ++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 912525e9bca6..8090b8b1d7bd 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -3677,6 +3677,48 @@ port@7 {
> };
> };
>
> + qcom_jpeg_enc: jpeg-encoder@ac4e000 {
To reiterate and reinforce what others wrote: this should be a subdevice
under the isp@ or camss@ node.
Then, drop the label, please.
> + cell-index = <0>;
No cell-index.
> + compatible = "qcom,sm8550-jenc";
> +
> + reg = <0 0xac4e000 0 0x4000>;
0x0 instead of 0, pad address to 8 digits (0x0ac4e000).
> + reg-names = "jpeg";
No need to name the only region.
> +
> + interrupts = <GIC_SPI 474 IRQ_TYPE_EDGE_RISING 0>;
> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +
> + clocks = <&gcc GCC_CAMERA_HF_AXI_CLK>,
> + <&gcc GCC_CAMERA_SF_AXI_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_AHB_CLK>,
> + <&camcc CAM_CC_CAMNOC_AXI_CLK>,
> + <&camcc CAM_CC_JPEG_CLK>;
> +
> + clock-names = "gcc_hf_axi",
> + "gcc_sf_axi",
> + "core_ahb",
> + "cpas_ahb",
> + "camnoc_axi",
> + "jpeg";
> +
> + iommus = <&apps_smmu 0x20C0 0x20>,
> + <&apps_smmu 0x20E0 0x20>;
lowercase the hex.
> +
> + interconnects = <&gem_noc MASTER_APPSS_PROC 0
> + &config_noc SLAVE_CAMERA_CFG 0>,
Use tags instead of 0.
> + <&mmss_noc MASTER_CAMNOC_HF 0
> + &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_SF 0
> + &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_ICP 0
> + &mc_virt SLAVE_EBI1 0>;
> +
> + interconnect-names = "cam_ahb",
> + "cam_hf_0_mnoc",
> + "cam_sf_0_mnoc",
> + "cam_sf_icp_mnoc";
I know that camera settled on these names. Please use a better approach:
describe the source and the destination of the interconnect (see how
other devices name them).
> + };
> +
> camcc: clock-controller@ade0000 {
> compatible = "qcom,sm8550-camcc";
> reg = <0 0x0ade0000 0 0x20000>;
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode
From: Dmitry Baryshkov @ 2026-06-14 21:18 UTC (permalink / raw)
To: Pengyu Luo
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, linux-arm-msm, linux-spi, devicetree,
linux-kernel
In-Reply-To: <20260614083424.464132-2-mitltlatltl@gmail.com>
On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
> Some devices (such as gaokun3) do not disable FIFO mode, causing the
> driver to fallback to FIFO mode by default. However, these platforms
> also support GSI mode, which is highly preferred for certain
> peripherals like SPI touchscreens to improve performance.
>
> Introduce the "qcom,force-gsi-mode" device property to hint and force
> the controller into GSI mode during initialization.
Ideally, this should be decided by the SPI controller based on the
requirements. Another option would be to prefer GSI for all transfers if
it is available, ignoring the FIFO even if it is not disabled.
>
> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> ---
> drivers/spi/spi-geni-qcom.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Add Embedded Controller node
From: Dmitry Baryshkov @ 2026-06-14 21:16 UTC (permalink / raw)
To: Daniel J Blueman
Cc: Konrad Dybcio, Bjorn Andersson, linux-arm-msm, devicetree,
Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Randy Dunlap, Bryan O'Donoghue, linux-kernel,
Anvesh Jain P, Maya Matuszczyk, Krzysztof Kozlowski,
Akhil P Oommen, Abel Vesa, Gaurav Kohli
In-Reply-To: <20260614130621.68811-2-daniel@quora.org>
On Sun, Jun 14, 2026 at 09:06:18PM +0800, Daniel J Blueman wrote:
> The Lenovo Slim7x uses the same Embedded Controller as the Qualcomm Hamoa
> X1 Customer Reference Device. Use the lenovo,yoga-slim7x-ec compatible
> introduced by patch 1 for fan control, thermal sensor and suspend
This is going to become commit message in the Git history of the Linux
kernel. There is no 'patch 1'. Moreover, the patches will go through
different trees.
Please rewrite the commit message accordingly (just drop the 'introduced
by' reference).
> behaviour.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Reviewed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
> v4:
> - add reviews
> v3:
> - use lenovo,yoga-slim7x-ec compatible (introduced by patch 1)
> v2:
> - corrected DT compatible node
>
> .../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 22 +++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v11 00/11] iio: adc: Add support for AVIA HX710B ADC
From: Jonathan Cameron @ 2026-06-14 21:04 UTC (permalink / raw)
To: Piyush Patle
Cc: linux-iio, devicetree, linux-kernel, ak, robh, krzk+dt, conor+dt,
andy, nuno.sa, dlechner
In-Reply-To: <20260603184859.89693-1-piyushpatle228@gmail.com>
On Thu, 4 Jun 2026 00:18:48 +0530
Piyush Patle <piyushpatle228@gmail.com> wrote:
> The HX710B is a 24-bit ADC from AVIA Semiconductor, related to the
> HX711 already supported in this driver. Unlike the HX711 (which has
> selectable gain and two input channels), the HX710B has a fixed gain
> of 128 and two operating modes selected by the trailing PD_SCK pulse
> count after each conversion:
>
> 25 pulses (1 trailing): differential input at 10 SPS
> 26 pulses (2 trailing): DVDD-AVDD supply monitor at 40 SPS
> 27 pulses (3 trailing): differential input at 40 SPS
>
> This series first extends the existing HX711 binding and driver with
> preparatory refactoring, then adds HX710B support on top.
>
> The differential input is exposed as a single IIO channel with
> IIO_CHAN_INFO_SAMP_FREQ, allowing userspace to select 10 or 40 SPS
> without needing two separate channels for the same physical input.
> The supply monitor is a second channel at fixed 40 SPS.
>
> This revision is rebased onto current mainline. Note that
> iio_device_claim_direct_mode() / iio_device_release_direct_mode() were
> removed from the IIO core since v10, so 11/11 now uses the replacement
> iio_device_claim_direct() / iio_device_release_direct() API.
>
> Tested on a PocketBeagle2 (TI AM625): the avia,hx710b node probes and
> the driver registers its two IIO channels.
>
> Changes from v10:
> - 02/11: Retitled to "add VSUP and DVDD supply properties"; the
> commit message now documents both supplies (the patch already
> added both; only the title/text were out of sync). [Jonathan]
> - 04/11: Reworded commit message so DVDD is no longer described as
> HX710B-specific (it is added for both parts in 02/11). The
> compatible match now uses "contains: const: avia,hx710b" so the
> constraints still apply if the compatible is later used as a
> fallback. dvdd-supply is now required for HX710B (in the HX710B
> branch only, so existing HX711 device trees are unaffected) and
> added to the HX710B example. [Jonathan, Conor, Sashiko]
> - 11/11: Kconfig title and file header use "similar" instead of
> "compatible". Simplified the tail of hx711_set_hx710b_channel()
> to "return hx711_wait_for_ready()". Dropped an unrelated
> reindentation of the iio_push_to_buffers_with_timestamp() call.
> Converted hx710b_write_raw() to the new
> iio_device_claim_direct() API (see above). [Jonathan]
>
> The Reviewed-by (Andy Shevchenko) and Acked-by (Conor Dooley) tags on
> 02/11 and 04/11 are carried over although those patches changed; please
> re-confirm if you disagree with the reworked constraints.
As the only comments I had (well mostly sashiko) were on the 710b patch
at the end and some patches were queued from previous patches, I now have
patches 1-3 and 5-10 applied to the testing branch of iio.git.
Thanks,
Jonathan
>
> Patches 01/11, 03/11, and 05/11 are unchanged from v10.
>
> Piyush Patle (11):
> dt-bindings: iio: adc: hx711: clean up existing binding text
> dt-bindings: iio: adc: hx711: add VSUP and DVDD supply properties
> dt-bindings: iio: adc: hx711: add RATE GPIO property
> dt-bindings: iio: adc: hx711: add HX710B support
> iio: adc: hx711: move scale computation to per-device storage
> iio: adc: hx711: introduce hx711_chip_info structure
> iio: adc: hx711: pass trailing pulse count into hx711_read
> iio: adc: hx711: split variable assignments in hx711_read and
> hx711_reset
> iio: adc: hx711: localize loop iterators in hx711_read
> iio: adc: hx711: pass iio_chan_spec to hx711_reset_read
> iio: adc: hx711: add support for HX710B
>
> .../bindings/iio/adc/avia-hx711.yaml | 82 ++++-
> drivers/iio/adc/Kconfig | 8 +-
> drivers/iio/adc/hx711.c | 343 +++++++++++++++---
> 3 files changed, 359 insertions(+), 74 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 2/5] iio: adc: Add ti-ads1262 driver
From: Kurt Borja @ 2026-06-14 20:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, sashiko-reviews
Cc: Kurt Borja, robh, conor+dt, devicetree
In-Reply-To: <20260613-graceful-berserk-rook-cc5ecb@quoll>
On Sat Jun 13, 2026 at 2:00 PM -05, Krzysztof Kozlowski wrote:
> On Fri, Jun 12, 2026 at 11:01:32PM +0000, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 15 potential issue(s) to consider:
>> - [High] Architecture Compatibility / Undefined Behavior due to direct bitfield mapping.
>> - [High] Out-of-Bounds Memory Access / Hardware Misconfiguration during active channel iteration.
>> - [High] Infinite Loop / Denial of Service in IDAC microamp parsing.
>> - [High] Logic Error: Inverted bounds check rejects valid pin numbers.
>> - [High] Race Condition / Lost Wakeup due to reinitializing completion after hardware trigger.
>> - [High] Missing Error Handling / Type Mismatch: Unsigned check of negative error code.
>> - [High] DMA Memory Corruption: Unaligned DMA buffer in union.
>> - [High] Uninitialized Memory Read (KMSAN) on stack variable.
>> - [High] Illegal DMA from Stack in regmap bus implementation.
>> - [High] Logic Error: GPIO get_multiple returns pin states incorrectly.
>> - [High] Hardware State / Timing violation during device reset.
>> - [High] Logic Error / Performance: Unconditional stall without IRQ.
>> - [Medium] Memory Leak of fwnode_handle reference on the error path.
>> - [Medium] Resource Leak of runtime PM usage counter on the error path.
>> - [Medium] API Contract Violation: Buffer mode lock released with direct mode API.
>
> Amount of findings is horrifying. You should probably involve some
> internal review before posting next version.
I'll set a local Sashiko instance before submitting the next version.
Also my local testing is a bit loose. I definitely need to take care of
it.
>
> Best regards,
> Krzysztof
Thanks for your feedback!
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH v16 00/14] ADF41513/ADF41510 PLL frequency synthesizers
From: Jonathan Cameron @ 2026-06-14 20:56 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
linux, David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan,
Krzysztof Kozlowski, Randy Dunlap
In-Reply-To: <20260604-adf41513-iio-driver-v16-0-1a7d09143bc2@analog.com>
On Thu, 04 Jun 2026 10:58:54 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> This patch series adds support for the Analog Devices ADF41513 and ADF41510
> ultralow noise PLL frequency synthesizers. These devices are designed for
> implementing local oscillators (LOs) in high-frequency applications.
> The ADF41513 covers frequencies from 1 GHz to 26.5 GHz, while the ADF41510
> operates from 1 GHz to 10 GHz.
>
> Key features supported by this driver:
> - Integer-N and fractional-N operation modes
> - High maximum PFD frequency (250 MHz integer-N, 125 MHz fractional-N)
> - 25-bit fixed modulus or 49-bit variable modulus fractional modes
> - Digital lock detect functionality
> - Phase resync capability for consistent output phase
> - Load Enable vs Reference signal syncronization
>
> The series includes:
> 1. PLL driver implementation
> 2. Device tree bindings documentation
> 3. IIO ABI documentation
> 4. Parsing utils for 64-bit decimal values
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Applied to the testing branch of iio.git
Thanks for your persistence with this. On a particular plus I think this
is the largest series I've yet seen that Sashiko gave a clean bill of health
to (so not even any false positives!)
Jonathan
> ---
> Changes in v16:
> - Incorporate Andy's series: https://lore.kernel.org/all/20260602203706.103449-1-andriy.shevchenko@linux.intel.com
> - Drop iio_val_s64_to_s32s() and iio_val_s64_from_s32s().
> - Add/change comments and minor changes.
> - Link to v15: https://lore.kernel.org/r/20260531-adf41513-iio-driver-v15-0-da09adf1c0dd@analog.com
>
> Changes in v15:
> - Set bleed value when chaging mode.
> - Link to v14: https://lore.kernel.org/r/20260524-adf41513-iio-driver-v14-0-06824d9c15f4@analog.com
>
> Changes in v14:
> - Review include headers.
> - Use named fields in spi device table.
> - Address relevant sashiko's feedback.
> - Minor tweaks to iio core changes.
> - Link to v13: https://lore.kernel.org/r/20260517-adf41513-iio-driver-v13-0-bb6e134a360f@analog.com
>
> Changes in v13:
> - Introduce _parse_integer_limit_init()
> - Better support for 0 and larger scales in kstrtodec64()
> - Increase test scope for kstrtodec64()
> - Fix LSB_P1 check at startup when going for fixed modulus mode.
> - Clear phase adjust when setting phase (It turns out sashiko was correct).
> - Make sure Load Enable is not selected when powering up.
> - Address some minor comments.
> - Link to v12: https://lore.kernel.org/r/20260510-adf41513-iio-driver-v12-0-34af2ed2779f@analog.com
>
> Changes in v12:
> - Contraint charge pump current.
> - Fix division-by-zero issues.
> - Address PM and sysfs powerdown conflicts.
> - Program proper phase resync value in clk divider mode.
> - Link to v11: https://lore.kernel.org/r/20260506-adf41513-iio-driver-v11-0-2b7e99cfe8f2@analog.com
>
> Changes in v11:
> - Cleanup ext info attribute read/write callbacks.
> - Adjust attribute names in the documentation.
> - Turn s64 compose macros into static inline functions.
> - Link to v10: https://lore.kernel.org/r/20260415-adf41513-iio-driver-v10-0-df61046d5457@analog.com
>
> Changes in v10:
> - Drop simple_strntoull() changes
> - Create kstrtodec64() and kstrtoudec64() helpers.
> - Add IIO value format for 64-bit decimal values.
> - PLL driver code implements new decimal format for frequency attr.
> - Link to v9: https://lore.kernel.org/r/20260320-adf41513-iio-driver-v9-0-132f0d076374@analog.com
>
> Changes in v9:
> - Expose simple_strntoull() in a safer prototype instead of new kstrntoull()
> - Link to v8: https://lore.kernel.org/r/20260303-adf41513-iio-driver-v8-0-8dd2417cc465@analog.com
>
> Changes in v8:
> - Add new function kstrntoull() to lib/kstrtox.c and tests to lib/test-kstrtox.c.
> - Drop custom iio u64 parser, replacing it for kstrntoull().
> - Dedicated MAINTAINERS entry for drivers/iio/test/iio-test-fixpoint-parse.c.
> - Link to v7: https://lore.kernel.org/r/20260216-adf41513-iio-driver-v7-0-b0ed387ab559@analog.com
>
> Changes in v7:
> - Addressed minor suggestions.
> - frequency_resolution ABI for AD4350 removed in favor of generic one.
> - Link to v6: https://lore.kernel.org/r/20260130-adf41513-iio-driver-v6-0-cf46239026bc@analog.com
>
> Changes in v6:
> - Drop usage of simple_strtoull().
> - Implement better overflow checks with iio_safe_strntou64().
> - Link to v5: https://lore.kernel.org/r/20260123-adf41513-iio-driver-v5-0-2dce812a2dda@analog.com
>
> Changes in v5:
> - Drop local parsing of 64-bit plus fractional parts
> - Add iio_str_to_fixpoint64() to iio core with parsing tests
> - Add DT property dependency for adi,charge-pump-resistor-ohms
> - Add local definition for ADF41513_HZ_PER_GHZ and drop units.h patch
> - Link to v4: https://lore.kernel.org/r/20260116-adf41513-iio-driver-v4-0-dbb7d6782217@analog.com
>
> Changes in v4:
> - Proper usage of units.h macros
> - Simplifications to DT property parsing
> - Adjustments to return value handling
> - Drop of simple DT property node example
> - Link to v3: https://lore.kernel.org/r/20260108-adf41513-iio-driver-v3-0-23d1371aef48@analog.com
>
> Changes in v3:
> - Use FIELD_MODIFY macro in driver implementation
> - Drop refin_frequency iio attribute
> - Drop muxout-select property from dt-bindings (and rename logic-level property)
> - Use -mhz suffix in power-up frequency property
> - Address documentation issues
> - Link to v2: https://lore.kernel.org/r/20251219-adf41513-iio-driver-v2-0-be29a83d5793@analog.com
>
> Changes in v2:
> - separate driver implementation from extra features and improve commit messages
> - use macros from units.h
> - explanation of custom parse function: adf41513_parse_uhz
> - reorganize driver data structures
> - drop clock framework support for now
> - reorganize documentation
> - Link to v1: https://lore.kernel.org/r/20251110-adf41513-iio-driver-v1-0-2df8be0fdc6e@analog.com
>
> ---
> Andy Shevchenko (2):
> lib: kstrtox: Make _parse_integer() take variadic arguments
> lib: vsprintf: use _parse_integer() instead of _parse_integer_limit()
>
> Rodrigo Alencar (12):
> dt-bindings: iio: frequency: add adf41513
> lib: kstrtox: add initial value to _parse_integer_limit()
> lib: kstrtox: add kstrtoudec64() and kstrtodec64()
> lib: test-kstrtox: tests for kstrtodec64() and kstrtoudec64()
> lib: math: div64: add div64_s64_rem()
> iio: core: add decimal value formatting into 64-bit value
> iio: test: iio-test-format: add test case for decimal format
> iio: frequency: adf41513: driver implementation
> iio: frequency: adf41513: handle LE synchronization feature
> iio: frequency: adf41513: features on frequency change
> docs: iio: add documentation for adf41513 driver
> Documentation: ABI: testing: add common ABI file for iio/frequency
>
> Documentation/ABI/testing/sysfs-bus-iio-frequency | 11 +
> .../ABI/testing/sysfs-bus-iio-frequency-adf4350 | 10 -
> .../bindings/iio/frequency/adi,adf41513.yaml | 227 ++++
> Documentation/iio/adf41513.rst | 199 ++++
> Documentation/iio/index.rst | 1 +
> MAINTAINERS | 9 +
> drivers/iio/frequency/Kconfig | 10 +
> drivers/iio/frequency/Makefile | 1 +
> drivers/iio/frequency/adf41513.c | 1246 ++++++++++++++++++++
> drivers/iio/industrialio-core.c | 49 +-
> drivers/iio/test/iio-test-format.c | 97 +-
> include/linux/iio/types.h | 20 +
> include/linux/kstrtox.h | 3 +
> include/linux/math64.h | 18 +
> lib/kstrtox.c | 114 +-
> lib/kstrtox.h | 17 +-
> lib/math/div64.c | 15 +
> lib/test-kstrtox.c | 182 +++
> lib/vsprintf.c | 2 +-
> 19 files changed, 2178 insertions(+), 53 deletions(-)
> ---
> base-commit: ae696dfa47c30016cd429b9db5e70b259b8f509e
> change-id: 20251110-adf41513-iio-driver-aaca8a7f808e
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v3 00/13] Support ACPI and SETAASA device discovery
From: Alexandre Belloni @ 2026-06-14 20:56 UTC (permalink / raw)
To: Akhil R
Cc: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Saket Dumbre, Len Brown, Guenter Roeck,
Philipp Zabel, Bjorn Andersson, Geert Uytterhoeven,
Dmitry Baryshkov, Arnd Bergmann, Eric Biggers, Wolfram Sang,
Miquel Raynal, Jon Hunter, Thierry Reding, linux-tegra, linux-i3c,
devicetree, linux-kernel, linux-acpi, acpica-devel, linux-hwmon
In-Reply-To: <20260423085718.70762-1-akhilrajeev@nvidia.com>
Hello,
On 23/04/2026 14:26:59+0530, Akhil R wrote:
> This patch series adds SETAASA device discovery to the I3C subsystem,
> enabling support for SPD5118 temperature sensors found on DDR5 memory
> modules. The changes also add ACPI support for all existing DAA
> methods like SETDASA, SETNEWDA as well as I2C devices on I3C bus.
>
> SPD5118 and similar devices on DDR5 memory modules differ from typical
> I3C devices in their initialization. They use SETAASA broadcast CCC
> instead of ENTDAA for address assignment, and per JEDEC specification,
> are not required to have a Provisioned ID or implement standard device
> information CCC commands (GETPID, GETDCR, GETBCR).
>
> The series enables to describe all I3C and I2C devices on both Device
> Tree and the ACPI table, using unified device property APIs throughout
> the I3C core and the Synopsys DesignWare I3C master driver.
>
> Please note that the series modifies drivers across multiple subsystems,
> like Device Tree bindings, ACPI, I3C and HWMON.
>
> v2->v3:
> * Fix maximum value and indent bit list for mipi-i3c-static-method.
> * Move I3C_ADDR_METHOD_* macros to dt-bindings header.
> * Drop ACPICA commit IDs, keep only the Link: tags.
> * Revert the change which proceeds to register other devices if SETAASA
> is not supported so that it aligns with the rest of the driver and to
> avoid the issues pointed by Sashiko.
> * Rework multiple commit messages.
>
> v1->v2:
> * Added patch to remove 16-bit addressing support for SPD5118
> * Guard ACPI calls with #ifdef CONFIG_ACPI
> * Remove CONFIG_OF guard for of_alias_get_highest_id()
> * Mask mipi-i3c-static-method in the driver to select only valid values.
> * Proceed to register other devices if SETAASA is not supported.
> * Update commit message and links in the description of multiple commits.
>
>
> Akhil R (13):
> dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
> ACPICA: Read LVR from the I2C resource descriptor
> i3c: master: Use unified device property interface
> i3c: master: Support ACPI enumeration of child devices
> i3c: master: Add support for devices using SETAASA
> i3c: master: Add support for devices without PID
> i3c: master: match I3C device through DT and ACPI
> i3c: dw-i3c-master: Add SETAASA as supported CCC
> i3c: dw-i3c-master: Add a quirk to skip clock and reset
> i3c: dw-i3c-master: Add ACPI ID for Tegra410
> hwmon: spd5118: Remove 16-bit addressing
> hwmon: spd5118: Add I3C support
> arm64: defconfig: Enable I3C and SPD5118 hwmon
>
I'd really like to apply this but I would have preferred having an
actual ack from Rob on patch 1. Also, you are going to have to rebase on
the current i3c-next. Can you do this?
Thanks!
> .../devicetree/bindings/i3c/i3c.yaml | 31 +-
> arch/arm64/configs/defconfig | 3 +
> drivers/acpi/acpica/rsserial.c | 6 +-
> drivers/hwmon/Kconfig | 9 +-
> drivers/hwmon/spd5118.c | 119 +++---
> drivers/i3c/master.c | 354 +++++++++++++++---
> drivers/i3c/master/dw-i3c-master.c | 66 ++--
> include/acpi/acrestyp.h | 1 +
> include/dt-bindings/i3c/i3c.h | 3 +
> include/linux/i3c/ccc.h | 1 +
> include/linux/i3c/master.h | 20 +-
> 11 files changed, 463 insertions(+), 150 deletions(-)
>
> --
> 2.50.1
>
>
> --
> linux-i3c mailing list
> linux-i3c@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-i3c
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 2/5] iio: adc: Add ti-ads1262 driver
From: Kurt Borja @ 2026-06-14 20:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kurt Borja
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, David Lechner, Nuno Sá,
Andy Shevchenko, linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260613-sparkling-naughty-tuna-3e9bf1@quoll>
On Sat Jun 13, 2026 at 1:59 PM -05, Krzysztof Kozlowski wrote:
[...]
> Functions used by probe() should be before probe(), not somewhere in the
> middle of the code. IOW, entire probe is together.
I they all are, it's just that regmap stuff takes a huge chunk. I'll
check how to reorganize.
[...]
>> +static const struct of_device_id ads1262_of_match[] = {
>> + { .compatible = "ti,ads1262" },
>> + { .compatible = "ti,ads1263" },
>
> So devices are fully compatible? Then it should be expressed in the
> binding and drop one entry here.
Not fully compatible as Jonathan said. One is a subset of the other.
I'll make it more clear in the commit message.
>
> Best regards,
> Krzysztof
Ack to the rest of comments.
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: adc: Add TI ADS126x ADC family
From: Kurt Borja @ 2026-06-14 20:53 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kurt Borja
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, David Lechner, Nuno Sá,
Andy Shevchenko, linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260613-loyal-azure-goldfish-cf6d54@quoll>
Hi Krzysztof,
On Sat Jun 13, 2026 at 1:54 PM -05, Krzysztof Kozlowski wrote:
> On Fri, Jun 12, 2026 at 05:46:19PM -0500, Kurt Borja wrote:
>> + ti,neg-refmux:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + Selects the negative voltage reference input:
>> + 0: Internal 2.5 V reference
>> + 1: AIN1 pin
>> + 2: AIN3 pin
>> + 3: AIN5 pin
>> + 4: AVSS pin
>> + minimum: 0
>> + maximum: 4
>> + default: 0
>> +
>> + ti,vbias:
>> + $ref: /schemas/types.yaml#/definitions/flag
>> + description: Enables the level-shift voltage on the AINCOM pin.
>> + default: false
>
> There is no such syntax, drop.
The "default: false" syntax? Sure I'll drop.
>
>> +
>> + ti,idac1-pin:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + Selects the analog input pin to connect IDAC1:
>> + 0: AIN0
>> + 1: AIN1
>> + 2: AIN2
>> + 3: AIN3
>> + 4: AIN4
>> + 5: AIN5
>> + 6: AIN6
>> + 7: AIN7
>> + 8: AIN8
>> + 9: AIN9
>> + 10: AINCOM
>> + 11: No Connection
>> + minimum: 0
>> + maximum: 11
>> + default: 11
>> +
>> + ti,idac1-microamp:
>> + description: Selects the current values of IDAC1.
>> + enum: [0, 50, 100, 250, 500, 750, 1000, 1500, 2000, 2500, 3000]
>> + default: 0
>> +
>> + ti,idac2-pin:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: |
>> + Selects the analog input pin to connect IDAC2:
>> + 0: AIN0
>> + 1: AIN1
>> + 2: AIN2
>> + 3: AIN3
>> + 4: AIN4
>> + 5: AIN5
>> + 6: AIN6
>> + 7: AIN7
>> + 8: AIN8
>> + 9: AIN9
>> + 10: AINCOM
>> + 11: No Connection
>> + minimum: 0
>> + maximum: 11
>> + default: 11
>> +
>> + ti,idac2-microamp:
>> + description: Selects the current values of IDAC2.
>> + enum: [0, 50, 100, 250, 500, 750, 1000, 1500, 2000, 2500, 3000]
>> + default: 0
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + '#io-channel-cells':
>> + const: 1
>> +
>> + '#gpio-cells':
>> + const: 2
>> +
>> + gpio-controller: true
>> +
>> + adc:
>> + $ref: /schemas/iio/adc/ti,ads1263-adc2.yaml#
>
> Not a separate device node. Fold into the parent... or explain in
> commit msg. You have entire commit msg to explain odd things.
>
> In that binding description you call it "independent", so it should have
> its own SPI chip select? Why "independent" and part of this binding?
> Maybe not independent, so basically part of this device?
It's independent in the sense that it is a proper subdevice on the same
chip. It shares the serial interface but operates completely in
parallel.
I decided to add a subnode because other devices might request their
io-channels and most importantly a different voltage reference might be
connected to it.
I'll clarify this in the commmit message on the next version. Although
after seeing this submitted bindings [1], I wonder if it's a better
approach to do something like
spi@0 {
mydevice@0 {
...
adc@0 { ... };
adc@1 { ... };
};
};
Any thoughts?
> Best regards,
> Krzysztof
Ack to the rest of comments.
[1] https://lore.kernel.org/linux-iio/20260519-ad5529r-driver-v3-1-267c0731aa68@analog.com/
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH 5/5] iio: adc: Add ti-ads1263-adc2 driver
From: Kurt Borja @ 2026-06-14 20:43 UTC (permalink / raw)
To: Jonathan Cameron, Kurt Borja
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260613151047.57cd074f@jic23-huawei>
On Sat Jun 13, 2026 at 9:10 AM -05, Jonathan Cameron wrote:
> On Fri, 12 Jun 2026 17:46:23 -0500
> Kurt Borja <kuurtb@gmail.com> wrote:
>
>> The TI ADS1263 includes an auxiliary, 24-bit, delta-sigma ADC (ADC2).
>> ADC2 operation is independent of ADC1, with independent selections of
>> input channel, reference voltage, sample rate, and channel gain
>>
>> Add support for this ADC as an independent IIO device, through the
>> auxiliary bus API.
>
> A few things inline.
>
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>
>> diff --git a/drivers/iio/adc/ti-ads1262.c b/drivers/iio/adc/ti-ads1262.c
>> index b33505e7fdc7..1a4b2f934d43 100644
>> --- a/drivers/iio/adc/ti-ads1262.c
>> +++ b/drivers/iio/adc/ti-ads1262.c
>
>> +static int ads1262_aux_device_setup(struct ads1262 *st)
>> +{
>> + struct device *dev = &st->spi->dev;
>> + struct ads1263_adc2_channel *chans;
>> + struct auxiliary_device *adev;
>> + struct ads1263_adc2_ctx *ctx;
>> + struct fwnode_handle *node;
>> + int id, ret;
>> +
>> + node = device_get_named_child_node(dev, "adc");
>> + if (!node)
>> + return 0;
>> +
>> + ctx = kzalloc_obj(*ctx);
>> + if (!ctx) {
>> + ret = -ENOMEM;
>> + goto out_node_put;
>> + }
>> +
>> + id = ida_alloc(&ads1262_ida, GFP_KERNEL);
>> + if (id < 0) {
>> + ret = id;
>> + goto out_free_adc2;
>> + }
>> +
>> + chans = kcalloc(st->num_channels, sizeof(*chans), GFP_KERNEL);
>> + if (!chans) {
>> + ret = -ENOMEM;
>> + goto out_free_id;
>> + }
>> +
>> + for (unsigned int i = 0; i < st->num_channels; i++) {
>> + chans[i].negative_input = st->channels[i].negative_input;
>> + chans[i].positive_input = st->channels[i].positive_input;
>> + }
>> +
>> + ctx->chip = st;
>> + ctx->num_channels = st->num_channels;
>> + ctx->channels = chans;
>> + ctx->enable = ads1263_adc2_enable;
>> + ctx->start = ads1263_adc2_start;
>> + ctx->stop = ads1263_adc2_stop;
>> + ctx->read = ads1263_adc2_read;
>> + mutex_init(&ctx->chan_lock);
> devm_mutex_init()
I actually call mutex_destroy() on device .release.
I think it makes more sense that way, otherwise we would UAF?
[...]
>> +struct ads1263_adc2_ctx {
>> + struct auxiliary_device adev;
>> + struct ads1262 *chip;
>> + /* Protects channel state */
>> + struct mutex chan_lock;
>> + struct ads1263_adc2_channel *channels;
>> + unsigned int num_channels;
>> + int (*enable)(struct ads1263_adc2_ctx *ctx,
>> + const struct ads1263_adc2_channel *chan);
>> + int (*start)(struct ads1263_adc2_ctx *ctx);
>> + int (*stop)(struct ads1263_adc2_ctx *ctx);
>> + int (*read)(struct ads1263_adc2_ctx *ctx, __be32 *val);
>
> I'm not sure I see this loose coupling as that useful. I'd just export the
> functions from the other module and add them to this header.
> Maybe I'm missing why you need this complexity.
I'll go for the exported (NS) functions. Much cleaner that way.
I don't know where did I read this callback approach was a way to handle
auxiliary devices and I got fixated on that.
[...]
>> +static int ads1263_adc2_channels_setup(struct iio_dev *indio_dev)
>> +{
>> + struct ads1263_adc2 *st = iio_priv(indio_dev);
>> + struct device *dev = &st->ctx->adev.dev;
>> + struct ads1263_adc2_ctx *ctx = st->ctx;
>> + struct iio_chan_spec *chns;
>> + unsigned int i;
>> +
>> + /* Account for the timestamp channel */
>> + chns = devm_kcalloc(dev, ctx->num_channels + 1, sizeof(*chns),
>> + GFP_KERNEL);
>> + if (!chns)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < ctx->num_channels; i++) {
>> + guard(mutex)(&ctx->chan_lock);
>> +
>> + ctx->channels[i].refmux = st->refmux;
>> +
>> + chns[i] = ads1263_adc2_iio_voltage_template;
> Rather than using a template like this I'd just set it all here using
> a designated initializer. Means there is one place to see all the fields.
>
> chns[i] = (struct iio_chan_spec) {
> .type = IIO_VOLTAGE,
> .indexed = true,
> .differential = true, //not sure why this wasn't in your template.
> .channel = ctx->channels[i].positive_input;
> .channel2 = ctx->channels[i].negative_input;
> .scan_index = i,
> .scan_type = {
> .format = IIO_SCAN_FORMAT_SIGNED_INT,
> .realbits = 24,
> .storagebits = 32,
> .shift = 8,
> .endianness = IIO_BE,
> },
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> BIT(IIO_CHAN_INFO_SCALE) |
> BIT(IIO_CHAN_INFO_HARDWAREGAIN) |
> BIT(IIO_CHAN_INFO_SAMP_FREQ),
> .info_mask_shared_by_all_available =
> BIT(IIO_CHAN_INFO_HARDWAREGAIN) |
> BIT(IIO_CHAN_INFO_SAMP_FREQ),
Sounds good to me.
> }
>> + chns[i].scan_index = i;
>> + chns[i].channel = ctx->channels[i].positive_input;
>> + chns[i].channel2 = ctx->channels[i].negative_input;
>> + chns[i].differential = true;
>> + }
>> +
>> + chns[i] = (struct iio_chan_spec)
>> + IIO_CHAN_SOFT_TIMESTAMP(ctx->num_channels - 1);
> That macro has recently become a designated intializer so
> chns[i] = IIO_CHAN_SOFT_TIMESTAMP(ctx->num_channels - 1);
>
>> + chns[i].scan_index = i;
>
> Isn't this just overwriting the ctx->num_channels - 1 we just
> passed in above?
It is. Thanks!
[...]
>> +static const struct auxiliary_device_id ads1263_adc2_auxiliary_match[] = {
>> + { .name = "ti_ads1262.ads1263_adc2",
>> + .driver_data = (kernel_ulong_t)"ads1263_adc2" },
> {
> .name = "ti_ads1262.ads1263_adc2",
> .driver_data = (kernel_ulong_t)"ads1263_adc2",
>
> Though I really don't like forcing that cast in there and it should be irrelevant
> given there is only one entry in this table. Should be fine to just hard code that
> where used. If you need this later, wrap it in a structure.
You're right. I'll add a NAME macro.
I don't think we'll ever add entries here.
>
> },
>
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(auxiliary, ads1263_adc2_auxiliary_match);
Thanks for your feedback, Jonathan! Apologies if this version was a
little rough... I'm a bit embarrased by the bugs found by Sashiko.
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: (subset) [PATCH v7 0/5] Add microchip sama7d65 SoC I3C support
From: Alexandre Belloni @ 2026-06-14 20:39 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, nicolas.ferre, claudiu.beznea,
linux, mturquette, sboyd, bmasney, aubin.constans, Ryan.Wanner,
romain.sioen, tytso, cristian.birsan, adrian.hunter, npitre,
linux-i3c, devicetree, linux-kernel, linux-arm-kernel, linux-clk,
Manikandan Muralidharan
In-Reply-To: <20260525092405.1514213-1-manikandan.m@microchip.com>
On Mon, 25 May 2026 14:54:00 +0530, Manikandan Muralidharan wrote:
> Add support for microchip sama7d65 SoC I3C master only IP which is
> based on mipi-i3c-hci from synopsys implementing version 1.0
> specification. The platform specific changes are integrated in the
> mipi-i3c-hci driver using existing quirks.
>
> I3C in master mode supports up to 12.5MHz, SDR mode data transfer in
> mixed bus mode (I2C and I3C target devices on same i3c bus).
>
> [...]
Applied, thanks!
[1/5] dt-bindings: i3c: mipi-i3c-hci: add Microchip SAMA7D65 compatible
https://git.kernel.org/i3c/c/9092105b87af
[3/5] i3c: mipi-i3c-hci: add microchip sama7d65 SoC compatible with the required quirk
https://git.kernel.org/i3c/c/efaa912ab0f1
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: exynos: Add bluetooth support to manta
From: sashiko-bot @ 2026-06-14 20:32 UTC (permalink / raw)
To: Lukas Timmermann; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260614-manta-bluetooth-v2-1-52de06cabf9d@timmermann.space>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `max-speed` property in the Bluetooth node significantly restricts UART bandwidth.
--
commit 661518d39bb3c0a9a3884e1d914c3ff2bc70cf74
Author: Lukas Timmermann <linux@timmermann.space>
ARM: dts: exynos: Add bluetooth support to manta
This commit enables the bcm4330-bt device for manta boards on serial0.
It also adds the necessary pin definitions and interrupt handling for wakeup.
> diff --git a/arch/arm/boot/dts/samsung/exynos5250-manta.dts b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> index 24a27b342227b..76d3657eb22f0 100644
> --- a/arch/arm/boot/dts/samsung/exynos5250-manta.dts
> +++ b/arch/arm/boot/dts/samsung/exynos5250-manta.dts
[ ... ]
> @@ -536,7 +557,25 @@ &sd1_cmd {
>
> /* Bluetooth */
> &serial_0 {
> - status = "disabled";
> + pinctrl-0 = <&uart0_data &uart0_fctl>;
> + pinctrl-names = "default";
> +
> + bluetooth {
> + compatible = "brcm,bcm4330-bt";
> +
> + pinctrl-0 = <&bt_reg_on &bt_wake &bt_host_wakeup>;
[Severity: Medium]
Should this node include a max-speed property to negotiate a high-speed
UART connection?
Without max-speed, the brcm,bcm4330-bt driver in drivers/bluetooth/hci_bcm.c
leaves the oper_speed at 0 and skips negotiating a higher baud rate. This
forces the UART to operate at its default 115200 bps.
Operating at 115200 bps restricts the bandwidth to around 11.5 KB/s, which
can cause high-bandwidth Bluetooth profiles like A2DP to stutter or fail.
Other Exynos boards typically set max-speed (e.g., max-speed = <3000000>)
to prevent this bottleneck.
> + pinctrl-names = "default";
> +
> + shutdown-gpios = <&gph0 0 GPIO_ACTIVE_HIGH>;
> + device-wakeup-gpios = <&gph1 3 GPIO_ACTIVE_HIGH>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-manta-bluetooth-v2-1-52de06cabf9d@timmermann.space?part=1
^ permalink raw reply
* Re: [PATCH 4/5] iio: adc: ti-ads1262: Add calibration support
From: Kurt Borja @ 2026-06-14 20:31 UTC (permalink / raw)
To: Jonathan Cameron, Kurt Borja
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, David Lechner, Nuno Sá, Andy Shevchenko,
linux-iio, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260613145055.06aedf2b@jic23-huawei>
On Sat Jun 13, 2026 at 8:50 AM -05, Jonathan Cameron wrote:
> On Fri, 12 Jun 2026 17:46:22 -0500
> Kurt Borja <kuurtb@gmail.com> wrote:
>
>> Add channel calibration support.
>>
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---
[...]
> Read it into a u8 [3] and use get_unaligned_le24()
> That avoids us having to think too much about the bits that aren't
> initialized and static analysis / compilers having to figure out
> they don't matter. I general it is easier to understand.
I didn't know there was a 24 bit version. I'll definitely use it.
>
>> + if (ret)
>> + return ret;
>> + *val = sign_extend32(le32_to_cpu(lval), 23);
>> +
>> + return 0;
>> +}
>> +
>> +static int ads1262_write_calib(struct ads1262 *st, unsigned int reg, u32 val)
>> +{
>> + __le32 lval = cpu_to_le32(val);
>> +
>> + /*
>> + * The calibration word is a signed 24 bit LSB-first value.
>> + */
>> + return regmap_bulk_write(st->regmap, reg, &lval, 3);
>
> Similar with a u8 [3] for the '__le24' storage.
>
>> +}
>> +
--
Thanks,
~ Kurt
^ 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