* [PATCH v1 0/5] media: lm3560: convert to use OF bindings
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
Add missing HWEN input pin and IN supply. Fix v4l2 subdev registration.
Remove platform data and switch to OF device tree bindings.
Svyatoslav Ryhel (5):
media: lm3560: Add HWEN pin support
media: lm3560: Add IN supply support
media: lm3560: Fix v4l2 subdev registration
media: lm3560: convert to use OF bindings
dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
.../devicetree/bindings/leds/ti,lm3560.yaml | 134 +++++++++++++++++
drivers/media/i2c/lm3560.c | 139 ++++++++++++++----
include/media/i2c/lm3560.h | 15 --
3 files changed, 243 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3560.yaml
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/5] media: lm3560: Add HWEN pin support
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
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);
+ 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[] = {
--
2.51.0
^ permalink raw reply related
* [PATCH v1 2/5] media: lm3560: Add IN supply support
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
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");
+ 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;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 3/5] media: lm3560: Fix v4l2 subdev registration
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
The existing driver does not call media subdev registration, making it
invisible to the media framework. Since the LM3560 supports two
independent LEDs, register each LED as a separate media entity.
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 a2674af6c9fb..bee1681a1603 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -368,10 +368,16 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
goto err_out;
flash->subdev_led[led_no].entity.function = MEDIA_ENT_F_FLASH;
+ rval = v4l2_async_register_subdev(&flash->subdev_led[led_no]);
+ if (rval < 0)
+ goto err_out;
+
return rval;
err_out:
v4l2_ctrl_handler_free(&flash->ctrls_led[led_no]);
+ media_entity_cleanup(&flash->subdev_led[led_no].entity);
+
return rval;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v1 4/5] media: lm3560: convert to use OF bindings
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
Since there are no users of this driver via platform data, remove platform
data and switch to using device tree bindings.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/media/i2c/lm3560.c | 118 +++++++++++++++++++++++++++----------
include/media/i2c/lm3560.h | 15 -----
2 files changed, 87 insertions(+), 46 deletions(-)
diff --git a/drivers/media/i2c/lm3560.c b/drivers/media/i2c/lm3560.c
index bee1681a1603..dab2da87331d 100644
--- a/drivers/media/i2c/lm3560.c
+++ b/drivers/media/i2c/lm3560.c
@@ -14,7 +14,9 @@
#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/slab.h>
+#include <linux/mod_devicetable.h>
#include <linux/mutex.h>
+#include <linux/property.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/videodev2.h>
@@ -45,17 +47,19 @@ enum led_enable {
* struct lm3560_flash
*
* @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
* @subdev_led: V4L2 subdev
+ * @peak: peak current
+ * @max_flash_timeout: flash timeout
+ * @max_flash_brt: flash mode led brightness
+ * @max_torch_brt: torch mode led brightness
*/
struct lm3560_flash {
struct device *dev;
- struct lm3560_platform_data *pdata;
struct regmap *regmap;
struct gpio_desc *hwen_gpio;
struct mutex lock;
@@ -63,6 +67,12 @@ struct lm3560_flash {
enum v4l2_flash_led_mode led_mode;
struct v4l2_ctrl_handler ctrls_led[LM3560_LED_MAX];
struct v4l2_subdev subdev_led[LM3560_LED_MAX];
+
+ enum lm3560_peak_current peak;
+ u32 max_flash_timeout;
+
+ u32 max_flash_brt[LM3560_LED_MAX];
+ u32 max_torch_brt[LM3560_LED_MAX];
};
#define to_lm3560_flash(_ctrl, _no) \
@@ -283,8 +293,8 @@ static int lm3560_init_controls(struct lm3560_flash *flash,
enum lm3560_led_id led_no)
{
struct v4l2_ctrl *fault;
- u32 max_flash_brt = flash->pdata->max_flash_brt[led_no];
- u32 max_torch_brt = flash->pdata->max_torch_brt[led_no];
+ u32 max_flash_brt = flash->max_flash_brt[led_no];
+ u32 max_torch_brt = flash->max_torch_brt[led_no];
struct v4l2_ctrl_handler *hdl = &flash->ctrls_led[led_no];
const struct v4l2_ctrl_ops *ops = &lm3560_led_ctrl_ops[led_no];
@@ -309,9 +319,9 @@ static int lm3560_init_controls(struct lm3560_flash *flash,
/* flash strobe timeout */
v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FLASH_TIMEOUT,
LM3560_FLASH_TOUT_MIN,
- flash->pdata->max_flash_timeout,
+ flash->max_flash_timeout,
LM3560_FLASH_TOUT_STEP,
- flash->pdata->max_flash_timeout);
+ flash->max_flash_timeout);
/* flash brt */
v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FLASH_INTENSITY,
@@ -351,15 +361,17 @@ static const struct regmap_config lm3560_regmap = {
};
static int lm3560_subdev_init(struct lm3560_flash *flash,
- enum lm3560_led_id led_no, char *led_name)
+ enum lm3560_led_id led_no,
+ struct fwnode_handle *fwnode)
{
struct i2c_client *client = to_i2c_client(flash->dev);
int rval;
v4l2_i2c_subdev_init(&flash->subdev_led[led_no], client, &lm3560_ops);
flash->subdev_led[led_no].flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
- strscpy(flash->subdev_led[led_no].name, led_name,
- sizeof(flash->subdev_led[led_no].name));
+ snprintf(flash->subdev_led[led_no].name,
+ sizeof(flash->subdev_led[led_no].name),
+ "lm3560-led%d", led_no);
rval = lm3560_init_controls(flash, led_no);
if (rval)
goto err_out;
@@ -367,6 +379,7 @@ static int lm3560_subdev_init(struct lm3560_flash *flash,
if (rval < 0)
goto err_out;
flash->subdev_led[led_no].entity.function = MEDIA_ENT_F_FLASH;
+ flash->subdev_led[led_no].fwnode = fwnode;
rval = v4l2_async_register_subdev(&flash->subdev_led[led_no]);
if (rval < 0)
@@ -388,7 +401,7 @@ static int lm3560_init_device(struct lm3560_flash *flash)
/* set peak current */
rval = regmap_update_bits(flash->regmap,
- REG_FLASH_TOUT, 0x60, flash->pdata->peak);
+ REG_FLASH_TOUT, 0x60, flash->peak);
if (rval < 0)
return rval;
/* output disable */
@@ -401,10 +414,64 @@ static int lm3560_init_device(struct lm3560_flash *flash)
return rval;
}
+static int lm3560_of_probe(struct lm3560_flash *flash)
+{
+ struct fwnode_handle *node;
+ u32 peak_ua;
+ int rval, reg;
+
+ flash->peak = LM3560_PEAK_3600mA;
+ rval = device_property_read_u32(flash->dev,
+ "ti,peak-current-microamp", &peak_ua);
+ if (!rval) {
+ switch (peak_ua) {
+ case 16000000:
+ flash->peak = LM3560_PEAK_1600mA;
+ break;
+ case 23000000:
+ flash->peak = LM3560_PEAK_2300mA;
+ break;
+ case 30000000:
+ flash->peak = LM3560_PEAK_3000mA;
+ break;
+ case 36000000:
+ flash->peak = LM3560_PEAK_3600mA;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+
+ flash->max_flash_timeout = LM3560_FLASH_TOUT_MAX;
+ device_property_read_u32(flash->dev, "ti,max-flash-timeout-ms",
+ &flash->max_flash_timeout);
+
+ device_for_each_child_node(flash->dev, node) {
+ fwnode_property_read_u32(node, "reg", ®);
+
+ if (reg == LM3560_LED0 || reg == LM3560_LED1) {
+ flash->max_flash_brt[reg] = LM3560_FLASH_BRT_MAX;
+ fwnode_property_read_u32(node, "ti,max-flash-current-microamp",
+ &flash->max_flash_brt[reg]);
+
+ flash->max_torch_brt[reg] = LM3560_TORCH_BRT_MAX;
+ fwnode_property_read_u32(node, "ti,max-torch-current-microamp",
+ &flash->max_torch_brt[reg]);
+
+ rval = lm3560_subdev_init(flash, reg, node);
+ if (rval < 0)
+ return dev_err_probe(flash->dev, rval,
+ "failed to register led%d\n",
+ reg);
+ }
+ }
+
+ return 0;
+}
+
static int lm3560_probe(struct i2c_client *client)
{
struct lm3560_flash *flash;
- struct lm3560_platform_data *pdata = dev_get_platdata(&client->dev);
int rval;
flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
@@ -417,21 +484,6 @@ static int lm3560_probe(struct i2c_client *client)
return rval;
}
- /* if there is no platform data, use chip default value */
- if (pdata == NULL) {
- pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
- if (pdata == NULL)
- return -ENODEV;
- pdata->peak = LM3560_PEAK_3600mA;
- pdata->max_flash_timeout = LM3560_FLASH_TOUT_MAX;
- /* led 1 */
- pdata->max_flash_brt[LM3560_LED0] = LM3560_FLASH_BRT_MAX;
- pdata->max_torch_brt[LM3560_LED0] = LM3560_TORCH_BRT_MAX;
- /* led 2 */
- pdata->max_flash_brt[LM3560_LED1] = LM3560_FLASH_BRT_MAX;
- pdata->max_torch_brt[LM3560_LED1] = LM3560_TORCH_BRT_MAX;
- }
- flash->pdata = pdata;
flash->dev = &client->dev;
mutex_init(&flash->lock);
@@ -446,11 +498,7 @@ static int lm3560_probe(struct i2c_client *client)
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;
-
- rval = lm3560_subdev_init(flash, LM3560_LED1, "lm3560-led1");
+ rval = lm3560_of_probe(flash);
if (rval < 0)
return rval;
@@ -477,6 +525,13 @@ static void lm3560_remove(struct i2c_client *client)
gpiod_set_value_cansleep(flash->hwen_gpio, 0);
}
+static const struct of_device_id lm3560_of_match[] = {
+ { .compatible = "ti,lm3559" },
+ { .compatible = "ti,lm3560" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, lm3560_of_match);
+
static const struct i2c_device_id lm3560_id_table[] = {
{ LM3559_NAME },
{ LM3560_NAME },
@@ -489,6 +544,7 @@ static struct i2c_driver lm3560_i2c_driver = {
.driver = {
.name = LM3560_NAME,
.pm = NULL,
+ .of_match_table = lm3560_of_match,
},
.probe = lm3560_probe,
.remove = lm3560_remove,
diff --git a/include/media/i2c/lm3560.h b/include/media/i2c/lm3560.h
index 770d8c72c94a..b56c1ff8fd49 100644
--- a/include/media/i2c/lm3560.h
+++ b/include/media/i2c/lm3560.h
@@ -66,19 +66,4 @@ enum lm3560_peak_current {
LM3560_PEAK_3600mA = 0x60
};
-/* struct lm3560_platform_data
- *
- * @peak : peak current
- * @max_flash_timeout: flash timeout
- * @max_flash_brt: flash mode led brightness
- * @max_torch_brt: torch mode led brightness
- */
-struct lm3560_platform_data {
- enum lm3560_peak_current peak;
-
- u32 max_flash_timeout;
- u32 max_flash_brt[LM3560_LED_MAX];
- u32 max_torch_brt[LM3560_LED_MAX];
-};
-
#endif /* __LM3560_H__ */
--
2.51.0
^ permalink raw reply related
* [PATCH v1 5/5] dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
From: Svyatoslav Ryhel @ 2026-04-17 11:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sakari Ailus, Mauro Carvalho Chehab,
Svyatoslav Ryhel
Cc: linux-leds, devicetree, linux-kernel, linux-media
In-Reply-To: <20260417114226.100033-1-clamor95@gmail.com>
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:
+ description:
+ Maximum flash current in uA with step 31250uA.
+ minimum: 31250
+ maximum: 250000
+ default: 250000
+
+ required:
+ - reg
+
+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>;
+ };
+ };
+ };
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/4] add ufs support for Exynosautov920 SoC
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <CGME20260417115813epcas5p40234b872c221ce28981b17e42ca48139@epcas5p4.samsung.com>
This series adds ufs driver support for ExynosAutov920,
ExynosAutov920 has the UFSHCI 3.1 compliant UFS controller.
ExynosAutov920 has a different mask of UFS sharability from ExynosAutov9,
so this series provide flexible parameter for the mask.
With this series applied, UFS is functional and basic I/O operations are
known to be working.
Changes since v1:
* collected Acked-by on patch 2/4
* This Acked-by from Krzysztof was long back, for now kept it
* rebased on linux-next
* fixed few self review comments
* split dtsi patch into two, separated out syscon node patch
Link v1:
https://lore.kernel.org/linux-samsung-soc/20250702013316.2837427-1-sowon.na@samsung.com/
Alim Akhtar (1):
arm64: dts: exynosautov920: Add syscon hsi2 node
Sowon Na (3):
dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
scsi: ufs: exynos: add support for ExynosAutov920 SoC
arm64: dts: exynosautov920: enable support for ufs controller
.../bindings/ufs/samsung,exynos-ufs.yaml | 1 +
.../boot/dts/exynos/exynosautov920-sadk.dts | 8 ++
.../arm64/boot/dts/exynos/exynosautov920.dtsi | 27 +++++
drivers/ufs/host/ufs-exynos.c | 110 ++++++++++++++++++
4 files changed, 146 insertions(+)
base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
--
2.34.1
^ permalink raw reply
* [PATCH v2 1/4] arm64: dts: exynosautov920: Add syscon hsi2 node
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
Syscon HSI2 block has system configuration settings for
HSI IPs, like ufs, usb etc. Add a syscon_hsi2 node entry
so that related HSI controller can make use of the same.
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/exynosautov920.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
index 0bf7c4cb9846..0eb853770732 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
@@ -1426,6 +1426,12 @@ cmu_hsi2: clock-controller@16b00000 {
"ethernet";
};
+ syscon_hsi2: syscon@16c00000 {
+ compatible = "samsung,exynosautov920-hsi2-sysreg",
+ "syscon";
+ reg = <0x16c00000 0x800>;
+ };
+
pinctrl_hsi2: pinctrl@16c10000 {
compatible = "samsung,exynosautov920-pinctrl";
reg = <0x16c10000 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Krzysztof Kozlowski, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
From: Sowon Na <sowon.na@samsung.com>
Add samsung,exynosautov920-ufs compatible for ExynosAutov920 SoC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
index a7eb7ad85a94..710ce493f3b6 100644
--- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
@@ -19,6 +19,7 @@ properties:
- samsung,exynos7-ufs
- samsung,exynosautov9-ufs
- samsung,exynosautov9-ufs-vh
+ - samsung,exynosautov920-ufs
- tesla,fsd-ufs
reg:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] scsi: ufs: exynos: add support for ExynosAutov920 SoC
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
From: Sowon Na <sowon.na@samsung.com>
Add a dedicated compatible and drv_data with associated hooks for
ExynosAutov920 SoC.
ExynosAutov920 has a different mask of UFS sharability
from ExynosAutov9, so add related changes for the same.
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
[Alim: fixed unintended changes, other fixes]
---
drivers/ufs/host/ufs-exynos.c | 110 ++++++++++++++++++++++++++++++++++
1 file changed, 110 insertions(+)
diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
index 77a6c8e44485..b2f65c465525 100644
--- a/drivers/ufs/host/ufs-exynos.c
+++ b/drivers/ufs/host/ufs-exynos.c
@@ -97,6 +97,10 @@
#define UFS_EXYNOSAUTO_RD_SHARABLE BIT(1)
#define UFS_EXYNOSAUTO_SHARABLE (UFS_EXYNOSAUTO_WR_SHARABLE | \
UFS_EXYNOSAUTO_RD_SHARABLE)
+#define UFS_EXYNOSAUTOV920_WR_SHARABLE BIT(3)
+#define UFS_EXYNOSAUTOV920_RD_SHARABLE BIT(2)
+#define UFS_EXYNOSAUTOV920_SHARABLE (UFS_EXYNOSAUTOV920_WR_SHARABLE |\
+ UFS_EXYNOSAUTOV920_RD_SHARABLE)
#define UFS_GS101_WR_SHARABLE BIT(1)
#define UFS_GS101_RD_SHARABLE BIT(0)
#define UFS_GS101_SHARABLE (UFS_GS101_WR_SHARABLE | \
@@ -417,6 +421,95 @@ static int exynos7_ufs_post_pwr_change(struct exynos_ufs *ufs,
return 0;
}
+static int exynosautov920_ufs_pre_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ int i;
+ u32 tx_line_reset_period, rx_line_reset_period;
+
+ rx_line_reset_period = (RX_LINE_RESET_TIME * ufs->mclk_rate)
+ / NSEC_PER_MSEC;
+ tx_line_reset_period = (TX_LINE_RESET_TIME * ufs->mclk_rate)
+ / NSEC_PER_MSEC;
+
+ unipro_writel(ufs, 0x5f, 0x44);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x200), 0x40);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x202), 0x02);
+
+ for_each_ufs_rx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_CLK_PRD, i),
+ DIV_ROUND_UP(NSEC_PER_SEC, ufs->mclk_rate));
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_CLK_PRD_EN, i), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_LINERESET_VALUE2, i),
+ (rx_line_reset_period >> 16) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_LINERESET_VALUE1, i),
+ (rx_line_reset_period >> 8) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_RX_LINERESET_VALUE0, i),
+ (rx_line_reset_period) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x2f, i), 0x69);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x84, i), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x25, i), 0xf6);
+ }
+
+ for_each_ufs_tx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_CLK_PRD, i),
+ DIV_ROUND_UP(NSEC_PER_SEC, ufs->mclk_rate));
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_CLK_PRD_EN, i),
+ 0x02);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_LINERESET_PVALUE2, i),
+ (tx_line_reset_period >> 16) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_LINERESET_PVALUE1, i),
+ (tx_line_reset_period >> 8) & 0xFF);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(VND_TX_LINERESET_PVALUE0, i),
+ (tx_line_reset_period) & 0xFF);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x04, i), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x7f, i), 0x0);
+ }
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x200), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_LOCAL_TX_LCC_ENABLE), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0xa011), 0x8000);
+
+ return 0;
+}
+
+static int exynosautov920_ufs_post_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x9529), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x15a4), 0x3e8);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x9529), 0x0);
+
+ return 0;
+}
+
+static int exynosautov920_ufs_pre_pwr_change(struct exynos_ufs *ufs,
+ struct ufs_pa_layer_attr *pwr)
+{
+ struct ufs_hba *hba = ufs->hba;
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(0x15d4), 0x1);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(DL_FC0PROTTIMEOUTVAL), 8064);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(DL_TC0REPLAYTIMEOUTVAL), 28224);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(DL_AFC0REQTIMEOUTVAL), 20160);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA0), 12000);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA1), 32000);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_PWRMODEUSERDATA2), 16000);
+
+ unipro_writel(ufs, 8064, UNIPRO_DME_POWERMODE_REQ_LOCALL2TIMER0);
+ unipro_writel(ufs, 28224, UNIPRO_DME_POWERMODE_REQ_LOCALL2TIMER1);
+ unipro_writel(ufs, 20160, UNIPRO_DME_POWERMODE_REQ_LOCALL2TIMER2);
+ unipro_writel(ufs, 12000, UNIPRO_DME_POWERMODE_REQ_REMOTEL2TIMER0);
+ unipro_writel(ufs, 32000, UNIPRO_DME_POWERMODE_REQ_REMOTEL2TIMER1);
+ unipro_writel(ufs, 16000, UNIPRO_DME_POWERMODE_REQ_REMOTEL2TIMER2);
+
+ return 0;
+}
+
/*
* exynos_ufs_auto_ctrl_hcc - HCI core clock control by h/w
* Control should be disabled in the below cases
@@ -2201,6 +2294,21 @@ static const struct exynos_ufs_drv_data gs101_ufs_drvs = {
.suspend = gs101_ufs_suspend,
};
+static const struct exynos_ufs_drv_data exynosautov920_ufs_drvs = {
+ .uic_attr = &exynos7_uic_attr,
+ .quirks = UFSHCD_QUIRK_SKIP_DEF_UNIPRO_TIMEOUT_SETTING,
+ .opts = EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL |
+ EXYNOS_UFS_OPT_SKIP_CONFIG_PHY_ATTR |
+ EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX |
+ EXYNOS_UFS_OPT_TIMER_TICK_SELECT,
+ .iocc_mask = UFS_EXYNOSAUTOV920_SHARABLE,
+ .drv_init = exynosauto_ufs_drv_init,
+ .post_hce_enable = exynosauto_ufs_post_hce_enable,
+ .pre_link = exynosautov920_ufs_pre_link,
+ .post_link = exynosautov920_ufs_post_link,
+ .pre_pwr_change = exynosautov920_ufs_pre_pwr_change,
+};
+
static const struct of_device_id exynos_ufs_of_match[] = {
{ .compatible = "google,gs101-ufs",
.data = &gs101_ufs_drvs },
@@ -2210,6 +2318,8 @@ static const struct of_device_id exynos_ufs_of_match[] = {
.data = &exynosauto_ufs_drvs },
{ .compatible = "samsung,exynosautov9-ufs-vh",
.data = &exynosauto_ufs_vh_drvs },
+ { .compatible = "samsung,exynosautov920-ufs",
+ .data = &exynosautov920_ufs_drvs },
{ .compatible = "tesla,fsd-ufs",
.data = &fsd_ufs_drvs },
{},
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: exynosautov920: enable support for ufs controller
From: Alim Akhtar @ 2026-04-17 12:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, martin.petersen, krzk+dt
Cc: sowon.na, peter.griffin, linux-scsi, devicetree,
linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
From: Sowon Na <sowon.na@samsung.com>
Add ufs node for ExynosAutov920 SoC. Also enable ufs_phy and
ufs controller nodes.
Signed-off-by: Sowon Na <sowon.na@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
.../boot/dts/exynos/exynosautov920-sadk.dts | 8 +++++++
.../arm64/boot/dts/exynos/exynosautov920.dtsi | 21 +++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
index a397f068ed53..5873720c213e 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
+++ b/arch/arm64/boot/dts/exynos/exynosautov920-sadk.dts
@@ -83,6 +83,14 @@ &usi_0 {
status = "okay";
};
+&ufs_0 {
+ status = "okay";
+};
+
+&ufs_0_phy {
+ status = "okay";
+};
+
&xtcxo {
clock-frequency = <38400000>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
index 0eb853770732..f1f5efcdb91e 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynosautov920.dtsi
@@ -1444,6 +1444,27 @@ pinctrl_hsi2ufs: pinctrl@16d20000 {
interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
};
+ ufs_0: ufs@16e00000 {
+ compatible = "samsung,exynosautov920-ufs";
+ reg = <0x16e00000 0x100>,
+ <0x16e01100 0x400>,
+ <0x16e80000 0x8000>,
+ <0x16d08000 0x800>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = <GIC_SPI 613 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu_hsi2 CLK_MOUT_HSI2_UFS_EMBD_USER>,
+ <&cmu_hsi2 CLK_MOUT_HSI2_NOC_UFS_USER>;
+ clock-names = "core_clk", "sclk_unipro_main";
+ freq-table-hz = <0 0>, <0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
+ phys = <&ufs_0_phy>;
+ phy-names = "ufs-phy";
+ samsung,sysreg = <&syscon_hsi2 0x710>;
+ dma-coherent;
+ status = "disabled";
+ };
+
ufs_0_phy: phy@16e04000 {
compatible = "samsung,exynosautov920-ufs-phy";
reg = <0x16e04000 0x4000>;
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v2 2/4] dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
From: Alim Akhtar @ 2026-04-17 12:02 UTC (permalink / raw)
To: 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: <20260417121452.827054-3-alim.akhtar@samsung.com>
> -----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.
^ 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: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
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