* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Jie Luo @ 2026-06-23 9:08 UTC (permalink / raw)
To: Andrew Lunn, Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lei Wei, Suruchi Agarwal, Pavithra R, linux-kernel, linux-arm-msm,
linux-clk, devicetree, netdev
In-Reply-To: <0247dfba-1c14-4fea-aab3-5489a36f35f6@lunn.ch>
On 6/23/2026 4:10 PM, Andrew Lunn wrote:
> Emails to the maintainer of Qualcomm PPE Ethernet driver (Luo Jie
> <quic_luoj@quicinc.com>) bounce permanently (full mailbox), because the
> "quicinc.com" addresses were deprecated for public work. All Qualcomm
> contributors are aware of that and were asked to fix their addresses.
>
> Driver is not supported - in terms of how netdev understands supported
> commitment - if maintainer does not care to receive the patches for its
> code, so demote it to "maintained" to reflect true status.
>
> Fix all occurences of Luo Jie email address to preferred and working
> domain.
Thanks a lot for fixing my email address and for the help!
Acked-by: Luo Jie <jie.luo@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: sound: add qcom,wsa885x-i2c
From: Prasad Kumpatla @ 2026-06-23 9:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Linus Walleij, Bartosz Golaszewski, Srinivas Kandagatla,
linux-arm-msm, linux-sound, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260611-debonair-barnacle-of-action-ee9d22@quoll>
On 6/11/2026 3:04 PM, Krzysztof Kozlowski wrote:
> On Wed, Jun 10, 2026 at 09:27:07PM +0530, Prasad Kumpatla wrote:
>> Document the Qualcomm WSA885X I2C smart amplifier binding.
>>
>> Describe the required supplies, powerdown and interrupt GPIOs, the
>> optional battery configuration, and the optional init-table property
>> used to program the device during codec initialization.
>>
>> This matches the driver programming model and documents the DT data
> Binding matches hardware, not driver. Please describe the hardware.
Hi Krzysztof,
Thanks for reviewing the patch and for the feedback.
Ack, Will add more HW details in next version.
>
>> needed to use the codec on platforms with Audio IF playback.
>>
>> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
>> ---
>> .../bindings/sound/qcom,wsa885x-i2c.yaml | 89 +++++++++++++++++++
>> 1 file changed, 89 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
>> new file mode 100644
>> index 000000000..1069f470d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
> There is no I2C in device name.
Ack, Will remove.
>
>> @@ -0,0 +1,89 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/sound/qcom,wsa885x-i2c.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm WSA885x I2C smart speaker amplifier
>> +
>> +maintainers:
>> + - Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>> + - Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
>> +
>> +description: |
> Do not need '|' unless you need to preserve formatting.
Ack, Will Update.
>
>> + WSA885x is a Qualcomm Aqstic smart speaker amplifier with an I2C control
>> + interface and a digital audio interface exposed through ASoC DAI callbacks.
>> +
>> +allOf:
>> + - $ref: dai-common.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: qcom,wsa885x-i2c
> Same here
>
> Also, incorrect usage of wildcard. Look at other bindings how this is
> written, so you will not repeat the same comments:
> https://lore.kernel.org/all/20250522-rb2_audio_v3-v3-3-9eeb08cab9dc@linaro.org/
>
> Read writing bindings before posting next version.
>
> I also cannot find traces of internal review of this. Did it happen? Did
> you receive toolset comments?
Ack, Thanks for the reference link, will cross check and update the
bindings.
No, there is o internal review done for this patch due to timelines.
>
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + '#sound-dai-cells':
>> + const: 0
>> +
>> + powerdown-gpios:
>> + description: GPIO controlling the SD_N powerdown pin.
>> + maxItems: 1
>> +
>> + interrupt-gpios:
> No, interrupts are never written as GPIOs.
>
> Where is this binding coming from?
Agree, Will remove this and come up standard interrupt bindings in next
version.
>
>> + description: GPIO used for the codec interrupt output.
>> + maxItems: 1
>> +
>> + vdd-1p8-supply: true
>> +
>> + vdd-io-supply: true
>> +
>> + qcom,battery-config:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: Speaker battery configuration, 1 for 1S and 2 for 2S.
> Use string
Ack.
>
>> + default: 1
>> + enum: [1, 2]
>> +
>> + qcom,wsa885x-init-table:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 2
>> + maxItems: 256
>> + description: |
>> + Sequence of register/value pairs applied during codec hardware
> No, we don't store register values usually.
Ack,I'll move them into the driver as a register table,
making them easier to maintain and avoiding opaque DT data.
>> + initialization. Entries are encoded as alternating register address and
>> + register value cells. The number of entries must be even (register/value
>> + pairs); maxItems is 256 (128 pairs).
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - '#sound-dai-cells'
>> + - powerdown-gpios
>> + - interrupt-gpios
>> + - vdd-1p8-supply
>> + - vdd-io-supply
>> +
>> +additionalProperties: false
> unevaluated instead. Again, OPEN other existing bindings. Why doing
> something completely different? Is there any WSA88xx binding with
> additionalProperties? No.
Thanks for pointing this out. I'll align the schema with the existing
WSA88xx
bindings and replace additionalProperties: false with
unevaluatedProperties: false
in the next revision.
Thanks,
Prasad
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Markus Elfring @ 2026-06-23 9:05 UTC (permalink / raw)
To: Amit Barzilai, dri-devel, devicetree, linux-fbdev, linux-staging,
Andy Shevchenko, Conor Dooley, David Airlie, Greg Kroah-Hartman,
Helge Deller, Javier Martinez Canillas, Krzysztof Kozlowski,
Maarten Lankhorst, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann
Cc: LKML, Adam Azuddin, Chintan Patel
In-Reply-To: <20260622152506.78627-4-amit.barzilai22@gmail.com>
…
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> @@ -146,6 +146,33 @@
> #define SSD133X_COLOR_DEPTH_256 0x0
> #define SSD133X_COLOR_DEPTH_65K 0x1
>
> +/* ssd135x commands */
> +#define SSD135X_SET_COL_RANGE 0x15
> +#define SSD135X_WRITE_RAM 0x5c
> +#define SSD135X_SET_ROW_RANGE 0x75
…
How do you think about to use an enumeration for such data?
https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family
From: Andy Shevchenko @ 2026-06-23 9:03 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-3-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:04PM +0300, Amit Barzilai wrote:
> SSD133X screens were getting 8bpp (RGB332) instead of the 16bpp
> (RGB565) that they support. This change adds a boolean to the
> deviceinfo struct selecting whether the variant is driven at
> DRM_FORMAT_RGB565.
>
> Changed SSD133X to now utilize 65k color (RGB565).
...
> - * Each Segment has a 8-bit pixel and each Common output has a
> - * row of pixels. When using the (default) horizontal address
> - * increment mode, each byte of data sent to the controller has
> - * a Segment (e.g: SEG0).
> + * Each Segment holds one pixel and each Common output has a row
> + * of pixels. A pixel is 8 bits (one byte) in the 256 color
> + * (RGB332) format or 16 bits (two bytes) in the 65k color
> + * (RGB565) format. When using the (default) horizontal address
> + * increment mode, the pixel data is sent Segment by Segment
> + * (e.g: SEG0 first).
> *
> * When using the 256 color depth format, each pixel contains 3
> * sub-pixels for color A, B and C. These have 3 bit, 3 bit and
> * 2 bits respectively.
Something wrong with the plural. There is a difference between "3-bit" and
"3 bits", but "3 bit" is odd.
> + *
> + * When using the 65k color depth format, each pixel contains 3
> + * sub-pixels for color A, B and C. These have 5 bit, 6 bit and
> + * 5 bits respectively.
Same mistake is repeated here.
...
> + /*
> + * Per-variant output format selector for the SSD133X data path. The
> + * hardware can drive the panel in RGB332 (1 byte/pixel) or RGB565
> + * (2 bytes/pixel); this is a policy choice per variant, not a
In other comments it was spelled fully, be consistent "1 byte per pixel",
"2 bytes per pixel".
> + * capability probe. When set, the variant is driven at RGB565.
> + */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V13 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
From: Jean-Baptiste Maneyrol @ 2026-06-23 8:14 UTC (permalink / raw)
To: Chris Morgan
Cc: Jonathan Cameron, Chris Morgan, linux-iio@vger.kernel.org,
andy@kernel.org, nuno.sa@analog.com, dlechner@baylibre.com,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
heiko@sntech.de, conor+dt@kernel.org, krzk+dt@kernel.org,
robh@kernel.org, andriy.shevchenko@intel.com, Krzysztof Kozlowski
In-Reply-To: <PH0PR19MB997338ED05370F27B730FEE60CA5EE2@PH0PR19MB997338.namprd19.prod.outlook.com>
>From: Chris Morgan <macromorgan@hotmail.com>
>Sent: Tuesday, June 23, 2026 02:06
>To: Jean-Baptiste Maneyrol
>Cc: Jonathan Cameron; Chris Morgan; linux-iio@vger.kernel.org; andy@kernel.org; nuno.sa@analog.com; dlechner@baylibre.com; linux-rockchip@lists.infradead.org; devicetree@vger.kernel.org; heiko@sntech.de; conor+dt@kernel.org; krzk+dt@kernel.org; robh@kernel.org; andriy.shevchenko@intel.com; Krzysztof Kozlowski
>Subject: Re: [PATCH V13 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
>
>On Mon, Jun 22, 2026 at 09: 23: 28AM +0000, Jean-Baptiste Maneyrol wrote: > Hello Chris and Jonathan, > > concerning dt bindings, my initial understanding was that we had a file per > driver. But here, Chris is doing a new driver for
>ZjQcmQRYFpfptBannerStart
>This Message Is From an External Sender
>This message came from outside your organization.
>
>ZjQcmQRYFpfptBannerEnd
>
>On Mon, Jun 22, 2026 at 09:23:28AM +0000, Jean-Baptiste Maneyrol wrote:
>> Hello Chris and Jonathan,
>>
>> concerning dt bindings, my initial understanding was that we had a file per
>> driver. But here, Chris is doing a new driver for icm42607 while adding new
>> bindings here.
>>
>> Does it means we don't have 1 binding file per driver, and there is no need
>> to create a new binding file for inv_icm42607 driver?
>>
>> Despite the naming, icm42607 chips are a complete new design very different
>> than all other icm42600 chips. It using similar IPs for things like the FIFO,
>> but all other parts are different. Especially, it doesn't use banks for
>> registers access but indirect access delegated to the chip internals for
>> accessing certain registers.
>
>For what it's worth I'm not using any of those registers in the driver
>currently; from what I see in the datasheets I was able to find on the
>web the 42607p doesn't do the indirect register access (again unless
>I'm misreading). To be fair I don't have any other icm42607 chips to
>test against. The 42607c does appear to do such register access.
>
>Thank you,
>Chris
Hello Chris,
here is a link to download ICM-42670-P datasheet, this chip is completely similar
to ICM-42607-P:
https://www.invensense.tdk.com/en-us/download-resource/ds-000451-icm-42670-p-datasheet
Indirect register access is required when you want to use the FIFO for configuring
which data is stored inside or when you want to update gyro/accel hardware
offsets (calibbias iio attribute usually). Also required for a lot of more
complex internal chip configuration.
I didn't had a chance to look at your driver currently. I hope to be able to
have a look soon.
I can you give the figures for the required maximum sleep time for accel and
gyro startups and stops. Usually, they are not provided in datasheet (only mean
values).
Thanks for your work,
JB
>
>>
>> Thanks,
>> JB
>>
>> >From: Chris Morgan <macromorgan@hotmail.com>
>> >
>> >Add the ICM42607 and ICM42607P inertial measurement unit.
>> >
>> >This device is functionally very similar to the icm42600 series with a
>> >very different register layout. The driver does not require an
>> >interrupt for these specific chip revisions.
>> >
>> >Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
>> >Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> >---
>> > .../bindings/iio/imu/invensense,icm42600.yaml | 18 +++++++++++++++++-
>> > 1 file changed, 17 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
>> >index 9b2af104f186..81b6e85decd5 100644
>> >--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
>> >+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
>> >@@ -30,6 +30,8 @@ properties:
>> > - invensense,icm42600
>> > - invensense,icm42602
>> > - invensense,icm42605
>> >+ - invensense,icm42607
>> >+ - invensense,icm42607p
>> > - invensense,icm42622
>> > - invensense,icm42631
>> > - invensense,icm42686
>> >@@ -67,10 +69,24 @@ properties:
>> > required:
>> > - compatible
>> > - reg
>> >- - interrupts
>> >
>> > allOf:
>> > - $ref: /schemas/spi/spi-peripheral-props.yaml#
>> >+ - if:
>> >+ properties:
>> >+ compatible:
>> >+ contains:
>> >+ enum:
>> >+ - invensense,icm42600
>> >+ - invensense,icm42602
>> >+ - invensense,icm42605
>> >+ - invensense,icm42622
>> >+ - invensense,icm42631
>> >+ - invensense,icm42686
>> >+ - invensense,icm42688
>> >+ then:
>> >+ required:
>> >+ - interrupts
>> >
>> > unevaluatedProperties: false
>> >
>> >--
>> >2.43.0
>
>
________________________________________
From: Chris Morgan <macromorgan@hotmail.com>
Sent: Tuesday, June 23, 2026 02:06
To: Jean-Baptiste Maneyrol
Cc: Jonathan Cameron; Chris Morgan; linux-iio@vger.kernel.org; andy@kernel.org; nuno.sa@analog.com; dlechner@baylibre.com; linux-rockchip@lists.infradead.org; devicetree@vger.kernel.org; heiko@sntech.de; conor+dt@kernel.org; krzk+dt@kernel.org; robh@kernel.org; andriy.shevchenko@intel.com; Krzysztof Kozlowski
Subject: Re: [PATCH V13 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
On Mon, Jun 22, 2026 at 09: 23: 28AM +0000, Jean-Baptiste Maneyrol wrote: > Hello Chris and Jonathan, > > concerning dt bindings, my initial understanding was that we had a file per > driver. But here, Chris is doing a new driver for
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On Mon, Jun 22, 2026 at 09:23:28AM +0000, Jean-Baptiste Maneyrol wrote:
> Hello Chris and Jonathan,
>
> concerning dt bindings, my initial understanding was that we had a file per
> driver. But here, Chris is doing a new driver for icm42607 while adding new
> bindings here.
>
> Does it means we don't have 1 binding file per driver, and there is no need
> to create a new binding file for inv_icm42607 driver?
>
> Despite the naming, icm42607 chips are a complete new design very different
> than all other icm42600 chips. It using similar IPs for things like the FIFO,
> but all other parts are different. Especially, it doesn't use banks for
> registers access but indirect access delegated to the chip internals for
> accessing certain registers.
For what it's worth I'm not using any of those registers in the driver
currently; from what I see in the datasheets I was able to find on the
web the 42607p doesn't do the indirect register access (again unless
I'm misreading). To be fair I don't have any other icm42607 chips to
test against. The 42607c does appear to do such register access.
Thank you,
Chris
>
> Thanks,
> JB
>
> >From: Chris Morgan <macromorgan@hotmail.com>
> >
> >Add the ICM42607 and ICM42607P inertial measurement unit.
> >
> >This device is functionally very similar to the icm42600 series with a
> >very different register layout. The driver does not require an
> >interrupt for these specific chip revisions.
> >
> >Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> >Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >---
> > .../bindings/iio/imu/invensense,icm42600.yaml | 18 +++++++++++++++++-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> >diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> >index 9b2af104f186..81b6e85decd5 100644
> >--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> >+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> >@@ -30,6 +30,8 @@ properties:
> > - invensense,icm42600
> > - invensense,icm42602
> > - invensense,icm42605
> >+ - invensense,icm42607
> >+ - invensense,icm42607p
> > - invensense,icm42622
> > - invensense,icm42631
> > - invensense,icm42686
> >@@ -67,10 +69,24 @@ properties:
> > required:
> > - compatible
> > - reg
> >- - interrupts
> >
> > allOf:
> > - $ref: /schemas/spi/spi-peripheral-props.yaml#
> >+ - if:
> >+ properties:
> >+ compatible:
> >+ contains:
> >+ enum:
> >+ - invensense,icm42600
> >+ - invensense,icm42602
> >+ - invensense,icm42605
> >+ - invensense,icm42622
> >+ - invensense,icm42631
> >+ - invensense,icm42686
> >+ - invensense,icm42688
> >+ then:
> >+ required:
> >+ - interrupts
> >
> > unevaluatedProperties: false
> >
> >--
> >2.43.0
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support
From: Krzysztof Kozlowski @ 2026-06-23 8:55 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alex Elder, linux-arm-msm,
devicetree, linux-kernel, netdev
In-Reply-To: <20260622-sm8450-ipa-v1-1-532f0299f96e@proton.me>
On Mon, Jun 22, 2026 at 09:44:17PM -0400, Esteban Urrutia wrote:
> Add support for IPA in DT while expanding the IMEM region just enough to
> accommodate the modem tables used by IPA.
> As reference, SM8450 uses IPA v5.1.
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 55 ++++++++++++++++++++++++++++++++----
> 1 file changed, 50 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 56cb6e959e4e..c904720008fa 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2639,6 +2639,47 @@ adreno_smmu: iommu@3da0000 {
> dma-coherent;
> };
>
> + ipa: ipa@3f40000 {
> + compatible = "qcom,sm8450-ipa";
> +
> + iommus = <&apps_smmu 0x5c0 0x0>,
> + <&apps_smmu 0x5c2 0x0>;
> + reg = <0 0x3f40000 0 0x10000>,
'reg' is always the second property, followed by reg-names.
> + <0 0x3f50000 0 0x5000>,
> + <0 0x3e04000 0 0xfc000>;
> + reg-names = "ipa-reg",
> + "ipa-shared",
> + "gsi";
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: net: qcom,ipa: Add SM8450 compatible string
From: Krzysztof Kozlowski @ 2026-06-23 8:54 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alex Elder, linux-arm-msm,
devicetree, linux-kernel, netdev
In-Reply-To: <20260622-sm8450-ipa-v1-2-532f0299f96e@proton.me>
On Mon, Jun 22, 2026 at 09:44:18PM -0400, Esteban Urrutia wrote:
> Declare compatible string in ipa binding for SM8450,
> which uses IPA v5.1.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
With this fixed:
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: sound: add qcom,wsa885x-i2c
From: Prasad Kumpatla @ 2026-06-23 8:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Bartosz Golaszewski, Srinivas Kandagatla, linux-arm-msm,
linux-sound, devicetree, linux-kernel, linux-gpio
In-Reply-To: <CAD++jLkFPb4CZqTsAh_qX1Jt9pWxhwhgbhREe9uybL_S7-t60Q@mail.gmail.com>
On 6/11/2026 2:50 AM, Linus Walleij wrote:
> Hi Prasad,
>
> thanks for your patch!
Hi Linus Walleij,
Thanks for reviewing the patch and for the feedback.
>
> On Wed, Jun 10, 2026 at 5:57 PM Prasad Kumpatla
> <prasad.kumpatla@oss.qualcomm.com> wrote:
>
>> Document the Qualcomm WSA885X I2C smart amplifier binding.
> Skip I2C? We don't need to tell e.g. "PCI" in some device on PCI and
> there is no reason to mention I2C for this device, the fact that it sits
> on an I2C bus will be apparent later.
Ack, Will rename the file name.
>
>> Describe the required supplies, powerdown and interrupt GPIOs, the
>> optional battery configuration, and the optional init-table property
>> used to program the device during codec initialization.
>>
>> This matches the driver programming model and documents the DT data
>> needed to use the codec on platforms with Audio IF playback.
>>
>> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
> Perhaps add
> Link: https://www.qualcomm.com/audio/applications/compute-and-mobile-audio/products/wsa8815
>
> (...)
Checking internal to get product Doc to publish.
>> ---
>> .../bindings/sound/qcom,wsa885x-i2c.yaml | 89 +++++++++++++++++++
>> 1 file changed, 89 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
> Drop the -i2c suffix on the files.
Ack, Will update.
>
>> new file mode 100644
>> index 000000000..1069f470d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/qcom,wsa885x-i2c.yaml
>> @@ -0,0 +1,89 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/sound/qcom,wsa885x-i2c.yaml#
> Drop the -i2c suffix.
Ack, Will update.
>
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm WSA885x I2C smart speaker amplifier
> Drop I2C.
Ack, Will update.
>
>> +maintainers:
>> + - Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>> + - Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
>> +
>> +description: |
>> + WSA885x is a Qualcomm Aqstic smart speaker amplifier with an I2C control
>> + interface and a digital audio interface exposed through ASoC DAI callbacks.
>> +
>> +allOf:
>> + - $ref: dai-common.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: qcom,wsa885x-i2c
> Drop -i2c
Ack, Will update.
>
>> + reg:
>> + maxItems: 1
>> +
>> + '#sound-dai-cells':
>> + const: 0
>> +
>> + powerdown-gpios:
>> + description: GPIO controlling the SD_N powerdown pin.
>> + maxItems: 1
>> +
>> + interrupt-gpios:
>> + description: GPIO used for the codec interrupt output.
>> + maxItems: 1
>> +
>> + vdd-1p8-supply: true
>> +
>> + vdd-io-supply: true
>> +
>> + qcom,battery-config:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description: Speaker battery configuration, 1 for 1S and 2 for 2S.
> What is a "1S" and a "2S"? Include description here.
Ack, Will Update more details for 1s and 2s in next version.
>
>> + default: 1
>> + enum: [1, 2]
>> +
>> + qcom,wsa885x-init-table:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + minItems: 2
>> + maxItems: 256
>> + description: |
>> + Sequence of register/value pairs applied during codec hardware
>> + initialization. Entries are encoded as alternating register address and
>> + register value cells. The number of entries must be even (register/value
>> + pairs); maxItems is 256 (128 pairs).
> Can this just be a table inside the driver, if it will be the same
> array for every user? If this is board-unique then it needs to describe
> what each value is actually doing well enough so engineers can use this
> documentation right here to configure their board without looking through
> register maps and what not.
>
> Something more abstract using SI units etc is probably needed here.
These values are part of a fixed hardware initialization sequence and
are not board-specific.
I'll move them into the driver as a register table, making them easier
to maintain and
avoiding opaque DT data.
Thanks,
Prasad
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: watchdog: microchip,pic32mzda-wdt: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-23 8:51 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260620172354.155565-1-challauday369@gmail.com>
On Sat, Jun 20, 2026 at 10:53:54PM +0530, Udaya Kiran Challa wrote:
> + watchdog@1f800800 {
> + compatible = "microchip,pic32mzda-wdt";
> + reg = <0x1f800800 0x200>;
> + clocks = <&rootclk REF2CLK>;
> + };
Indentaion needs fixing.
With that:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Javier Martinez Canillas @ 2026-06-23 8:50 UTC (permalink / raw)
To: Andy Shevchenko, Amit Barzilai
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam, chintanlike,
dri-devel, devicetree, linux-kernel, linux-fbdev, linux-staging
In-Reply-To: <ajpGy7K4eM8oJIfD@ashevche-desk.local>
Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
>> The SSD1351 support was added to the ssd130x DRM driver. To avoid
>> confusion and irrelevant updates, the staging fb_ssd1351 driver is
>> removed.
>
> NAK, the fbtft has two drivers in one (SPI + parallel), plus as Maxime said,
> it has its own binding.
>
Yes, I agree that we don't want to delete the fbtft driver.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Sudeep Holla @ 2026-06-23 8:47 UTC (permalink / raw)
To: Pragnesh Papaniya
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sibi Sankar, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Dmitry Osipenko, Thierry Reding, Jonathan Hunter, Bjorn Andersson,
Konrad Dybcio, Rajendra Nayak, Pankaj Patil, linux-arm-msm,
linux-kernel, arm-scmi, linux-arm-kernel, devicetree, linux-pm,
linux-tegra, Amir Vajid, Ramakrishna Gottimukkula
In-Reply-To: <8725caf9-cebb-49ce-b2c8-4960a6073322@oss.qualcomm.com>
On Fri, Jun 19, 2026 at 06:01:23PM +0530, Pragnesh Papaniya wrote:
>
> On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
>
> > Not sure if it was discussed in the previous versions or not, it would be
> > good if you can capture why some of bus scaling doesn't work with the existing
> > SCMI performance protocol and the monitors don't fit the MPAM mode.
> >
> > Please capture them in 1/9 as a motivation for this vendor protocol. It will
> > then help to understand it better as I am still struggling to. Sorry for that.
>
> Thanks for the input!
>
> SCMI perf protocol exports perf domains to kernel where kernel can set
> the frequency but here the scaling governor runs on the SCP while kernel
> just observes frequency changes made by remote governor.
OK if it is sort of read-only w.r.t kernel, why not perf domain notifications
work to consume the change done by the SCMI platform.
And why do you have set operations in the vendor protocol being proposed then.
It all looks like something just cooked up to make things work. I need
detailed reasoning as why the existing perf protocol can't work considering
all the existing notifications in place.
> While MPAM is not enabled/supported on all hardware (Hamoa).
Fair enough but I still don't fully understand to rule that out yet.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 02/11] dt-bindings: Add the actual power domains on U8500
From: Krzysztof Kozlowski @ 2026-06-23 8:46 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Vinod Koul, Frank Li, Lee Jones,
linux-arm-kernel, devicetree, linux-pm, dri-devel, dmaengine
In-Reply-To: <20260618-ux500-power-domains-v7-1-v1-2-eb5e50b1a588@kernel.org>
On Thu, Jun 18, 2026 at 07:00:48AM +0200, Linus Walleij wrote:
> This file has been left in an unfinished state just defining
> the root power domain for the U8500 SoC. Fix it up by adding
> the actual existing power domains in this SoC.
>
> The PRCMU code and old regulator driver is mentioning some
> *_RET domains, this means "retention" and is a state in the
> domain and not a domain of its own.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
From/SoB mismatch.
> ---
> include/dt-bindings/arm/ux500_pm_domains.h | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/arm/ux500_pm_domains.h b/include/dt-bindings/arm/ux500_pm_domains.h
> index 9bd764f0c9e6..1c168e59ac90 100644
> --- a/include/dt-bindings/arm/ux500_pm_domains.h
> +++ b/include/dt-bindings/arm/ux500_pm_domains.h
> @@ -8,8 +8,23 @@
> #define _DT_BINDINGS_ARM_UX500_PM_DOMAINS_H
>
> #define DOMAIN_VAPE 0
> +#define DOMAIN_VARM 1
> +#define DOMAIN_VMODEM 2
> +#define DOMAIN_VPLL 3
> +#define DOMAIN_VSMPS1 4
> +#define DOMAIN_VSMPS2 5
> +#define DOMAIN_VSMPS3 6
> +#define DOMAIN_VRF1 7
> +#define DOMAIN_SVA_MMDSP 8
> +#define DOMAIN_SVA_PIPE 9
> +#define DOMAIN_SIA_MMDSP 10
> +#define DOMAIN_SIA_PIPE 11
> +#define DOMAIN_SGA 12
> +#define DOMAIN_B2R2_MCDE 13
> +#define DOMAIN_ESRAM_12 14
> +#define DOMAIN_ESRAM_34 15
>
> /* Number of PM domains. */
> -#define NR_DOMAINS (DOMAIN_VAPE + 1)
> +#define NR_DOMAINS (DOMAIN_ESRAM_34 + 1)
In a separate commit, instead you need to drop NR_DOMAINS and move them
to driver. If this changes, then it is not ABI. We did similarly for
many clock bindings/drivers.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Krzysztof Kozlowski @ 2026-06-23 8:43 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-2-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:03PM +0300, Amit Barzilai wrote:
> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
> RGB OLED display controller driven over a 4-wire SPI bus. The binding
> builds on the shared solomon,ssd-common.yaml properties already used by
> the other Solomon display controllers.
>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> ---
> .../bindings/display/solomon,ssd1351.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Andy Shevchenko @ 2026-06-23 8:41 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-5-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
> The SSD1351 support was added to the ssd130x DRM driver. To avoid
> confusion and irrelevant updates, the staging fb_ssd1351 driver is
> removed.
NAK, the fbtft has two drivers in one (SPI + parallel), plus as Maxime said,
it has its own binding.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V2 3/8] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
From: Bartosz Golaszewski @ 2026-06-23 8:34 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun, robh, krzk+dt, conor+dt,
Frank.Li, s.hauer, kernel, festevam, amitkumar.karwar,
neeraj.sanjaykale, marcel, luiz.dentz, hongxing.zhu, l.stach,
lpieralisi, kwilczynski, mani, bhelgaas, brgl
In-Reply-To: <20260623030736.1421537-4-sherry.sun@oss.nxp.com>
On Tue, 23 Jun 2026 05:07:30 +0200, "Sherry Sun (OSS)"
<sherry.sun@oss.nxp.com> said:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Power supply to the M.2 Bluetooth device attached to the host using M.2
> connector is controlled using the 'uart' pwrseq device. So add support for
> getting the pwrseq device if the OF graph link is present. Once obtained,
> pwrseq_power_on() is called to power up the M.2 Bluetooth card. The power
> sequencer descriptor is obtained via devm_pwrseq_get(), so the power-off
> and cleanup are handled automatically when the device is unbound.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: sashiko-bot @ 2026-06-23 8:31 UTC (permalink / raw)
To: Roman Vivchar via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260623-mt6323-adc-v4-2-299680ad3194@protonmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] NULL pointer dereference when accessing `dev->parent->parent` if the device is instantiated directly via Device Tree.
- [High] The driver powers down the AUXADC clock during initialization by setting an active-high power-down bit.
- [High] Logic error: Polling a channel data register (`ADC19`) for a busy state using an inverted mask (`GENMASK(15, 1)`).
- [High] The driver disables the 1.8V Reference Voltage by setting an active-low Enable Bar (`_ENB`) bit.
- [Medium] Hardware resource leak: voltage buffer left permanently enabled if register operations fail during channel request or release.
--
commit 14abb8cfa2d6b144f1f3f039d3bbc230861286d0
Author: Roman Vivchar <rva333@protonmail.com>
Date: Tue Jun 23 08:16:14 2026 +0000
iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
provides support for reading various channels including battery and
charger voltages, battery and chip temperature, current sensing and
accessory detection.
Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
> new file mode 100644
> index 0000000000000..c450fb6f09cb5
> --- /dev/null
> +++ b/drivers/iio/adc/mt6323-auxadc.c
[ ... ]
> +static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
> +{
> + struct regmap *map = auxadc->regmap;
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
> + if (ret)
> + return ret;
> +
> + /* The ADC is idle. */
> + if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
> + return 0;
> +
> + ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19,
> + val, !(val & AUXADC_ADC19_BUSY_MASK),
> + 10, 500);
[Severity: High]
The polling here checks the data payload register MT6323_AUXADC_ADC19 instead
of a status register. Is this a typo? Waiting for both the READY bit and
payload bits to become zero on a data register might immediately succeed
with a garbage state or result in a timeout failure.
> + if (ret)
> + return ret;
> +
> + return regmap_clear_bits(map, MT6323_AUXADC_CON19,
> + AUXADC_CON19_DECI_GDLY_MASK);
> +}
> +
> +static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
> + unsigned long channel)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
> + if (ret)
> + return ret;
> +
> + return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
[Severity: Medium]
If this second register write fails, the function returns an error without
rolling back the AUXADC_CON11_VBUF_EN bit set just above. The caller
in mt6323_auxadc_read_raw() then bypasses mt6323_auxadc_release() on error.
Will this leave the voltage buffer permanently enabled, causing a silent
resource and power leak?
> +}
> +
> +static int mt6323_auxadc_release(struct mt6323_auxadc *auxadc,
> + unsigned long channel)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
> + if (ret)
> + return ret;
[Severity: Medium]
Similarly here, if clearing the CON22 register fails, the function exits
early and skips clearing the AUXADC_CON11_VBUF_EN bit. Should the voltage
buffer be cleared even if the channel bits fail to clear?
> +
> + return regmap_clear_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
> +}
[ ... ]
> +static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
> +{
> + struct regmap *map = auxadc->regmap;
> + int ret;
> +
> + ret = regmap_set_bits(map, MT6323_STRUP_CON10,
> + AUXADC_STRUP_CON10_RSTB_SW |
> + AUXADC_STRUP_CON10_RSTB_SEL);
> + if (ret)
> + return ret;
> +
> + ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
[Severity: High]
In MediaTek PMICs, CKPDN usually stands for Clock Power Down. Does setting
this active-high bit power down the AUXADC clock instead of enabling it?
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(map, MT6323_AUXADC_CON10,
> + AUXADC_TRIM_CH2_MASK | AUXADC_TRIM_CH4_MASK |
> + AUXADC_TRIM_CH5_MASK | AUXADC_TRIM_CH6_MASK,
> + FIELD_PREP(AUXADC_TRIM_CH2_MASK, 1) |
> + FIELD_PREP(AUXADC_TRIM_CH4_MASK, 1) |
> + FIELD_PREP(AUXADC_TRIM_CH5_MASK, 1) |
> + FIELD_PREP(AUXADC_TRIM_CH6_MASK, 1));
> + if (ret)
> + return ret;
> +
> + ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
> + AUXADC_CON27_VREF18_ENB_MD |
> + AUXADC_CON27_MD_STATUS);
[Severity: High]
The ENB suffix typically designates an active-low Enable Bar bit.
By using regmap_set_bits() to set AUXADC_CON27_VREF18_ENB_MD to 1, does this
explicitly power down the 1.8V reference voltage needed by the ADC?
> + if (ret)
> + return ret;
[ ... ]
> +static int mt6323_auxadc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mt6323_auxadc *auxadc;
> + struct regmap *regmap;
> + struct iio_dev *iio;
> + int ret;
> +
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
The driver exports an of_match_table, which means it could be instantiated
directly by the Device Tree core instead of as an MFD sub-device. In that
scenario, could dev->parent or dev->parent->parent be NULL?
If so, passing a NULL pointer to dev_get_regmap() will cause a kernel crash.
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
> +
> + iio = devm_iio_device_alloc(dev, sizeof(*auxadc));
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-mt6323-adc-v4-0-299680ad3194@protonmail.com?part=2
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-23 8:30 UTC (permalink / raw)
To: Joshua Crofts
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260622115554.000036a9@gmail.com>
On 6/22/2026 11:55 AM, Joshua Crofts wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Mon, 22 Jun 2026 00:47:28 -0700
> Petar Stepanovic <pstepanovic@axiado.com> wrote:
>
>> Add support for the SARADC controller found on Axiado AX3000 and
>> AX3005 SoCs.
>>
>> The driver supports single-shot voltage reads through the IIO
>> subsystem. The number of available input channels is selected from
>> the SoC match data, allowing AX3000 and AX3005 variants to use the
>> same driver.
>>
>> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
>> ---
>> + info->clk_rate = clk_get_rate(info->clk);
>> + if (!info->clk_rate)
>> + return dev_err_probe(dev, -EINVAL, "invalid clock rate\n");
>> +
>> + ret = devm_regulator_get_enable_read_voltage(dev, "vref");
>> + if (ret < 0)
>> + return dev_err_probe(dev, info->vref_uV,
>> + "failed to get vref voltage\n");
> Sashiko raised an issue that I've missed on previous reads - why
> are you using info->vref_uV in dev_err_probe()? The info struct
> is not zeroed out on initialization, which means that dev_err_probe
> will return a different value each time when read_voltage() fails.
> It was designed to accept the retval from whatever function we're
> checking.
Thank you for catching this.
You are right, |dev_err_probe()| should use the return value from |devm_regulator_get_enable_read_voltage()|, not |info->vref_uV|.
I will fix this in the next version by passing |ret| to |dev_err_probe()| and assigning |info->vref_uV| only after the call succeeds.
Regards,
Petar
^ permalink raw reply
* Re: [PATCH v4 2/4] PCI: rzg3s-host: Use shared reset controls for power domain resets
From: Lad, Prabhakar @ 2026-06-23 8:29 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Philipp Zabel, Claudiu Beznea, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-pci, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <txpkke2xogecipyetascqajgaxamd3ualcuhsibxf75llzcym5@xgcn7efcbmp4>
Hi Manivanna,
On Tue, Jun 23, 2026 at 7:04 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Mon, Jun 22, 2026 at 03:53:57PM +0100, Lad, Prabhakar wrote:
> > Hi Manivannan,
> >
> > On Mon, Jun 22, 2026 at 3:30 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Fri, Jun 05, 2026 at 12:54:46PM +0100, Lad, Prabhakar wrote:
> > > > Hi Philipp,
> > > >
> > > > Thank you for the review.
> > > >
> > > > On Wed, Jun 3, 2026 at 9:16 AM Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > > > >
> > > > > On Di, 2026-06-02 at 20:50 +0100, Prabhakar wrote:
> > > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > > > >
> > > > > > Switch to shared reset controls for PCIe power resets to prepare for
> > > > > > RZ/V2H(P) support. On this platform, multiple PCIe controllers share
> > > > > > the same reset line, requiring shared ownership of the reset control.
> > > > > >
> > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > > > > Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > > > Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > > > > > ---
> > > > > > v3->v4:
> > > > > > - Added RB/TB tags.
> > > > > >
> > > > > > v2->v3:
> > > > > > - No change.
> > > > > >
> > > > > > v1->v2:
> > > > > > - Updated commit message.
> > > > > > ---
> > > > > > drivers/pci/controller/pcie-rzg3s-host.c | 6 +++---
> > > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/controller/pcie-rzg3s-host.c b/drivers/pci/controller/pcie-rzg3s-host.c
> > > > > > index d86e7516dcc2..a5192e4b58df 100644
> > > > > > --- a/drivers/pci/controller/pcie-rzg3s-host.c
> > > > > > +++ b/drivers/pci/controller/pcie-rzg3s-host.c
> > > > > > @@ -1276,9 +1276,9 @@ static int rzg3s_pcie_resets_prepare_and_get(struct rzg3s_pcie_host *host)
> > > > > > for (i = 0; i < data->num_cfg_resets; i++)
> > > > > > host->cfg_resets[i].id = data->cfg_resets[i];
> > > > > >
> > > > > > - ret = devm_reset_control_bulk_get_exclusive(host->dev,
> > > > > > - data->num_power_resets,
> > > > > > - host->power_resets);
> > > > > > + ret = devm_reset_control_bulk_get_shared(host->dev,
> > > > > > + data->num_power_resets,
> > > > > > + host->power_resets);
> > > > > > if (ret)
> > > > > > return ret;
> > > > > >
> > > > >
> > > > > I have a few questions about this.
> > > > >
> > > > > Can you move rzg3s_pcie_resets_prepare_and_get() and
> > > > > rzg3s_pcie_power_resets_deassert() up before setting
> > > > > RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B in
> > > > > rzg3s_pcie_probe() without ill effect?
> > > > >
> > > > > Can you move rzg3s_pcie_power_resets_deassert() up before setting
> > > > > RZG3S_SYSC_FUNC_ID_MODE and RZG3S_SYSC_FUNC_ID_RST_RSM_B
> > > > > rzg3s_pcie_resume_noirq()?
> > > > >
> > > > > Those would have the same effect as the reset already being deasserted
> > > > > by the other controller.
> > > > >
> > > > Yes to both. I have reordered the sequences as suggested, and it works
> > > > perfectly without any ill effects.
> > > >
> > >
> > > Are you going to respin the patches incorporating the review comments?
> > >
> > If I have not mistaken, no code changes were requested; it was just
> > that Philipp wanted to ensure the shared reset worked correctly after
> > shuffling the code around.
> >
>
> Ah, I was mistaken.
>
> > I can respin the series if it fails to apply on top of pci/next.
> >
>
> Sure. Please respin once v7.2-rc1 is released.
>
Sure, will do.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH 2/2] pwm: add Axiado AX3000 PWM driver
From: Petar Stepanovic @ 2026-06-23 8:25 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Akhila Kavi, Prasad Bolisetty, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-pwm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <ajlf4t_tuuX-Eplc@monoceros>
On 6/22/2026 6:29 PM, Uwe Kleine-König wrote:
> Hello Petar,
>
> Just a very high-level review:
Thank you for the review.
I will address all your comments in the next version.
Regards,
Petar
^ permalink raw reply
* RE: [PATCH] dt-bindings: clock: Replace bouncing emails
From: Alim Akhtar @ 2026-06-23 6:00 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Bjorn Andersson',
'Michael Turquette', 'Stephen Boyd',
'Brian Masney', 'Rob Herring',
'Krzysztof Kozlowski', 'Conor Dooley',
'Sylwester Nawrocki', 'Chanwoo Choi',
'Peter Griffin', 'Barnabas Czeman',
'Tomasz Figa', linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-samsung-soc, linux-arm-kernel, cpgs
In-Reply-To: <20260623055626.23814-2-krzysztof.kozlowski@oss.qualcomm.com>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Sent: Tuesday, June 23, 2026 11:26 AM
> To: Bjorn Andersson <andersson@kernel.org>; Michael Turquette
> <mturquette@baylibre.com>; Stephen Boyd <sboyd@kernel.org>; Brian
> Masney <bmasney@redhat.com>; Rob Herring <robh@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Sylwester Nawrocki <s.nawrocki@samsung.com>;
> Chanwoo Choi <cw00.choi@samsung.com>; Peter Griffin
> <peter.griffin@linaro.org>; Alim Akhtar <alim.akhtar@samsung.com>;
> Barnabas Czeman <barnabas.czeman@mainlining.org>; Tomasz Figa
> <tomasz.figa@gmail.com>; linux-arm-msm@vger.kernel.org; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Subject: [PATCH] dt-bindings: clock: Replace bouncing emails
>
> Replace permanently bouncing email addresses (550 5.1.1 Recipient address
> rejected) of Adam Skladowski, Sireesh Kodali and Chanho Park. There are
no
> new messages from them via other email addresses, so drop them
> permanently. Add Alim Akhtar to Samsung ExynosAutov9 SoC clocks,
> because he looks at other Samsung clock hardware and drivers.
>
> Signed-off-by: Krzysztof Kozlowski
> <krzysztof.kozlowski@oss.qualcomm.com>
>
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: mediatek: mt6323: add AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 AUXADC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..c070f4b0936c 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,11 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ mt6323_adc: adc {
+ compatible = "mediatek,mt6323-auxadc";
+ #io-channel-cells = <1>;
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
drivers/mfd/mt6397-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e..013b0857fb54 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-auxadc",
+ .of_compatible = "mediatek,mt6323-auxadc",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Conor Dooley
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@protonmail.com>
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.
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.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
MAINTAINERS | 6 ++++++
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 5d4ab701f51a..852eb7336a5a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek MT6350 series PMIC AUXADC
+title: MediaTek MT6350 series and similar PMIC AUXADC
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
@@ -19,6 +19,7 @@ description:
properties:
compatible:
enum:
+ - mediatek,mt6323-auxadc
- mediatek,mt6357-auxadc
- mediatek,mt6358-auxadc
- mediatek,mt6359-auxadc
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..2551c8cd9e9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,12 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC AUXADC DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
new file mode 100644
index 000000000000..6ee9a9ecffc1
--- /dev/null
+++ b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+#define _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+
+#define MT6323_AUXADC_BATON2 0
+#define MT6323_AUXADC_CH6 1
+#define MT6323_AUXADC_BAT_TEMP 2
+#define MT6323_AUXADC_CHIP_TEMP 3
+#define MT6323_AUXADC_VCDT 4
+#define MT6323_AUXADC_BATON1 5
+#define MT6323_AUXADC_ISENSE 6
+#define MT6323_AUXADC_BATSNS 7
+#define MT6323_AUXADC_ACCDET 8
+#define MT6323_AUXADC_AUDIO0 9
+#define MT6323_AUXADC_AUDIO1 10
+#define MT6323_AUXADC_AUDIO2 11
+#define MT6323_AUXADC_AUDIO3 12
+#define MT6323_AUXADC_AUDIO4 13
+#define MT6323_AUXADC_AUDIO5 14
+#define MT6323_AUXADC_AUDIO6 15
+#define MT6323_AUXADC_AUDIO7 16
+
+#endif
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Andy Shevchenko
In-Reply-To: <20260623-mt6323-adc-v4-0-299680ad3194@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
provides support for reading various channels including battery and
charger voltages, battery and chip temperature, current sensing and
accessory detection.
Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
MAINTAINERS | 1 +
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 327 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2551c8cd9e9d..fb40128451dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16260,6 +16260,7 @@ MEDIATEK MT6323 PMIC AUXADC DRIVER
M: Roman Vivchar <rva333@protonmail.com>
L: linux-iio@vger.kernel.org
S: Maintained
+F: drivers/iio/adc/mt6323-auxadc.c
F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
MEDIATEK MT6735 CLOCK & RESET DRIVERS
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 60038ae8dfc4..a03614b46041 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1137,6 +1137,17 @@ config MCP3911
This driver can also be built as a module. If so, the module will be
called mcp3911.
+config MEDIATEK_MT6323_AUXADC
+ tristate "MediaTek MT6323 PMIC AUXADC driver"
+ depends on MFD_MT6397
+ help
+ Say yes here to enable support for MediaTek MT6323 PMIC Auxiliary ADC.
+ This driver provides multiple channels for system monitoring,
+ such as battery voltage, PMIC temperature, and others.
+
+ This driver can also be built as a module. If so, the module will be
+ called mt6323-auxadc.
+
config MEDIATEK_MT6359_AUXADC
tristate "MediaTek MT6359 PMIC AUXADC driver"
depends on MFD_MT6397
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index c76550415ff1..58161750d6e3 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MCP3564) += mcp3564.o
obj-$(CONFIG_MCP3911) += mcp3911.o
+obj-$(CONFIG_MEDIATEK_MT6323_AUXADC) += mt6323-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6359_AUXADC) += mt6359-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
new file mode 100644
index 000000000000..c450fb6f09cb
--- /dev/null
+++ b/drivers/iio/adc/mt6323-auxadc.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ *
+ * Based on drivers/iio/adc/mt6359-auxadc.c
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stringify.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
+
+#define AUXADC_STRUP_CON10_RSTB_SEL BIT(7)
+#define AUXADC_STRUP_CON10_RSTB_SW BIT(5)
+
+#define AUXADC_TOP_CKPDN2_CTL_CK BIT(5)
+
+#define AUXADC_TRIM_CH2_MASK GENMASK(11, 10)
+#define AUXADC_TRIM_CH4_MASK GENMASK(9, 8)
+#define AUXADC_TRIM_CH5_MASK GENMASK(5, 4)
+#define AUXADC_TRIM_CH6_MASK GENMASK(3, 2)
+
+#define AUXADC_CON27_VREF18_ENB_MD BIT(15)
+#define AUXADC_CON27_MD_STATUS BIT(0)
+
+#define AUXADC_CON19_GPS_STATUS BIT(1)
+
+#define AUXADC_CON26_VREF18_SELB BIT(1)
+#define AUXADC_CON26_DECI_GDLY_SEL BIT(0)
+
+#define AUXADC_CON11_VBUF_EN BIT(4)
+
+#define AUXADC_CON19_DECI_GDLY_MASK GENMASK(15, 14)
+#define AUXADC_ADC19_BUSY_MASK GENMASK(15, 1)
+#define AUXADC_READY_MASK BIT(15)
+#define AUXADC_DATA_MASK GENMASK(14, 0)
+
+#define AUXADC_CON9_OSR_MASK GENMASK(12, 10)
+#define AUXADC_DEFAULT_OSR 3
+
+#define MTK_PMIC_IIO_CHAN(_name, _chan, _addr) \
+{ \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _chan, \
+ .address = _addr, \
+ .datasheet_name = __stringify(_name), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+/*
+ * AUXADC reports everything in mV, including temperature and
+ * current channels. Channel macros are mapped such that their
+ * ID matches their respective hardware bit position in CON22.
+ */
+static const struct iio_chan_spec mt6323_auxadc_channels[] = {
+ MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6),
+ MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11),
+ MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5),
+ MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, MT6323_AUXADC_ADC4),
+ MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, MT6323_AUXADC_ADC2),
+ MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, MT6323_AUXADC_ADC3),
+ MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, MT6323_AUXADC_ADC1),
+ MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, MT6323_AUXADC_ADC0),
+ MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, MT6323_AUXADC_ADC7),
+};
+
+/*
+ * The MediaTek MT6323 (as well as a lot of other PMICs) has the following hierarchy:
+ * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
+ *
+ * Therefore, PWRAP regmap should be obtained using dev->parent->parent.
+ */
+struct mt6323_auxadc {
+ struct regmap *regmap;
+ /* AUXADC doesn't support reading multiple channels simultaneously. */
+ struct mutex lock;
+};
+
+static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
+ if (ret)
+ return ret;
+
+ /* The ADC is idle. */
+ if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
+ return 0;
+
+ ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19,
+ val, !(val & AUXADC_ADC19_BUSY_MASK),
+ 10, 500);
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON19,
+ AUXADC_CON19_DECI_GDLY_MASK);
+}
+
+static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+ if (ret)
+ return ret;
+
+ return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+}
+
+static int mt6323_auxadc_release(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+}
+
+static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
+ const struct iio_chan_spec *chan, int *out)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read_poll_timeout(map, chan->address,
+ val, (val & AUXADC_READY_MASK),
+ 1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
+ if (ret)
+ return ret;
+
+ *out = FIELD_GET(AUXADC_DATA_MASK, val);
+
+ return 0;
+}
+
+static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
+ int ret, mult;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->channel == MT6323_AUXADC_ISENSE ||
+ chan->channel == MT6323_AUXADC_BATSNS)
+ mult = 4;
+ else
+ mult = 1;
+
+ /* 1800mV full range with 15-bit resolution. */
+ *val = mult * 1800;
+ *val2 = 15;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+ case IIO_CHAN_INFO_RAW: {
+ guard(mutex)(&auxadc->lock);
+
+ ret = mt6323_auxadc_prepare_channel(auxadc);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_request(auxadc, chan->channel);
+ if (ret)
+ return ret;
+
+ /* Hardware limitation: the AUXADC needs a delay to become ready. */
+ fsleep(300);
+
+ ret = mt6323_auxadc_read(auxadc, chan, val);
+
+ if (mt6323_auxadc_release(auxadc, chan->channel))
+ dev_err(&indio_dev->dev,
+ "failed to release channel %d\n", chan->channel);
+
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_STRUP_CON10,
+ AUXADC_STRUP_CON10_RSTB_SW |
+ AUXADC_STRUP_CON10_RSTB_SEL);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(map, MT6323_AUXADC_CON10,
+ AUXADC_TRIM_CH2_MASK | AUXADC_TRIM_CH4_MASK |
+ AUXADC_TRIM_CH5_MASK | AUXADC_TRIM_CH6_MASK,
+ FIELD_PREP(AUXADC_TRIM_CH2_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH4_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH5_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH6_MASK, 1));
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
+ AUXADC_CON27_VREF18_ENB_MD |
+ AUXADC_CON27_MD_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON19, AUXADC_CON19_GPS_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON26,
+ AUXADC_CON26_VREF18_SELB |
+ AUXADC_CON26_DECI_GDLY_SEL);
+ if (ret)
+ return ret;
+
+ return regmap_update_bits(map, MT6323_AUXADC_CON9, AUXADC_CON9_OSR_MASK,
+ FIELD_PREP(AUXADC_CON9_OSR_MASK, AUXADC_DEFAULT_OSR));
+}
+
+static const struct iio_info mt6323_auxadc_iio_info = {
+ .read_raw = mt6323_auxadc_read_raw,
+};
+
+static int mt6323_auxadc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mt6323_auxadc *auxadc;
+ struct regmap *regmap;
+ struct iio_dev *iio;
+ int ret;
+
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ iio = devm_iio_device_alloc(dev, sizeof(*auxadc));
+ if (!iio)
+ return -ENOMEM;
+
+ auxadc = iio_priv(iio);
+ auxadc->regmap = regmap;
+
+ ret = devm_mutex_init(dev, &auxadc->lock);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_init(auxadc);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to initialize auxadc\n");
+
+ iio->name = "mt6323-auxadc";
+ iio->info = &mt6323_auxadc_iio_info;
+ iio->modes = INDIO_DIRECT_MODE;
+ iio->channels = mt6323_auxadc_channels;
+ iio->num_channels = ARRAY_SIZE(mt6323_auxadc_channels);
+
+ return devm_iio_device_register(dev, iio);
+}
+
+static const struct of_device_id mt6323_auxadc_of_match[] = {
+ { .compatible = "mediatek,mt6323-auxadc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_auxadc_of_match);
+
+static struct platform_driver mt6323_auxadc_driver = {
+ .driver = {
+ .name = "mt6323-auxadc",
+ .of_match_table = mt6323_auxadc_of_match,
+ },
+ .probe = mt6323_auxadc_probe,
+};
+module_platform_driver(mt6323_auxadc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC AUXADC Driver");
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/4] AUXADC driver for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-23 8:16 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Conor Dooley,
Andy Shevchenko
This series adds support for the 15-bit AUXADC hardware block found on
the MediaTek mt6323 PMIC.
The previous version of the series for all AUXADC, EFUSE and thermal
drivers was split after Krzysztof's comment [1].
Tested on the MediaTek mt6572 and mt8163 SoCs (Ben), both paired with a
mt6323.
[1]: https://lore.kernel.org/linux-mediatek/20260504-mt6323-v1-0-799b58b355ff@protonmail.com/T/#med30fad67a090be35f549231336b2dec295233f6
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes in v4:
- dt-bindings: Drop separate driver mention from the commit message (Conor)
- AUXADC driver: Break one more time 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Link to v3: https://patch.msgid.link/20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com
Changes in v3:
- AUXADC driver:
- Add comment for channels table about voltage and channel IDs (Jonathan)
- Add comment for mutex in the 'mt6323_auxadc' struct (Jonathan)
- Break 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Switch to 'guard' from 'scoped_guard' (Andy)
- Link to v2: https://patch.msgid.link/20260609-mt6323-adc-v2-0-aa93a22309f9@protonmail.com
Changes in v2:
- AUXADC driver:
- Drop channel type from the MTK_PMIC_IIO_CHAN macro (Nuno)
- Drop kerneldoc for the mt6323_auxadc struct (Nuno)
- Add channel release to save power (Sashiko, Jonathan)
- Drop 'reg' variable in the mt6323_auxadc_read (Jonathan)
- Sort variables in the mt6323_auxadc_probe (Jonathan)
- Maintainers:
- Drop linux-mediatek list (Andy)
- Split between dt-bindings and driver to avoid missing file (Nuno)
- Link to v1: https://patch.msgid.link/20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com
Changes after split:
- dt-bindings: Change 'MT63xx' to 'MT6350 series and similar' (Jonathan)
- AUXADC driver:
- Add missing headers (Andy)
- Fix AUXADC_TRIM_CH* values (Andy)
- Rename masks to include their register name (Jonathan)
- Fix formatting (Andy, Jonathan)
- Replace channel address with actual register value (Jonathan), align the table
- Replace IIO_TEMP with IIO_VOLTAGE, since the actual output is still mV, not mC
- Rename constants to match their registers (Jonathan)
- Remove 'if/else if/else' in the mt6323_auxadc_read_raw (Andy)
- Add comments for fsleep, ADC range and resolution (Andy, Jonathan)
- Remove useless error messages (Andy)
- Maintainers:
- Explicitly include mt6323 in the name (Jonathan)
- Squash with AUXADC driver commit (Krzysztof)
- Set status back to 'Maintained'
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
mfd: mt6397-core: add mt6323 AUXADC support
ARM: dts: mediatek: mt6323: add AUXADC support
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 +-
MAINTAINERS | 7 +
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +
drivers/iio/adc/Kconfig | 11 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 +++++++++++++++++++++
drivers/mfd/mt6397-core.c | 3 +
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++
8 files changed, 367 insertions(+), 1 deletion(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260525-mt6323-adc-3befce36cbf2
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox