* Re: [PATCH v1 5/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Sakari Ailus @ 2026-04-17 12:13 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-6-clamor95@gmail.com>
Hi Svyatoslav,
Thanks for the set.
This patch should be the first one in the set, or at least before those
using the bindings defined here.
On Fri, Apr 17, 2026 at 02:42:26PM +0300, Svyatoslav Ryhel wrote:
> Document TI LM3560 Synchronous Boost Flash Driver used for camera flash
> LEDs.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/leds/ti,lm3560.yaml | 134 ++++++++++++++++++
> 1 file changed, 134 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3560.yaml b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> new file mode 100644
> index 000000000000..460ea1fbc1e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> @@ -0,0 +1,134 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/ti,lm3560.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI LM3560 Synchronous Boost Flash Driver
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + The LM3560 is a 2-MHz fixed frequency synchronous boost converter with two
> + 1000-mA constant current drivers for high-current white LEDs. The dual high-
> + side current sources allow for grounded cathode LED operation and can be
> + tied together for providing flash currents at up to 2 A through a single LED.
> + An adaptive regulation method ensures the current for each LED remains in
> + regulation and maximizes efficiency.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,lm3559
> + - ti,lm3560
> +
> + reg:
> + maxItems: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + enable-gpios:
> + description: GPIO connected to the HWEN pin.
> + maxItems: 1
> +
> + vin-supply:
> + description: Supply connected to the IN line.
> +
> + ti,peak-current-microamp:
> + description:
> + The LM3560 features 4 selectable current limits 1.6A, 2.3A, 3A, and 3.6A.
> + When the current limit is reached, the LM3560 stops switching for the
> + remainder of the switching cycle.
> + enum: [16000000, 23000000, 30000000, 36000000]
> + default: 36000000
> +
> + ti,max-flash-timeout-ms:
> + description:
> + Maximum flash timeout in ms with step 32ms.
> + minimum: 32
> + maximum: 1024
> + default: 1024
> +
> +patternProperties:
> + '^led@[01]$':
> + description: LED control bank nodes.
> + $ref: /schemas/leds/common.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description: Control bank selection (0 = bank A, 1 = bank B).
> + maximum: 1
> +
> + ti,max-flash-current-microamp:
> + description:
> + Maximum flash current in uA with step 62500uA.
> + minimum: 62500
> + maximum: 1000000
> + default: 1000000
> +
> + ti,max-torch-current-microamp:
Don't the LED flash bindings already have standardised properties for
these?
> + description:
> + Maximum flash current in uA with step 31250uA.
> + minimum: 31250
> + maximum: 250000
> + default: 250000
> +
> + required:
> + - reg
I'd say the max current properties are required as well, same for the
timeouts. Or make the lowest the default. The lowest values are very seldom
used in practice though.
> +
> +required:
> + - compatible
> + - reg
> + - '#address-cells'
> + - '#size-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@53 {
> + compatible = "ti,lm3560";
> + reg = <0x53>;
> +
> + enable-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&vdd_3v3_sys>;
> +
> + ti,peak-current-microamp = <16000000>;
> + ti,max-flash-timeout-ms = <1024>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@0 {
> + reg = <0>;
> +
> + label = "white::flash";
> + linux,default-trigger = "flash";
> +
> + ti,max-flash-current-microamp = <562500>;
> + ti,max-torch-current-microamp = <156250>;
> + };
> +
> + led@1 {
> + reg = <1>;
> +
> + label = "yellow::flash";
> + linux,default-trigger = "flash";
> +
> + ti,max-flash-current-microamp = <562500>;
> + ti,max-torch-current-microamp = <156250>;
> + };
> + };
> + };
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v1 1/5] media: lm3560: Add HWEN pin support
From: Sakari Ailus @ 2026-04-17 12:15 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-2-clamor95@gmail.com>
Hi Svyatoslav,
On Fri, Apr 17, 2026 at 02:42:22PM +0300, Svyatoslav Ryhel wrote:
> Add HWEN - logic high hardware enable input found in LM3560 to ensure its
> proper operation.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/media/i2c/lm3560.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
> index f4cc844f4e3c..e6af61415821 100644
> --- a/drivers/media/i2c/lm3560.c
> +++ b/drivers/media/i2c/lm3560.c
> @@ -11,6 +11,7 @@
>
> #include <linux/delay.h>
> #include <linux/module.h>
> +#include <linux/gpio.h>
> #include <linux/i2c.h>
> #include <linux/slab.h>
> #include <linux/mutex.h>
> @@ -45,6 +46,7 @@ enum led_enable {
> * @dev: pointer to &struct device
> * @pdata: platform data
> * @regmap: reg. map for i2c
> + * @hwen_gpio: line connected to hwen pin
> * @lock: muxtex for serial access.
> * @led_mode: V4L2 LED mode
> * @ctrls_led: V4L2 controls
> @@ -54,6 +56,7 @@ struct lm3560_flash {
> struct device *dev;
> struct lm3560_platform_data *pdata;
> struct regmap *regmap;
> + struct gpio_desc *hwen_gpio;
> struct mutex lock;
>
> enum v4l2_flash_led_mode led_mode;
> @@ -425,6 +428,12 @@ static int lm3560_probe(struct i2c_client *client)
> flash->dev = &client->dev;
> mutex_init(&flash->lock);
>
> + flash->hwen_gpio = devm_gpiod_get_optional(&client->dev, "enable",
> + GPIOD_OUT_HIGH);
Please add runtime PM support for this so it can be powered on when needed.
> + if (IS_ERR(flash->hwen_gpio))
> + return dev_err_probe(&client->dev, PTR_ERR(flash->hwen_gpio),
> + "failed to get hwen gpio\n");
> +
> rval = lm3560_subdev_init(flash, LM3560_LED0, "lm3560-led0");
> if (rval < 0)
> return rval;
> @@ -452,6 +461,8 @@ static void lm3560_remove(struct i2c_client *client)
> v4l2_ctrl_handler_free(&flash->ctrls_led[i]);
> media_entity_cleanup(&flash->subdev_led[i].entity);
> }
> +
> + gpiod_set_value_cansleep(flash->hwen_gpio, 0);
> }
>
> static const struct i2c_device_id lm3560_id_table[] = {
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v1 2/5] media: lm3560: Add IN supply support
From: Sakari Ailus @ 2026-04-17 12:17 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-3-clamor95@gmail.com>
Hi Svyatoslav,
On Fri, Apr 17, 2026 at 02:42:23PM +0300, Svyatoslav Ryhel wrote:
> Add IN supply (2.5V - 5.5V) found in LM3560 to ensure its proper work.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/media/i2c/lm3560.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
> index e6af61415821..a2674af6c9fb 100644
> --- a/drivers/media/i2c/lm3560.c
> +++ b/drivers/media/i2c/lm3560.c
> @@ -16,6 +16,7 @@
> #include <linux/slab.h>
> #include <linux/mutex.h>
> #include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/videodev2.h>
> #include <media/i2c/lm3560.h>
> #include <media/v4l2-ctrls.h>
> @@ -434,6 +435,11 @@ static int lm3560_probe(struct i2c_client *client)
> return dev_err_probe(&client->dev, PTR_ERR(flash->hwen_gpio),
> "failed to get hwen gpio\n");
>
> + rval = devm_regulator_get_enable(&client->dev, "vin");
I'd also enable this via runtime PM.
Sensor drivers such as imx219 serve as a good example here.
> + if (rval)
> + return dev_err_probe(&client->dev, rval,
> + "failed to enable regulator\n");
> +
> rval = lm3560_subdev_init(flash, LM3560_LED0, "lm3560-led0");
> if (rval < 0)
> return rval;
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: use refgen regulator for DSI
From: Pengyu Luo @ 2026-04-17 12:23 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <awrfjdwsf4gyyg2s6ppw4jfmpzp5s2aavosmspsp26oqccco7y@csij6bpnfpu7>
On Sat, Feb 28, 2026 at 9:13 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Sat, Feb 28, 2026 at 08:54:30PM +0800, Pengyu Luo wrote:
> > Use it for the DSI controllers, since DSI nodes have been added.
> >
> > Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> > ---
> > This patch depends on the below series:
> > https://lore.kernel.org/linux-arm-msm/20260228101907.18043-1-mitltlatltl@gmail.com/
>
> Why was it not squashed into that series? I'd assume that DSI nodes are
> incomplete and are working "by luck" without the refgen supplies.
>
Today, I did a casual read. I found the register(0x8900000 + 0x80) to
enable refgen is always 0 on windows. The refgen driver may be not
compatible with sc8280xp or the DT configuration is wrong.
Best wishes,
Pengyu
^ permalink raw reply
* Re: [PATCH v1 5/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Svyatoslav Ryhel @ 2026-04-17 12:30 UTC (permalink / raw)
To: Sakari Ailus
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <aeIkBR4cx54OVmGo@kekkonen.localdomain>
пт, 17 квіт. 2026 р. о 15:13 Sakari Ailus <sakari.ailus@linux.intel.com> пише:
>
> Hi Svyatoslav,
>
> Thanks for the set.
>
> This patch should be the first one in the set, or at least before those
> using the bindings defined here.
>
Maybe before conversion, but definitely not the first. I would like to
avoid patch multiplication caused by schema adjustments after every
single commit if possible.
> On Fri, Apr 17, 2026 at 02:42:26PM +0300, Svyatoslav Ryhel wrote:
> > Document TI LM3560 Synchronous Boost Flash Driver used for camera flash
> > LEDs.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../devicetree/bindings/leds/ti,lm3560.yaml | 134 ++++++++++++++++++
> > 1 file changed, 134 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/leds/ti,lm3560.yaml b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> > new file mode 100644
> > index 000000000000..460ea1fbc1e5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> > @@ -0,0 +1,134 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/leds/ti,lm3560.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: TI LM3560 Synchronous Boost Flash Driver
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + The LM3560 is a 2-MHz fixed frequency synchronous boost converter with two
> > + 1000-mA constant current drivers for high-current white LEDs. The dual high-
> > + side current sources allow for grounded cathode LED operation and can be
> > + tied together for providing flash currents at up to 2 A through a single LED.
> > + An adaptive regulation method ensures the current for each LED remains in
> > + regulation and maximizes efficiency.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - ti,lm3559
> > + - ti,lm3560
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > + enable-gpios:
> > + description: GPIO connected to the HWEN pin.
> > + maxItems: 1
> > +
> > + vin-supply:
> > + description: Supply connected to the IN line.
> > +
> > + ti,peak-current-microamp:
> > + description:
> > + The LM3560 features 4 selectable current limits 1.6A, 2.3A, 3A, and 3.6A.
> > + When the current limit is reached, the LM3560 stops switching for the
> > + remainder of the switching cycle.
> > + enum: [16000000, 23000000, 30000000, 36000000]
> > + default: 36000000
> > +
> > + ti,max-flash-timeout-ms:
> > + description:
> > + Maximum flash timeout in ms with step 32ms.
> > + minimum: 32
> > + maximum: 1024
> > + default: 1024
> > +
> > +patternProperties:
> > + '^led@[01]$':
> > + description: LED control bank nodes.
> > + $ref: /schemas/leds/common.yaml#
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + reg:
> > + description: Control bank selection (0 = bank A, 1 = bank B).
> > + maximum: 1
> > +
> > + ti,max-flash-current-microamp:
> > + description:
> > + Maximum flash current in uA with step 62500uA.
> > + minimum: 62500
> > + maximum: 1000000
> > + default: 1000000
> > +
> > + ti,max-torch-current-microamp:
>
> Don't the LED flash bindings already have standardised properties for
> these?
>
Oh, they do! Thanks for pointing out. led-max-microamp,
flash-max-microamp and flash-max-timeout-us. Very nice, I will adjust
in the v2.
> > + description:
> > + Maximum flash current in uA with step 31250uA.
> > + minimum: 31250
> > + maximum: 250000
> > + default: 250000
> > +
> > + required:
> > + - reg
>
> I'd say the max current properties are required as well, same for the
> timeouts. Or make the lowest the default. The lowest values are very seldom
> used in practice though.
>
I have transferred from the driver which uses maximum values as
default one. I can change to minimum if needed, that is not a big
deal.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - '#address-cells'
> > + - '#size-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + led-controller@53 {
> > + compatible = "ti,lm3560";
> > + reg = <0x53>;
> > +
> > + enable-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
> > + vin-supply = <&vdd_3v3_sys>;
> > +
> > + ti,peak-current-microamp = <16000000>;
> > + ti,max-flash-timeout-ms = <1024>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + led@0 {
> > + reg = <0>;
> > +
> > + label = "white::flash";
> > + linux,default-trigger = "flash";
> > +
> > + ti,max-flash-current-microamp = <562500>;
> > + ti,max-torch-current-microamp = <156250>;
> > + };
> > +
> > + led@1 {
> > + reg = <1>;
> > +
> > + label = "yellow::flash";
> > + linux,default-trigger = "flash";
> > +
> > + ti,max-flash-current-microamp = <562500>;
> > + ti,max-torch-current-microamp = <156250>;
> > + };
> > + };
> > + };
>
> --
> Kind regards,
>
> Sakari Ailus
^ permalink raw reply
* Re: [PATCH v1 5/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Sakari Ailus @ 2026-04-17 12:36 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <CAPVz0n3wi2yzVc0noYe=5=VR2NWEeyXke3EPKJpSPm81qrpp4Q@mail.gmail.com>
Hi Svyatoslav,
On Fri, Apr 17, 2026 at 03:30:30PM +0300, Svyatoslav Ryhel wrote:
> пт, 17 квіт. 2026 р. о 15:13 Sakari Ailus <sakari.ailus@linux.intel.com> пише:
> >
> > Hi Svyatoslav,
> >
> > Thanks for the set.
> >
> > This patch should be the first one in the set, or at least before those
> > using the bindings defined here.
> >
>
> Maybe before conversion, but definitely not the first. I would like to
> avoid patch multiplication caused by schema adjustments after every
> single commit if possible.
You don't have to use all the properties defined but you can't use
properties in drivers not yet defined in bindings.
>
> > On Fri, Apr 17, 2026 at 02:42:26PM +0300, Svyatoslav Ryhel wrote:
> > > Document TI LM3560 Synchronous Boost Flash Driver used for camera flash
> > > LEDs.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > .../devicetree/bindings/leds/ti,lm3560.yaml | 134 ++++++++++++++++++
> > > 1 file changed, 134 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/leds/ti,lm3560.yaml b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> > > new file mode 100644
> > > index 000000000000..460ea1fbc1e5
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/leds/ti,lm3560.yaml
> > > @@ -0,0 +1,134 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/leds/ti,lm3560.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: TI LM3560 Synchronous Boost Flash Driver
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description:
> > > + The LM3560 is a 2-MHz fixed frequency synchronous boost converter with two
> > > + 1000-mA constant current drivers for high-current white LEDs. The dual high-
> > > + side current sources allow for grounded cathode LED operation and can be
> > > + tied together for providing flash currents at up to 2 A through a single LED.
> > > + An adaptive regulation method ensures the current for each LED remains in
> > > + regulation and maximizes efficiency.
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - ti,lm3559
> > > + - ti,lm3560
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + '#address-cells':
> > > + const: 1
> > > +
> > > + '#size-cells':
> > > + const: 0
> > > +
> > > + enable-gpios:
> > > + description: GPIO connected to the HWEN pin.
> > > + maxItems: 1
> > > +
> > > + vin-supply:
> > > + description: Supply connected to the IN line.
> > > +
> > > + ti,peak-current-microamp:
> > > + description:
> > > + The LM3560 features 4 selectable current limits 1.6A, 2.3A, 3A, and 3.6A.
> > > + When the current limit is reached, the LM3560 stops switching for the
> > > + remainder of the switching cycle.
> > > + enum: [16000000, 23000000, 30000000, 36000000]
> > > + default: 36000000
> > > +
> > > + ti,max-flash-timeout-ms:
> > > + description:
> > > + Maximum flash timeout in ms with step 32ms.
> > > + minimum: 32
> > > + maximum: 1024
> > > + default: 1024
> > > +
> > > +patternProperties:
> > > + '^led@[01]$':
> > > + description: LED control bank nodes.
> > > + $ref: /schemas/leds/common.yaml#
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + reg:
> > > + description: Control bank selection (0 = bank A, 1 = bank B).
> > > + maximum: 1
> > > +
> > > + ti,max-flash-current-microamp:
> > > + description:
> > > + Maximum flash current in uA with step 62500uA.
> > > + minimum: 62500
> > > + maximum: 1000000
> > > + default: 1000000
> > > +
> > > + ti,max-torch-current-microamp:
> >
> > Don't the LED flash bindings already have standardised properties for
> > these?
> >
>
> Oh, they do! Thanks for pointing out. led-max-microamp,
> flash-max-microamp and flash-max-timeout-us. Very nice, I will adjust
> in the v2.
Sounds good, thanks!
I think it'd be worth standardising maximum input current, too, as other
devices use it, too.
>
> > > + description:
> > > + Maximum flash current in uA with step 31250uA.
> > > + minimum: 31250
> > > + maximum: 250000
> > > + default: 250000
> > > +
> > > + required:
> > > + - reg
> >
> > I'd say the max current properties are required as well, same for the
> > timeouts. Or make the lowest the default. The lowest values are very seldom
> > used in practice though.
> >
>
> I have transferred from the driver which uses maximum values as
> default one. I can change to minimum if needed, that is not a big
> deal.
I'd just make these mandatory.
>
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - '#address-cells'
> > > + - '#size-cells'
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + i2c {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + led-controller@53 {
> > > + compatible = "ti,lm3560";
> > > + reg = <0x53>;
> > > +
> > > + enable-gpios = <&gpio 28 GPIO_ACTIVE_HIGH>;
> > > + vin-supply = <&vdd_3v3_sys>;
> > > +
> > > + ti,peak-current-microamp = <16000000>;
> > > + ti,max-flash-timeout-ms = <1024>;
> > > +
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + led@0 {
> > > + reg = <0>;
> > > +
> > > + label = "white::flash";
> > > + linux,default-trigger = "flash";
> > > +
> > > + ti,max-flash-current-microamp = <562500>;
> > > + ti,max-torch-current-microamp = <156250>;
> > > + };
> > > +
> > > + led@1 {
> > > + reg = <1>;
> > > +
> > > + label = "yellow::flash";
> > > + linux,default-trigger = "flash";
> > > +
> > > + ti,max-flash-current-microamp = <562500>;
> > > + ti,max-torch-current-microamp = <156250>;
> > > + };
> > > + };
> > > + };
> >
> > --
> > Kind regards,
> >
> > Sakari Ailus
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: use refgen regulator for DSI
From: Konrad Dybcio @ 2026-04-17 12:37 UTC (permalink / raw)
To: Pengyu Luo, Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <CAH2e8h7W8Tng4v9Da9c7xg-oczHgNcMvz0OF6A27L9m+Pw7iZA@mail.gmail.com>
On 4/17/26 2:23 PM, Pengyu Luo wrote:
> On Sat, Feb 28, 2026 at 9:13 PM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Sat, Feb 28, 2026 at 08:54:30PM +0800, Pengyu Luo wrote:
>>> Use it for the DSI controllers, since DSI nodes have been added.
>>>
>>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
>>> ---
>>> This patch depends on the below series:
>>> https://lore.kernel.org/linux-arm-msm/20260228101907.18043-1-mitltlatltl@gmail.com/
>>
>> Why was it not squashed into that series? I'd assume that DSI nodes are
>> incomplete and are working "by luck" without the refgen supplies.
>>
>
> Today, I did a casual read. I found the register(0x8900000 + 0x80) to
> enable refgen is always 0 on windows. The refgen driver may be not
> compatible with sc8280xp or the DT configuration is wrong.
The Linux driver casts a software vote. Most newer SoCs should have
a separate hw line between the PHYs and the REFGEN regulator to take
care of it automatically.
Even if a little unnecessary, this won't hurt
I *think* base+0xc & BIT(3) should tell you whether the power is
actually flowing at a given moment
Konrad
^ permalink raw reply
* Re: [PATCH v1 2/5] media: lm3560: Add IN supply support
From: Svyatoslav Ryhel @ 2026-04-17 12:37 UTC (permalink / raw)
To: Sakari Ailus
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <aeIk3z8f4dvjEXBQ@kekkonen.localdomain>
пт, 17 квіт. 2026 р. о 15:17 Sakari Ailus <sakari.ailus@linux.intel.com> пише:
>
> Hi Svyatoslav,
>
> On Fri, Apr 17, 2026 at 02:42:23PM +0300, Svyatoslav Ryhel wrote:
> > Add IN supply (2.5V - 5.5V) found in LM3560 to ensure its proper work.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/media/i2c/lm3560.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
> > index e6af61415821..a2674af6c9fb 100644
> > --- a/drivers/media/i2c/lm3560.c
> > +++ b/drivers/media/i2c/lm3560.c
> > @@ -16,6 +16,7 @@
> > #include <linux/slab.h>
> > #include <linux/mutex.h>
> > #include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> > #include <linux/videodev2.h>
> > #include <media/i2c/lm3560.h>
> > #include <media/v4l2-ctrls.h>
> > @@ -434,6 +435,11 @@ static int lm3560_probe(struct i2c_client *client)
> > return dev_err_probe(&client->dev, PTR_ERR(flash->hwen_gpio),
> > "failed to get hwen gpio\n");
> >
> > + rval = devm_regulator_get_enable(&client->dev, "vin");
>
> I'd also enable this via runtime PM.
>
> Sensor drivers such as imx219 serve as a good example here.
>
Would you mind if I squash adding hwen, vin and pm into single commit?
It would be tricky to separate them from PM addition. I will add
descriptions of what was changed.
> > + if (rval)
> > + return dev_err_probe(&client->dev, rval,
> > + "failed to enable regulator\n");
> > +
> > rval = lm3560_subdev_init(flash, LM3560_LED0, "lm3560-led0");
> > if (rval < 0)
> > return rval;
>
> --
> Kind regards,
>
> Sakari Ailus
^ permalink raw reply
* Re: [PATCH v1 2/5] media: lm3560: Add IN supply support
From: Sakari Ailus @ 2026-04-17 12:46 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, linux-leds, devicetree,
linux-kernel, linux-media
In-Reply-To: <CAPVz0n0vf_Re-4s4ygOP8aAMA+b=o7yM+UYVZiRUfkrJ931J2A@mail.gmail.com>
On Fri, Apr 17, 2026 at 03:37:37PM +0300, Svyatoslav Ryhel wrote:
> пт, 17 квіт. 2026 р. о 15:17 Sakari Ailus <sakari.ailus@linux.intel.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Fri, Apr 17, 2026 at 02:42:23PM +0300, Svyatoslav Ryhel wrote:
> > > Add IN supply (2.5V - 5.5V) found in LM3560 to ensure its proper work.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> > > drivers/media/i2c/lm3560.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
> > > index e6af61415821..a2674af6c9fb 100644
> > > --- a/drivers/media/i2c/lm3560.c
> > > +++ b/drivers/media/i2c/lm3560.c
> > > @@ -16,6 +16,7 @@
> > > #include <linux/slab.h>
> > > #include <linux/mutex.h>
> > > #include <linux/regmap.h>
> > > +#include <linux/regulator/consumer.h>
> > > #include <linux/videodev2.h>
> > > #include <media/i2c/lm3560.h>
> > > #include <media/v4l2-ctrls.h>
> > > @@ -434,6 +435,11 @@ static int lm3560_probe(struct i2c_client *client)
> > > return dev_err_probe(&client->dev, PTR_ERR(flash->hwen_gpio),
> > > "failed to get hwen gpio\n");
> > >
> > > + rval = devm_regulator_get_enable(&client->dev, "vin");
> >
> > I'd also enable this via runtime PM.
> >
> > Sensor drivers such as imx219 serve as a good example here.
> >
>
> Would you mind if I squash adding hwen, vin and pm into single commit?
> It would be tricky to separate them from PM addition. I will add
> descriptions of what was changed.
Sounds good to me.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
From: Krzysztof Kozlowski @ 2026-04-17 12:55 UTC (permalink / raw)
To: Alim Akhtar, avri.altman, bvanassche, robh, martin.petersen,
krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, 'Krzysztof Kozlowski'
In-Reply-To: <27b401dcce62$03bd3280$0b379780$@samsung.com>
On 17/04/2026 14:02, Alim Akhtar wrote:
>
>
>> -----Original Message-----
>> From: Alim Akhtar <alim.akhtar@samsung.com>
>> Sent: Friday, April 17, 2026 5:45 PM
>> To: avri.altman@wdc.com; bvanassche@acm.org; robh@kernel.org;
>> martin.petersen@oracle.com; krzk+dt@kernel.org
>> Cc: sowon.na@samsung.com; peter.griffin@linaro.org; linux-
>> scsi@vger.kernel.org; devicetree@vger.kernel.org; linux-samsung-
>> soc@vger.kernel.org; linux-kernel@vger.kernel.org; Krzysztof Kozlowski
>> <krzysztof.kozlowski@linaro.org>; Alim Akhtar <alim.akhtar@samsung.com>
>> Subject: [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920
>> compatible string
>>
>> From: Sowon Na <sowon.na@samsung.com>
>>
>> Add samsung,exynosautov920-ufs compatible for ExynosAutov920 SoC.
>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Just noticed that this email is no longer valid, In case there is a re-spin, will correct this.
> Sorry for the noise.
The ack can stay wild email, it's fine. It still gives the credit to
previous employer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Jonathan Cameron @ 2026-04-17 12:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Alexis Czezar Torreno, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel
In-Reply-To: <aeHwwN2sFJBzQ21H@ashevche-desk.local>
On Fri, 17 Apr 2026 11:35:12 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Fri, Apr 17, 2026 at 04:27:16PM +0800, Alexis Czezar Torreno wrote:
> > Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> > current output digital-to-analog converter with SPI interface.
> >
> > Features:
> > - 4 independent DAC channels
> > - Hardware and software LDAC trigger
> > - Configurable output range
> > - PWM-based LDAC control
> > - Dither and toggle modes
> > - Dynamically configurable SPI speed
>
> ...
>
> > +#define AD5706R_DAC_RESOLUTION 16
> > +#define AD5706R_DAC_MAX_CODE GENMASK(15, 0)
>
> I know Jonathan asked for this, hence it's comment for him.
> I think that BIT() notation in a form of (BIT(16) - 1) is
> also appropriate here as it gives the relationship to the
> resolution of the given register / bitfield in HW.
>
> GENMASK() works for me, but it might require an additional
> operation to deduce the above.
>
> (Note, there is no request to change or resend for you, Alexis. It's just
> a remark to make Jonathan to think about which one suits better. He might
> change that whilst applying.)
>
I'm not against that form. It was more being against bare BIT(16) as that was
1 greater than the maximum value it can take.
However making the relationship explicit would be even better.
#define AD5705_DAC_MAX_CODE (BIT(AD5706R_DAC_RESOLUTION) - 1)
I might tweak it when picking this up.
^ permalink raw reply
* Re: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Tudor Ambarus @ 2026-04-17 13:06 UTC (permalink / raw)
To: Alexey Klimov, daniel.lezcano
Cc: Rafael J. Wysocki, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alim Akhtar, Bartlomiej Zolnierkiewicz, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <63087cad-a8d1-4ff0-870a-6e1a738ff8b8@linaro.org>
On 4/9/26 3:22 PM, Tudor Ambarus wrote:
> No, it's more than that. When I talked with Daniel about this driver, he
> suggested I shall really focus on using the .set_trips callback instead of
> .set_trip_temp. I'm not sure if it's possible given the static nature of
> the ACPM interface. So it needs a bit of investigation, which I couldn't
> do lately.
FYI, I switched to .set_trips and testing went fine. I'll recheck the
review feedback and resubmit.
Cheers,
ta
^ permalink raw reply
* [PATCH v2 1/3] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel,
Paul Walmsley
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while back. Paul did a much better job at
finding the right words to mourn this loss than I ever could, so I will
leave this link here:
https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
Co-developed-by: Paul Walmsley <pjw@kernel.org>
Co-developed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Co-developed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v2:
- add more missing entries
CREDITS | 10 ++++++++++
MAINTAINERS | 1 -
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
index 885fb05d8816..afd1f70b41cf 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3645,7 +3645,17 @@ D: Macintosh IDE Driver
N: Peter De Schrijver
E: stud11@cc4.kuleuven.ac.be
+E: p2@mind.be
+E: peter.de-schrijver@nokia.com
+E: pdeschrijver@nvidia.com
+E: p2@psychaos.be
+D: Apollo Domain workstations
+D: Ariadne and Hydra Amiga Ethernet drivers
+D: IBM PS/2, Microchannel, and Token Ring support
D: Mitsumi CD-ROM driver patches March version
+D: TWL4030 power management and audio codec driver
+D: OMAP power management
+D: NVIDIA Tegra clock and BPMP drivers, among many other things
S: Molenbaan 29
S: B2240 Zandhoven
S: Belgium
diff --git a/MAINTAINERS b/MAINTAINERS
index ef978bfca514..ffe20d770249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26145,7 +26145,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
N: [^a-z]tegra
TEGRA CLOCK DRIVER
-M: Peter De Schrijver <pdeschrijver@nvidia.com>
M: Prashant Gaikwad <pgaikwad@nvidia.com>
S: Supported
F: drivers/clk/tegra/
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/3] Documentation: ABI: Take over as contact for sysfs-driver-tegra-fuse
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while ago, so I'll be taking over as contact
for this ABI documentation.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Documentation/ABI/testing/sysfs-driver-tegra-fuse | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
index b8936fad2ccf..47d5513100f6 100644
--- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
@@ -1,6 +1,6 @@
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
-Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
+Contact: Thierry Reding <thierry.reding@kernel.org>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is laid out in 32bit
--
2.52.0
^ permalink raw reply related
* [PATCH v2 3/3] dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM
From: Thierry Reding @ 2026-04-17 13:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-1-thierry.reding@kernel.org>
From: Thierry Reding <treding@nvidia.com>
Peter sadly passed away a while ago, so change the maintainers for BPMP
SHMEM to Jon and myself.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
index 4380f622f9a9..6efadc5f8078 100644
--- a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
@@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Tegra CPU-NS - BPMP IPC reserved memory
maintainers:
- - Peter De Schrijver <pdeschrijver@nvidia.com>
+ - Thierry Reding <thierry.reding@kernel.org>
+ - Jonathan Hunter <jonathanh@nvidia.com>
description: |
Define a memory region used for communication between CPU-NS and BPMP.
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: sc8280xp: use refgen regulator for DSI
From: Pengyu Luo @ 2026-04-17 13:24 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <54ab414e-a33e-4cdb-a125-5a980ea7e851@oss.qualcomm.com>
On Fri, Apr 17, 2026 at 8:37 PM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 4/17/26 2:23 PM, Pengyu Luo wrote:
> > On Sat, Feb 28, 2026 at 9:13 PM Dmitry Baryshkov
> > <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >>
> >> On Sat, Feb 28, 2026 at 08:54:30PM +0800, Pengyu Luo wrote:
> >>> Use it for the DSI controllers, since DSI nodes have been added.
> >>>
> >>> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
> >>> ---
> >>> This patch depends on the below series:
> >>> https://lore.kernel.org/linux-arm-msm/20260228101907.18043-1-mitltlatltl@gmail.com/
> >>
> >> Why was it not squashed into that series? I'd assume that DSI nodes are
> >> incomplete and are working "by luck" without the refgen supplies.
> >>
> >
> > Today, I did a casual read. I found the register(0x8900000 + 0x80) to
> > enable refgen is always 0 on windows. The refgen driver may be not
> > compatible with sc8280xp or the DT configuration is wrong.
>
> The Linux driver casts a software vote. Most newer SoCs should have
> a separate hw line between the PHYs and the REFGEN regulator to take
> care of it automatically.
>
> Even if a little unnecessary, this won't hurt
>
> I *think* base+0xc & BIT(3) should tell you whether the power is
> actually flowing at a given moment
>
I see. Thanks for your explanation!
Best wishes,
Pengyu
> Konrad
^ permalink raw reply
* Re: [PATCH v8 1/5] soc: qcom: ice: Add OPP-based clock scaling support for ICE
From: Harshal Dev @ 2026-04-17 13:25 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Kuldeep Singh,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-1-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> Register optional operation-points-v2 table for ICE device
> during device probe. Attach the OPP-table with only the ICE
> core clock. Since, dtbinding is on a trasition phase to include
> iface clock and clock-names, attaching the opp-table to core clock
> remains options such that it does not cause probe failures.
>
> Introduce clock scaling API qcom_ice_scale_clk which scale ICE
> core clock based on the target frequency provided and if a valid
> OPP-table is registered. Use round_ceil passed to decide on the
> rounding of the clock freq against OPP-table. Clock scaling is
> disabled when a valid OPP-table is not registered.
>
> This ensures when an ICE-device specific OPP table is available,
> use the PM OPP framework to manage frequency scaling and maintain
> proper power-domain constraints.
>
> Also, ensure to drop the votes in suspend to prevent power/thermal
> retention. Subsequently restore the frequency in resume from
> core_clk_freq which stores the last ICE core clock operating frequency.
>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ice.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++
> include/soc/qcom/ice.h | 2 ++
> 2 files changed, 94 insertions(+)
>
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index bf4ab2d9e5c0360d8fe6135cc35f93b6b09e7a0e..9e869e6abc6300c7608b4d9a18e7f3e80c93f5e7 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -16,6 +16,7 @@
[..]
> @@ -742,6 +800,40 @@ static int qcom_ice_probe(struct platform_device *pdev)
> if (IS_ERR(engine))
> return PTR_ERR(engine);
>
> + /* qcom_ice_create() may return NULL if scm calls are not available */
> + if (!engine)
> + return -EOPNOTSUPP;
> +
> + err = devm_pm_opp_set_clkname(&pdev->dev, "core");
> + if (err && err != -ENOENT) {
> + dev_err(&pdev->dev, "Unable to set core clkname to OPP-table\n");
> + return err;
> + }
> +
> + /* OPP table is optional */
> + err = devm_pm_opp_of_add_table(&pdev->dev);
> + if (err && err != -ENODEV) {
> + dev_err(&pdev->dev, "Invalid OPP table in Device tree\n");
> + return err;
> + }
> +
> + /*
> + * The OPP table is optional. devm_pm_opp_of_add_table() returns
> + * -ENODEV when no OPP table is present in DT, which is not treated
> + * as an error. Therefore, track successful OPP registration only
> + * when the return value is 0.
> + */
> + engine->has_opp = (err == 0);
> + if (!engine->has_opp)
> + dev_info(&pdev->dev, "ICE OPP table is not registered, please update your DT\n");
> +
> + /*
> + * Store the core clock rate for suspend resume cycles,
> + * against OPP aware DVFS operations. core_clk_freq will
> + * have a valid value only for non-legacy bindings.
> + */
> + engine->core_clk_freq = clk_get_rate(engine->core_clk);
> +
When you are calling 4-5 functions in a function, it's probably time to define another
function to keep things simple. Maybe qcom_ice_attach_opp_table().
Also, I still have issues with engine->has_opp = (err == 0), mostly because I don't
see this style used at other placed in the kernel. I would still suggest that you
make it simpler, but I won't hard-request it.
/* The same explanatory comment as before */
if (err == -ENODEV)
engine->has_opp = false;
dev_info(...);
else
engine->has_opp = true;
With these optional suggestions, feel free to add:
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> platform_set_drvdata(pdev, engine);
>
> return 0;
> diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
> index 4bee553f0a59d86ec6ce20f7c7b4bce28a706415..4eb58a264d416e71228ed4b13e7f53c549261fdc 100644
> --- a/include/soc/qcom/ice.h
> +++ b/include/soc/qcom/ice.h
> @@ -30,5 +30,7 @@ int qcom_ice_import_key(struct qcom_ice *ice,
> const u8 *raw_key, size_t raw_key_size,
> u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
> struct qcom_ice *devm_of_qcom_ice_get(struct device *dev);
> +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> + bool round_ceil);
>
> #endif /* __QCOM_ICE_H__ */
>
^ permalink raw reply
* Re: [PATCH v7 2/3] ufs: host: Add ICE clock scaling during UFS clock changes
From: Harshal Dev @ 2026-04-17 13:26 UTC (permalink / raw)
To: Abhinaba Rakshit, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Neeraj Soni
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi
In-Reply-To: <20260302-enable-ufs-ice-clock-scaling-v7-2-669b96ecadd8@oss.qualcomm.com>
On 3/2/2026 4:19 PM, Abhinaba Rakshit wrote:
> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> UFS controller clock scaling. This ensures that the ICE operates at
> an appropriate frequency when the UFS clocks are scaled up or down,
> improving performance and maintaining stability for crypto operations.
>
> For scale_up operation ensure to pass ~round_ceil (round_floor)
> and vice-versa for scale_down operations.
>
> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> devfreq for UFS, as ICE OPP-table is optional.
>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Regards,
Harshal
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: thermal: Add Google GS101 TMU
From: Tudor Ambarus @ 2026-04-17 13:28 UTC (permalink / raw)
To: Alexey Klimov, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik
Cc: willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <DGUJIFLIOK7Y.1Q4PZQU3MOWTT@linaro.org>
On 3/5/26 5:48 AM, Alexey Klimov wrote:
> Hi Tudor,
>
> On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
>> Document the Thermal Management Unit (TMU) found on the Google GS101 SoC.
>>
>> The GS101 TMU utilizes a hybrid control model shared between the
>> Application Processor (AP) and the ACPM (Alive Clock and Power Manager)
>> firmware.
>>
>> While the TMU is a standard memory-mapped IP block, on this platform
>
> this ^^
>
okay
cut
> Is it Google TMU hardware block or Exynos/Samsung TMU block?
>
> My understanding at this point is that ACPM interface, ACPM protocols, etc
> appeared on Samsung SoCs before gs101 (maybe even before initial SCMI
> prototyping). It looks like ACPM firmware, communication via mailboxes,
> TMU channel, dealing with TMU behing ACPM, etc are actually a standard
> Samsung Exynos architectural feature, rather than a Google-specific
> implementation. I can't say though what was the first chipset where it
> was implemented.
autov920, exynos850 too can use the hybrid ACPM TMU approach.
I'll generalize the description.
>
> Given that this is a Samsung design that predates the gs101, would it
> make sense to use more generic name for this binding to reflect that
> it is Exynos-derived? That would save us from generalizing things later
The name has to match the compatible. We can rename it when other Samsung
compatibles are added.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v8 3/5] mmc: sdhci-msm: Set ICE clk to TURBO at sdhci ICE init
From: Harshal Dev @ 2026-04-17 13:29 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Kuldeep Singh,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree,
Konrad Dybcio
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-3-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> MMC controller lacks a clock scaling mechanism, unlike the UFS
> controller. By default, the MMC controller is set to TURBO mode
> during probe, but the ICE clock remains at XO frequency,
> leading to read/write performance degradation on eMMC.
>
> To address this, set the ICE clock to TURBO during sdhci_msm_ice_init
> to align it with the controller clock. This ensures consistent
> performance and avoids mismatches between the controller
> and ICE clock frequencies.
>
> For platforms where ICE is represented as a separate device,
> use the OPP framework to vote for TURBO mode, maintaining
> proper voltage and power domain constraints.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/mmc/host/sdhci-msm.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
[...]
>
> static const struct blk_crypto_ll_ops sdhci_msm_crypto_ops; /* forward decl */
> +static int sdhci_msm_ice_scale_clk(struct sdhci_msm_host *msm_host, unsigned long target_freq,
> + bool round_ceil); /* forward decl */
>
> static int sdhci_msm_ice_init(struct sdhci_msm_host *msm_host,
> struct cqhci_host *cq_host)
> @@ -1964,6 +1966,11 @@ static int sdhci_msm_ice_init(struct sdhci_msm_host *msm_host,
> }
>
> mmc->caps2 |= MMC_CAP2_CRYPTO;
> +
> + err = sdhci_msm_ice_scale_clk(msm_host, INT_MAX, false);
The 2nd parameter is an unsigned long, do you really want to pass INT_MAX here? I would go with
UINT_MAX. But still, why go with such a high value? Do we not have an upper bound for the clk
frequency that we know we can't ever exceed for any target across OPP tables? If not, then maybe
UINT_MAX is best we can do here.
Regards,
Harshal
> + if (err && err != -EOPNOTSUPP)
> + dev_warn(dev, "Unable to boost ICE clock to TURBO\n");
> +
> return 0;
> }
>
> @@ -1989,6 +1996,16 @@ static int sdhci_msm_ice_suspend(struct sdhci_msm_host *msm_host)
> return 0;
> }
>
> +static int sdhci_msm_ice_scale_clk(struct sdhci_msm_host *msm_host,
> + unsigned long target_freq,
> + bool round_ceil)
> +{
> + if (msm_host->mmc->caps2 & MMC_CAP2_CRYPTO)
> + return qcom_ice_scale_clk(msm_host->ice, target_freq, round_ceil);
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v7 0/3] Mediatek MT8189 JPEG support
From: Nicolas Dufresne @ 2026-04-17 13:30 UTC (permalink / raw)
To: Jianhua Lin, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3866 bytes --]
Hi,
Le vendredi 17 avril 2026 à 18:05 +0800, Jianhua Lin a écrit :
> This series is based on tag: next-20260410, linux-next/master
What dependencies justify not submitting based on media-committers/next as usual
? Its fine to say you tested against linux-next of course, and if its only
working there, its really nice to explain why.
Nicolas
>
> Changes compared with v6:
> - Patches 1/3 (dt-bindings: decoder):
> update the existing `allOf` condition for mediatek,mt8189-jpgdec to
> make the 'mediatek,larb' property strictly required for MT8189 SoC.
> - Patches 2/3 (dt-bindings: encoder):
> Add an `allOf` condition to enforce that the `mediatek,larb` property
> is strictly required when the compatible string contains
> mediatek,mt8189-jpgenc.
>
> Changes compared with v5:
> - Patches 1/3 (dt-bindings: decoder):
> - Drop top-level minItems/maxItems for clock-names per Krzysztof's
> review.
> - Refine allOf block to strictly enforce clock constraints.
>
> Changes compared with v4:
> - Refines the device tree bindings for JPEG decoder and encoder.
> - Patches 1/3 (dt-bindings: decoder):
> Moved the standalone compatible string mediatek,mt8189-jpgdec
> into the first oneOf entry along with mt2701 and mt8173, as
> suggested by Rob Herring. This correctly groups all independent
> ICs and removes the redundant items wrapper.
> - Patches 2/3 (dt-bindings: encoder):
> Applied the same logic suggested by Rob Herring to the encoder
> binding. Restructured the compatible property to clearly
> distinguish between the standalone IC (mediatek,mt8189-jpgenc)
> and the ICs that must fallback to mediatek,mtk-jpgenc.
>
> Changes compared with v3:
> - The v4 is resending the cover-letter, because the v3 cover-letter was
> not sent successfully.
>
> Changes compared with v2:
> - Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
> compatible) as it belongs to a different tree/series.
> - Patches 1/3 (dt-bindings: decoder):
> - Changed the MT8189 compatible to be a standalone `const` instead of
> an `enum`.
> - Added an `allOf` block with conditional checks to enforce the single
> clock ("jpgdec") requirement for MT8189, while preserving the
> two-clock requirement for older SoCs.
> - Updated commit message to reflect the schema structure changes and
> hardware differences.
> - Patches 2/3 (dt-bindings: encoder):
> - Changed the MT8189 compatible to be a standalone `const` instead of
> an `enum` inside the `items` list, as it does not fallback to
> "mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
> - Updated commit message to explain the standalone compatible design.
> - Patches 3/3 (media: mediatek: jpeg):
> - Refined commit message for better clarity regarding 34-bit IOVA and
> single clock configuration.
>
> Changes compared with v1:
> - Patches 1/4:
> - Updating commit message
> - Patches 2/4, 3/4:
> - Updating commit message
> - Adjusted property descriptions acorrding to hardware requirements
> - Improved formatting for better readability and consistency
> - Patches 4/4:
> - Updating commit message
>
> Jianhua Lin (3):
> dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
> string
> dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
> string
> media: mediatek: jpeg: add compatible for MT8189 SoC
>
> .../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
> .../bindings/media/mediatek-jpeg-encoder.yaml | 29 ++++++++---
> .../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++
> 3 files changed, 107 insertions(+), 14 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v8 2/5] ufs: host: Add ICE clock scaling during UFS clock changes
From: Harshal Dev @ 2026-04-17 13:32 UTC (permalink / raw)
To: Abhinaba Rakshit, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Adrian Hunter, Ulf Hansson, Neeraj Soni, Kuldeep Singh,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, linux-scsi, linux-mmc, devicetree
In-Reply-To: <20260409-enable-ice-clock-scaling-v8-2-ca1129798606@oss.qualcomm.com>
On 4/9/2026 5:14 PM, Abhinaba Rakshit wrote:
> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> UFS controller clock scaling. This ensures that the ICE operates at
> an appropriate frequency when the UFS clocks are scaled up or down,
> improving performance and maintaining stability for crypto operations.
>
> For scale_up operation ensure to pass ~round_ceil (round_floor)
> and vice-versa for scale_down operations.
>
> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> devfreq for UFS, as ICE OPP-table is optional.
>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
Whoops, I mistakenly replied to v7 of this patch with a Reviewed-by, please
ignore that one.
Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
Regards,
Harshal
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: Harshal Dev @ 2026-04-17 13:38 UTC (permalink / raw)
To: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, johannes.goede
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <82e0d347-9ac9-497c-bc67-0db9206c5dd2@oss.qualcomm.com>
On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
> On 4/17/26 11:22 AM, Harshal Dev wrote:
>> Hi,
>>
>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>> SM8x50 platforms.
>>>>
>>>> Describe the crypto engine and its BAM.
>>>>
>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>> 1 file changed, 26 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>> status = "disabled";
>>>> };
>>>>
>>>> + cryptobam: dma-controller@1dc4000 {
>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>> + #dma-cells = <1>;
>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>> + <&apps_smmu 0x481 0x0>;
>>>
>>> It seems like these aren't the right SIDs on this platform.. Have you
>>> tested this patch on hw?
>>
>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>> (I hope I don't need to pad them?)
>
> No, you don't
Ack.
>
>>
>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>
>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>
>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>> SIDs and wait for a Tested-by from him.
>
> Thanks
>
> I think you should be able to get some life out of the crypto engine
> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
> mentioned reports a failure on Hamoa)
Sure, I'll try this, could you also point me to the bug report?
Regards,
Harshal
>
> Konrad
^ permalink raw reply
* [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: Ariana Lazar @ 2026-04-17 13:38 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Conor Dooley, Jonathan Cameron, linux-iio, devicetree,
linux-kernel, Ariana Lazar
Change maxItems value from 8 to 1 for the channel number reg property.
Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
---
Changes in v2:
- keep just maxItems value update in this patch
- remove Reported-by from commit message
- Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
---
Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
--- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
@@ -161,8 +161,7 @@ patternProperties:
properties:
reg:
description: The channel number.
- minItems: 1
- maxItems: 8
+ maxItems: 1
label:
description: Unique name to identify which channel this is.
---
base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
change-id: 20260416-mcp47feb02-fix5-26994c5b428c
Best regards,
--
Ariana Lazar <ariana.lazar@microchip.com>
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: johannes.goede @ 2026-04-17 14:30 UTC (permalink / raw)
To: Harshal Dev, Konrad Dybcio, Thara Gopinath, Herbert Xu,
David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <0d5bf2bd-b90c-4814-bd2e-126a9bcb82ce@oss.qualcomm.com>
Hi,
On 17-Apr-26 15:38, Harshal Dev wrote:
>
>
> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>> Hi,
>>>
>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>> SM8x50 platforms.
>>>>>
>>>>> Describe the crypto engine and its BAM.
>>>>>
>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>> 1 file changed, 26 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + cryptobam: dma-controller@1dc4000 {
>>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>> + #dma-cells = <1>;
>>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>>> + <&apps_smmu 0x481 0x0>;
>>>>
>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>> tested this patch on hw?
>>>
>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>> (I hope I don't need to pad them?)
>>
>> No, you don't
>
> Ack.
>
>>
>>>
>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>
>>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>
>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>> SIDs and wait for a Tested-by from him.
>>
>> Thanks
>>
>> I think you should be able to get some life out of the crypto engine
>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>> mentioned reports a failure on Hamoa)
>
> Sure, I'll try this, could you also point me to the bug report?
No bug report yet, I was asking around internally who I should
talk to about his.
I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
T14s gen 6 (Hamoa x1e78100):
[ 1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
[ 1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
[ 1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"
This is with manually compiled 7.0-rc# using Fedora's default kernel
config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
with the latter being hidden behind CONFIG_EXPERT for some reason.
This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
is also enabled by Fedora and it works fine.
I've not looked further into this yet, other then a message to fellow
OSTT team arm64-laptop users asking for tips / whom to report this to.
I would be happy to send create a kernel.bugzilla.org bug-report
about this to, or report to email somewhere, or ...
Please let met know where you want a bug-report to be filed and
also what information to add on top of the above info ?
E.g. these failures trigger a WARN() and thus log a backtrace,
do you want those backtraces and if yes I presume I should run
them through addr2line ?
Regards,
Hans
^ 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