* [PATCH RFC 06/10] driver core: make struct device_type member groups a constant array
From: Heiner Kallweit @ 2026-02-17 22:29 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groups array, allowing to assign constant arrays.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index bfa2ca603c2..808f723bbcf 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -87,7 +87,7 @@ int subsys_virtual_register(const struct bus_type *subsys,
*/
struct device_type {
const char *name;
- const struct attribute_group **groups;
+ const struct attribute_group *const *groups;
int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
char *(*devnode)(const struct device *dev, umode_t *mode,
kuid_t *uid, kgid_t *gid);
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 05/10] driver core: make struct device member groups a constant array
From: Heiner Kallweit @ 2026-02-17 22:28 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groups array, allowing to assign constant arrays.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 48a0444ccc1..bfa2ca603c2 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -640,7 +640,7 @@ struct device {
struct list_head devres_head;
const struct class *class;
- const struct attribute_group **groups; /* optional groups */
+ const struct attribute_group *const *groups; /* optional groups */
void (*release)(struct device *dev);
struct iommu_group *iommu_group;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 04/10] driver: core: constify groups array argument in device_add_groups and device_remove_groups
From: Heiner Kallweit @ 2026-02-17 22:28 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Now that sysfs_create_groups() and sysfs_remove_groups() allow to
pass constant groups arrays, we can constify the groups array argument
also here.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/base/core.c | 5 +++--
include/linux/device.h | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index f599a1384ee..4db63b2603c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2831,14 +2831,15 @@ static ssize_t removable_show(struct device *dev, struct device_attribute *attr,
}
static DEVICE_ATTR_RO(removable);
-int device_add_groups(struct device *dev, const struct attribute_group **groups)
+int device_add_groups(struct device *dev,
+ const struct attribute_group *const *groups)
{
return sysfs_create_groups(&dev->kobj, groups);
}
EXPORT_SYMBOL_GPL(device_add_groups);
void device_remove_groups(struct device *dev,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
sysfs_remove_groups(&dev->kobj, groups);
}
diff --git a/include/linux/device.h b/include/linux/device.h
index 0be95294b6e..48a0444ccc1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1131,9 +1131,9 @@ device_create_with_groups(const struct class *cls, struct device *parent, dev_t
void device_destroy(const struct class *cls, dev_t devt);
int __must_check device_add_groups(struct device *dev,
- const struct attribute_group **groups);
+ const struct attribute_group *const *groups);
void device_remove_groups(struct device *dev,
- const struct attribute_group **groups);
+ const struct attribute_group *const *groups);
static inline int __must_check device_add_group(struct device *dev,
const struct attribute_group *grp)
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 03/10] sysfs: constify group arrays in function arguments
From: Heiner Kallweit @ 2026-02-17 22:27 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
Constify the groups array argument where applicable. This allows to
pass constant arrays as arguments.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
fs/sysfs/group.c | 10 +++++-----
include/linux/sysfs.h | 16 ++++++++--------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index e1e639f515a..b3edae0578c 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -217,7 +217,7 @@ int sysfs_create_group(struct kobject *kobj,
EXPORT_SYMBOL_GPL(sysfs_create_group);
static int internal_create_groups(struct kobject *kobj, int update,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
int error = 0;
int i;
@@ -250,7 +250,7 @@ static int internal_create_groups(struct kobject *kobj, int update,
* Returns 0 on success or error code from sysfs_create_group on failure.
*/
int sysfs_create_groups(struct kobject *kobj,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
return internal_create_groups(kobj, 0, groups);
}
@@ -268,7 +268,7 @@ EXPORT_SYMBOL_GPL(sysfs_create_groups);
* Returns 0 on success or error code from sysfs_update_group on failure.
*/
int sysfs_update_groups(struct kobject *kobj,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
return internal_create_groups(kobj, 1, groups);
}
@@ -342,7 +342,7 @@ EXPORT_SYMBOL_GPL(sysfs_remove_group);
* If groups is not NULL, remove the specified groups from the kobject.
*/
void sysfs_remove_groups(struct kobject *kobj,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
int i;
@@ -613,7 +613,7 @@ EXPORT_SYMBOL_GPL(sysfs_group_change_owner);
* Returns 0 on success or error code on failure.
*/
int sysfs_groups_change_owner(struct kobject *kobj,
- const struct attribute_group **groups,
+ const struct attribute_group *const *groups,
kuid_t kuid, kgid_t kgid)
{
int error = 0, i;
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index c33a96b7391..445869ce0f4 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -445,15 +445,15 @@ void sysfs_delete_link(struct kobject *dir, struct kobject *targ,
int __must_check sysfs_create_group(struct kobject *kobj,
const struct attribute_group *grp);
int __must_check sysfs_create_groups(struct kobject *kobj,
- const struct attribute_group **groups);
+ const struct attribute_group *const *groups);
int __must_check sysfs_update_groups(struct kobject *kobj,
- const struct attribute_group **groups);
+ const struct attribute_group *const *groups);
int sysfs_update_group(struct kobject *kobj,
const struct attribute_group *grp);
void sysfs_remove_group(struct kobject *kobj,
const struct attribute_group *grp);
void sysfs_remove_groups(struct kobject *kobj,
- const struct attribute_group **groups);
+ const struct attribute_group *const *groups);
int sysfs_add_file_to_group(struct kobject *kobj,
const struct attribute *attr, const char *group);
void sysfs_remove_file_from_group(struct kobject *kobj,
@@ -486,7 +486,7 @@ int sysfs_change_owner(struct kobject *kobj, kuid_t kuid, kgid_t kgid);
int sysfs_link_change_owner(struct kobject *kobj, struct kobject *targ,
const char *name, kuid_t kuid, kgid_t kgid);
int sysfs_groups_change_owner(struct kobject *kobj,
- const struct attribute_group **groups,
+ const struct attribute_group *const *groups,
kuid_t kuid, kgid_t kgid);
int sysfs_group_change_owner(struct kobject *kobj,
const struct attribute_group *groups, kuid_t kuid,
@@ -629,13 +629,13 @@ static inline int sysfs_create_group(struct kobject *kobj,
}
static inline int sysfs_create_groups(struct kobject *kobj,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
return 0;
}
static inline int sysfs_update_groups(struct kobject *kobj,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
return 0;
}
@@ -652,7 +652,7 @@ static inline void sysfs_remove_group(struct kobject *kobj,
}
static inline void sysfs_remove_groups(struct kobject *kobj,
- const struct attribute_group **groups)
+ const struct attribute_group *const *groups)
{
}
@@ -733,7 +733,7 @@ static inline int sysfs_change_owner(struct kobject *kobj, kuid_t kuid, kgid_t k
}
static inline int sysfs_groups_change_owner(struct kobject *kobj,
- const struct attribute_group **groups,
+ const struct attribute_group *const *groups,
kuid_t kuid, kgid_t kgid)
{
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 02/10] rtc: prepare for struct device member groups becoming a constant array
From: Heiner Kallweit @ 2026-02-17 22:26 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
This prepares for making struct device member groups a constant array.
The assignment groups = rtc->dev.groups would result in a "discarding
const qualifier" warning with this change.
No functional change intended.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/rtc/sysfs.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/sysfs.c b/drivers/rtc/sysfs.c
index 4ab05e105a7..ae5e1252b4c 100644
--- a/drivers/rtc/sysfs.c
+++ b/drivers/rtc/sysfs.c
@@ -308,7 +308,7 @@ const struct attribute_group **rtc_get_dev_attribute_groups(void)
int rtc_add_groups(struct rtc_device *rtc, const struct attribute_group **grps)
{
size_t old_cnt = 0, add_cnt = 0, new_cnt;
- const struct attribute_group **groups, **old;
+ const struct attribute_group **groups, *const *old;
if (grps) {
for (groups = grps; *groups; groups++)
@@ -320,9 +320,9 @@ int rtc_add_groups(struct rtc_device *rtc, const struct attribute_group **grps)
return -EINVAL;
}
- groups = rtc->dev.groups;
- if (groups)
- for (; *groups; groups++)
+ old = rtc->dev.groups;
+ if (old)
+ while (*old++)
old_cnt++;
new_cnt = old_cnt + add_cnt + 1;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 01/10] IB/core: Prepare for immutable device groups
From: Heiner Kallweit @ 2026-02-17 22:25 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
In-Reply-To: <5d0951ec-42c9-453f-9966-ecca593c4153@kernel.org>
This prepares for making struct device member groups a constant array.
No functional change intended.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/infiniband/core/device.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 1174ab7da62..f967ad534fc 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -565,15 +565,14 @@ static void rdma_init_coredev(struct ib_core_device *coredev,
*/
BUILD_BUG_ON(offsetof(struct ib_device, coredev.dev) !=
offsetof(struct ib_device, dev));
-
- coredev->dev.class = &ib_class;
- coredev->dev.groups = dev->groups;
-
/*
* Don't expose hw counters outside of the init namespace.
*/
if (!is_full_dev && dev->hw_stats_attr_index)
- coredev->dev.groups[dev->hw_stats_attr_index] = NULL;
+ dev->groups[dev->hw_stats_attr_index] = NULL;
+
+ coredev->dev.class = &ib_class;
+ coredev->dev.groups = dev->groups;
device_initialize(&coredev->dev);
coredev->owner = dev;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC 00/10] driver core: constify groups arrays in several structs
From: Heiner Kallweit @ 2026-02-17 22:24 UTC (permalink / raw)
To: Thomas Weißschuh, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Jason Gunthorpe, Leon Romanovsky,
Alexandre Belloni
Cc: driver-core, Linux Kernel Mailing List, linux-rdma, linux-rtc
This series constifies the attribute group groups arrays in a number
of structs, plus some preparation work. This allows to assign constant
arrays, w/o "discards const qualifier" compiler warning.
This is a step towards to goal to e.g. create constant arrays in macro
__ATTRIBUTE_GROUPS().
There may be drivers not covered by my test scenarios which conflict
with this series. Therefore I send it as RFC for now.
Hopefully some CI checking this series provides additional hints.
Heiner Kallweit (10):
IB/core: Prepare for immutable device groups
rtc: prepare for struct device member groups becoming a constant array
sysfs: constify group arrays in function arguments
driver: core: constify groups array argument in device_add_groups and
device_remove_groups
driver core: make struct device member groups a constant array
driver core: make struct device_type member groups a constant array
driver core: make struct bus_type groups members constant arrays
driver core: make struct class groups members constant arrays
driver core: make struct device_driver groups members contact arrays
kobject: make struct kobject member default_groups a constant array
drivers/base/base.h | 6 ++++--
drivers/base/core.c | 5 +++--
drivers/base/driver.c | 4 ++--
drivers/infiniband/core/device.c | 9 ++++-----
drivers/rtc/sysfs.c | 8 ++++----
fs/sysfs/group.c | 10 +++++-----
include/linux/device.h | 8 ++++----
include/linux/device/bus.h | 6 +++---
include/linux/device/class.h | 4 ++--
include/linux/device/driver.h | 4 ++--
include/linux/kobject.h | 2 +-
include/linux/sysfs.h | 16 ++++++++--------
12 files changed, 42 insertions(+), 40 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: mfd: maxim,max77686: document optional RTC address
From: Krzysztof Kozlowski @ 2026-02-12 11:27 UTC (permalink / raw)
To: Svyatoslav Ryhel, Chanwoo Choi, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <8E149750-19F1-4274-BD24-B13ED47D1D51@gmail.com>
On 12/02/2026 09:08, Svyatoslav Ryhel wrote:
>
>
> 12 лютого 2026 р. 09:26:33 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише:
>> On 11/02/2026 19:49, Svyatoslav Ryhel wrote:
>>> Document an optional second I2C address for the PMIC's RTC device, to be
>>> used if the RTC is located at a non-default I2C address
>>
>> MAX77686 did not allow changing the I2C address and there are no other
>> devices in the bindings.
>>
>
> That is true, MAX77663 RTC does this, should I adjust Documentation/devicetree/bindings/mfd/max77620.txt instead?
I don't know which binding you should update instead, but I know that it
must not be max77686. Please update the binding for the device you are
actually changing, not some other devices.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: mfd: maxim,max77686: document optional RTC address
From: Svyatoslav Ryhel @ 2026-02-12 8:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, Chanwoo Choi, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <a58587d3-65ec-4d40-aab9-dca08278c2f2@kernel.org>
12 лютого 2026 р. 09:26:33 GMT+02:00, Krzysztof Kozlowski <krzk@kernel.org> пише:
>On 11/02/2026 19:49, Svyatoslav Ryhel wrote:
>> Document an optional second I2C address for the PMIC's RTC device, to be
>> used if the RTC is located at a non-default I2C address
>
>MAX77686 did not allow changing the I2C address and there are no other
>devices in the bindings.
>
That is true, MAX77663 RTC does this, should I adjust Documentation/devicetree/bindings/mfd/max77620.txt instead?
>
>Best regards,
>Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: mfd: maxim,max77686: document optional RTC address
From: Krzysztof Kozlowski @ 2026-02-12 7:26 UTC (permalink / raw)
To: Svyatoslav Ryhel, Chanwoo Choi, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <20260211184941.6756-2-clamor95@gmail.com>
On 11/02/2026 19:49, Svyatoslav Ryhel wrote:
> Document an optional second I2C address for the PMIC's RTC device, to be
> used if the RTC is located at a non-default I2C address
MAX77686 did not allow changing the I2C address and there are no other
devices in the bindings.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1 2/2] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-02-11 18:49 UTC (permalink / raw)
To: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <20260211184941.6756-1-clamor95@gmail.com>
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/rtc/rtc-max77686.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 69ea3ce75b5a..3cdfd78a07cc 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -686,6 +686,11 @@ static int max77686_rtc_init_reg(struct max77686_rtc_info *info)
return ret;
}
+static void max77686_rtc_release_dev(void *client)
+{
+ i2c_unregister_device(client);
+}
+
static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
{
struct device *parent = info->dev->parent;
@@ -713,12 +718,17 @@ static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
goto add_rtc_irq;
}
- client = devm_i2c_new_dummy_device(info->dev, parent_i2c->adapter,
- info->drv_data->rtc_i2c_addr);
+ client = i2c_new_ancillary_device(parent_i2c, "rtc",
+ info->drv_data->rtc_i2c_addr);
if (IS_ERR(client))
return dev_err_probe(info->dev, PTR_ERR(client),
"Failed to allocate I2C device for RTC\n");
+ ret = devm_add_action_or_reset(info->dev, max77686_rtc_release_dev,
+ client);
+ if (ret)
+ return ret;
+
info->rtc_regmap = devm_regmap_init_i2c(client,
info->drv_data->regmap_config);
if (IS_ERR(info->rtc_regmap))
--
2.51.0
^ permalink raw reply related
* [PATCH v1 1/2] dt-bindings: mfd: maxim,max77686: document optional RTC address
From: Svyatoslav Ryhel @ 2026-02-11 18:49 UTC (permalink / raw)
To: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <20260211184941.6756-1-clamor95@gmail.com>
Document an optional second I2C address for the PMIC's RTC device, to be
used if the RTC is located at a non-default I2C address
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../devicetree/bindings/mfd/maxim,max77686.yaml | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
index c13d51e462ba..2d4aad8feaeb 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
@@ -32,7 +32,17 @@ properties:
maxItems: 1
reg:
- maxItems: 1
+ description:
+ Can contain an optional second I2C address pointing to the PMIC's
+ RTC device. If no RTC address is provided, a default address specific
+ to this PMIC will be used.
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pmic
+ - const: rtc
voltage-regulators:
$ref: /schemas/regulator/maxim,max77686.yaml
@@ -59,7 +69,8 @@ examples:
max77686: pmic@9 {
compatible = "maxim,max77686";
- reg = <0x09>;
+ reg = <0x09>, <0x06>;
+ reg-names = "pmic", "rtc";
interrupt-parent = <&gpx0>;
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/2] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-02-11 18:49 UTC (permalink / raw)
To: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
I have tested this patch on LG Optimus Vu P895 with max77663 PMIC and
non-default RTC position. RTC is registered correctly.
Svyatoslav Ryhel (2):
dt-bindings: mfd: maxim,max77686: document optional RTC address
rtc: max77686: convert to i2c_new_ancillary_device
.../devicetree/bindings/mfd/maxim,max77686.yaml | 15 +++++++++++++--
drivers/rtc/rtc-max77686.c | 14 ++++++++++++--
2 files changed, 25 insertions(+), 4 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Kaustabh Chakraborty @ 2026-02-10 18:37 UTC (permalink / raw)
To: André Draszik, Kaustabh Chakraborty, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Sebastian Reichel, Krzysztof Kozlowski,
Alexandre Belloni, Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <9dad174d88c814d3ad2086a31e8dfc222fd431e4.camel@linaro.org>
On 2026-02-10 10:03 +00:00, André Draszik wrote:
> On Thu, 2026-02-05 at 21:46 +0530, Kaustabh Chakraborty wrote:
>> On 2026-02-04 16:55 +00:00, André Draszik wrote:
>> > Hi,
>> >
>> > On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
>> > > Add support for flash LEDs found in certain Samsung S2M series PMICs.
>> > > The device has two channels for LEDs, typically for the back and front
>> > > cameras in mobile devices. Both channels can be independently
>> > > controlled, and can be operated in torch or flash modes.
>> > >
>> > > The driver includes initial support for the S2MU005 PMIC flash LEDs.
>> > >
>> > > Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> > > ---
>> > > drivers/leds/flash/Kconfig | 12 ++
>> > > drivers/leds/flash/Makefile | 1 +
>> > > drivers/leds/flash/leds-s2m-flash.c | 410 ++++++++++++++++++++++++++++++++++++
>> > > 3 files changed, 423 insertions(+)
>> > >
>> > > diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
>> > > index 5e08102a67841..be62e05277429 100644
>> > > --- a/drivers/leds/flash/Kconfig
>> > > +++ b/drivers/leds/flash/Kconfig
>> > > @@ -114,6 +114,18 @@ config LEDS_RT8515
>> > > To compile this driver as a module, choose M here: the module
>> > > will be called leds-rt8515.
>> > >
>> > > +config LEDS_S2M_FLASH
>> > > + tristate "Samsung S2M series PMICs flash/torch LED support"
>> > > + depends on LEDS_CLASS
>> > > + depends on MFD_SEC_CORE
>> > > + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
>> > > + select REGMAP_IRQ
>> > > + help
>> > > + This option enables support for the flash/torch LEDs found in
>> > > + certain Samsung S2M series PMICs, such as the S2MU005. It has
>> > > + a LED channel dedicated for every physical LED. The LEDs can
>> > > + be controlled in flash and torch modes.
>> > > +
>> > > config LEDS_SGM3140
>> > > tristate "LED support for the SGM3140"
>> > > depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
>> > > diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
>> > > index 712fb737a428e..44e6c1b4beb37 100644
>> > > --- a/drivers/leds/flash/Makefile
>> > > +++ b/drivers/leds/flash/Makefile
>> > > @@ -10,6 +10,7 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
>> > > obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
>> > > obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
>> > > obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
>> > > +obj-$(CONFIG_LEDS_S2M_FLASH) += leds-s2m-flash.o
>> > > obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
>> > > obj-$(CONFIG_LEDS_SY7802) += leds-sy7802.o
>> > > obj-$(CONFIG_LEDS_TPS6131X) += leds-tps6131x.o
>> > > diff --git a/drivers/leds/flash/leds-s2m-flash.c b/drivers/leds/flash/leds-s2m-flash.c
>> > > new file mode 100644
>> > > index 0000000000000..1be2745c475bf
>> > > --- /dev/null
>> > > +++ b/drivers/leds/flash/leds-s2m-flash.c
>> > > @@ -0,0 +1,410 @@
>> > > +// SPDX-License-Identifier: GPL-2.0
>> > > +/*
>> > > + * Flash and Torch LED Driver for Samsung S2M series PMICs.
>> > > + *
>> > > + * Copyright (c) 2015 Samsung Electronics Co., Ltd
>> > > + * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
>> > > + */
>> > > +
>> > > +#include <linux/container_of.h>
>> > > +#include <linux/led-class-flash.h>
>> > > +#include <linux/mfd/samsung/core.h>
>> > > +#include <linux/mfd/samsung/s2mu005.h>
>> > > +#include <linux/module.h>
>> > > +#include <linux/of.h>
>> > > +#include <linux/platform_device.h>
>> > > +#include <linux/regmap.h>
>> > > +#include <media/v4l2-flash-led-class.h>
>> > > +
>> > > +#define MAX_CHANNELS 2
>> > > +
>> > > +struct s2m_fled {
>> > > + struct device *dev;
>> > > + struct regmap *regmap;
>> > > + struct led_classdev_flash cdev;
>> > > + struct v4l2_flash *v4l2_flash;
>> > > + struct mutex lock;
>> >
>> > Please add a (brief) comment describing what the mutex protects.
>>
>> The mutex object prevents the concurrent access of flash control
>> registers by the LED and V4L2 subsystems. -- will add this.
>>
>> > > +
>> > > + /*
>> > > + * Get the LED enable register address. Revision EVT0 has the
>> > > + * register at CTRL4, while EVT1 and higher have it at CTRL6.
>> > > + */
>> > > + if (priv->pmic_revision == 0)
>> > > + reg_enable = S2MU005_REG_FLED_CTRL4;
>> > > + else
>> > > + reg_enable = S2MU005_REG_FLED_CTRL6;
>> >
>> > You could REG_FIELD() and friends for this and everywhere else with
>> > similar if / else.
>> >
>>
>> REG_FIELD(), from what I understood, is for selecting a bit field inside
>> a single register. However this code chooses between two separate
>> registers. I believe your interpretation was incorrect? Please clarify.
>
> The first argument to REG_FIELD is the register itself, so reg fields can
> be used to describe this difference. See e.g. drivers/leds/rgb/leds-mt6370-rgb.c
> Of course, you could have a member variable instead to hold the register
> index if all bits are the same in both revisions. Either way would avoid
> having to constantly check the revision during runtime.
Wow, this is a great way of abstraction, thanks. I will try to implement
this in all drivers, let's see.
>
> Cheers,
> Andre'
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Thomas Bogendoerfer @ 2026-02-10 15:50 UTC (permalink / raw)
To: Brian Masney
Cc: Claudiu Beznea, linux-mips, linux-kernel, Michael Turquette,
Stephen Boyd, linux-clk, Thomas Gleixner, Adrian Hunter,
Ulf Hansson, linux-mmc, Linus Walleij, linux-gpio,
Alexandre Belloni, linux-rtc, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Guenter Roeck, Wim Van Sebroeck, linux-watchdog,
Lukas Bulwahn
In-Reply-To: <aYsnsecPa8bWMbaA@redhat.com>
On Tue, Feb 10, 2026 at 07:42:25AM -0500, Brian Masney wrote:
> Hi Thomas,
>
> On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> > There are currently some pic32 MIPS drivers that are in tree, and are
> > only configured to be compiled on the MIPS pic32 platform. There's a
> > risk of breaking some of these drivers when migrating drivers away from
> > legacy APIs. It happened to me with a pic32 clk driver.
> >
> > Let's go ahead and move the pic32.h from the asm to the platform_data
> > include directory in the tree. This will make it easier, and cleaner to
> > enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> > updating some includes, which I do at the beginning of this series.
> >
> > This series was compile tested on a centos-stream-10 arm64 host in two
> > different configurations:
> >
> > - native arm64 build with COMPILE_TEST (via make allmodconfig)
> > - MIPS cross compile on arm64 with:
> > ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
> >
> > Note that there is a separate MIPS compile error in linux-next, and I
> > reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
> >
> > I included a patch at the end that shows enabling COMPILE_TEST for a
> > pic32 clk driver.
> >
> > Merge Strategy
> > ==============
> > - Patches 1-15 can go through the MIPS tree.
> > - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> > tree after the next merge window. There is a separate patch set that
> > fixes a compiler error I unintentionally introduced via the clk tree.
> > https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
>
> Sorry about the duplicate message. I just wanted to reply to the series
> with MIPS in the header so this message isn't lost.
>
> Can you back out these two patches from your tree in linux-next, and not
> send these to Linus?
>
> clk: microchip: core: allow driver to be compiled with COMPILE_TEST
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=026d70dcfe5de1543bb8edb8e50d22dc16863e6b
>
> clk: microchip: fix typo in reference to a config option
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a6ab150deb4b740334721d18e02ad400a9d888f5
I've reverted both patches in mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Brian Masney @ 2026-02-10 12:42 UTC (permalink / raw)
To: Thomas Bogendoerfer, Claudiu Beznea
Cc: linux-mips, linux-kernel, Michael Turquette, Stephen Boyd,
linux-clk, Thomas Gleixner, Adrian Hunter, Ulf Hansson, linux-mmc,
Linus Walleij, linux-gpio, Alexandre Belloni, linux-rtc,
Greg Kroah-Hartman, Jiri Slaby, linux-serial, Guenter Roeck,
Wim Van Sebroeck, linux-watchdog, Lukas Bulwahn
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>
Hi Thomas,
On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> There are currently some pic32 MIPS drivers that are in tree, and are
> only configured to be compiled on the MIPS pic32 platform. There's a
> risk of breaking some of these drivers when migrating drivers away from
> legacy APIs. It happened to me with a pic32 clk driver.
>
> Let's go ahead and move the pic32.h from the asm to the platform_data
> include directory in the tree. This will make it easier, and cleaner to
> enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> updating some includes, which I do at the beginning of this series.
>
> This series was compile tested on a centos-stream-10 arm64 host in two
> different configurations:
>
> - native arm64 build with COMPILE_TEST (via make allmodconfig)
> - MIPS cross compile on arm64 with:
> ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
>
> Note that there is a separate MIPS compile error in linux-next, and I
> reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
>
> I included a patch at the end that shows enabling COMPILE_TEST for a
> pic32 clk driver.
>
> Merge Strategy
> ==============
> - Patches 1-15 can go through the MIPS tree.
> - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> tree after the next merge window. There is a separate patch set that
> fixes a compiler error I unintentionally introduced via the clk tree.
> https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
Sorry about the duplicate message. I just wanted to reply to the series
with MIPS in the header so this message isn't lost.
Can you back out these two patches from your tree in linux-next, and not
send these to Linus?
clk: microchip: core: allow driver to be compiled with COMPILE_TEST
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=026d70dcfe5de1543bb8edb8e50d22dc16863e6b
clk: microchip: fix typo in reference to a config option
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a6ab150deb4b740334721d18e02ad400a9d888f5
See
https://lore.kernel.org/oe-kbuild-all/202602100954.BAVYq6aC-lkp@intel.com/
All of the other patches with the include changes are good. I have
patches queued to send out in two weeks to other subsystems once the
include changes land in Linus's tree.
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: André Draszik @ 2026-02-10 10:03 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <DG75VP6IIUXD.1VA6YSMNTPJQ6@disroot.org>
On Thu, 2026-02-05 at 21:46 +0530, Kaustabh Chakraborty wrote:
> On 2026-02-04 16:55 +00:00, André Draszik wrote:
> > Hi,
> >
> > On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
> > > Add support for flash LEDs found in certain Samsung S2M series PMICs.
> > > The device has two channels for LEDs, typically for the back and front
> > > cameras in mobile devices. Both channels can be independently
> > > controlled, and can be operated in torch or flash modes.
> > >
> > > The driver includes initial support for the S2MU005 PMIC flash LEDs.
> > >
> > > Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> > > ---
> > > drivers/leds/flash/Kconfig | 12 ++
> > > drivers/leds/flash/Makefile | 1 +
> > > drivers/leds/flash/leds-s2m-flash.c | 410 ++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 423 insertions(+)
> > >
> > > diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
> > > index 5e08102a67841..be62e05277429 100644
> > > --- a/drivers/leds/flash/Kconfig
> > > +++ b/drivers/leds/flash/Kconfig
> > > @@ -114,6 +114,18 @@ config LEDS_RT8515
> > > To compile this driver as a module, choose M here: the module
> > > will be called leds-rt8515.
> > >
> > > +config LEDS_S2M_FLASH
> > > + tristate "Samsung S2M series PMICs flash/torch LED support"
> > > + depends on LEDS_CLASS
> > > + depends on MFD_SEC_CORE
> > > + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> > > + select REGMAP_IRQ
> > > + help
> > > + This option enables support for the flash/torch LEDs found in
> > > + certain Samsung S2M series PMICs, such as the S2MU005. It has
> > > + a LED channel dedicated for every physical LED. The LEDs can
> > > + be controlled in flash and torch modes.
> > > +
> > > config LEDS_SGM3140
> > > tristate "LED support for the SGM3140"
> > > depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> > > diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
> > > index 712fb737a428e..44e6c1b4beb37 100644
> > > --- a/drivers/leds/flash/Makefile
> > > +++ b/drivers/leds/flash/Makefile
> > > @@ -10,6 +10,7 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
> > > obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
> > > obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
> > > obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
> > > +obj-$(CONFIG_LEDS_S2M_FLASH) += leds-s2m-flash.o
> > > obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
> > > obj-$(CONFIG_LEDS_SY7802) += leds-sy7802.o
> > > obj-$(CONFIG_LEDS_TPS6131X) += leds-tps6131x.o
> > > diff --git a/drivers/leds/flash/leds-s2m-flash.c b/drivers/leds/flash/leds-s2m-flash.c
> > > new file mode 100644
> > > index 0000000000000..1be2745c475bf
> > > --- /dev/null
> > > +++ b/drivers/leds/flash/leds-s2m-flash.c
> > > @@ -0,0 +1,410 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Flash and Torch LED Driver for Samsung S2M series PMICs.
> > > + *
> > > + * Copyright (c) 2015 Samsung Electronics Co., Ltd
> > > + * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
> > > + */
> > > +
> > > +#include <linux/container_of.h>
> > > +#include <linux/led-class-flash.h>
> > > +#include <linux/mfd/samsung/core.h>
> > > +#include <linux/mfd/samsung/s2mu005.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/regmap.h>
> > > +#include <media/v4l2-flash-led-class.h>
> > > +
> > > +#define MAX_CHANNELS 2
> > > +
> > > +struct s2m_fled {
> > > + struct device *dev;
> > > + struct regmap *regmap;
> > > + struct led_classdev_flash cdev;
> > > + struct v4l2_flash *v4l2_flash;
> > > + struct mutex lock;
> >
> > Please add a (brief) comment describing what the mutex protects.
>
> The mutex object prevents the concurrent access of flash control
> registers by the LED and V4L2 subsystems. -- will add this.
>
> > > +
> > > + /*
> > > + * Get the LED enable register address. Revision EVT0 has the
> > > + * register at CTRL4, while EVT1 and higher have it at CTRL6.
> > > + */
> > > + if (priv->pmic_revision == 0)
> > > + reg_enable = S2MU005_REG_FLED_CTRL4;
> > > + else
> > > + reg_enable = S2MU005_REG_FLED_CTRL6;
> >
> > You could REG_FIELD() and friends for this and everywhere else with
> > similar if / else.
> >
>
> REG_FIELD(), from what I understood, is for selecting a bit field inside
> a single register. However this code chooses between two separate
> registers. I believe your interpretation was incorrect? Please clarify.
The first argument to REG_FIELD is the register itself, so reg fields can
be used to describe this difference. See e.g. drivers/leds/rgb/leds-mt6370-rgb.c
Of course, you could have a member variable instead to hold the register
index if all bits are the same in both revisions. Either way would avoid
having to constantly check the revision during runtime.
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
From: André Draszik @ 2026-02-10 9:55 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <DG74Y3QSCLIO.32Q8ZKCTISXXB@disroot.org>
On Thu, 2026-02-05 at 21:02 +0530, Kaustabh Chakraborty wrote:
> On 2026-02-04 15:23 +00:00, André Draszik wrote:
> > Hi,
> >
> > On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
> > > Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
> > > USB Interface Controller), and flash and RGB LED controllers.
> > >
> > > S2MU005's interrupt registers can be properly divided into three regmap
> > > IRQ chips, one each for the charger, flash LEDs, and the MUIC.
> > >
> > > Add initial support for S2MU005 in the PMIC driver, along with it's three
> > > interrupt chips.
> > >
> > > Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> > > ---
> > > drivers/mfd/sec-common.c | 16 ++
> > > drivers/mfd/sec-i2c.c | 12 ++
> > > drivers/mfd/sec-irq.c | 74 ++++++++
> > > include/linux/mfd/samsung/core.h | 1 +
> > > include/linux/mfd/samsung/irq.h | 66 ++++++++
> > > include/linux/mfd/samsung/s2mu005.h | 328 ++++++++++++++++++++++++++++++++++++
> > > 6 files changed, 497 insertions(+)
> > >
>
> [...]
>
> > > diff --git a/drivers/mfd/sec-i2c.c b/drivers/mfd/sec-i2c.c
> > > index 3132b849b4bc4..3f1d70cc3292b 100644
> > > --- a/drivers/mfd/sec-i2c.c
> > > +++ b/drivers/mfd/sec-i2c.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/mfd/samsung/s2mps14.h>
> > > #include <linux/mfd/samsung/s2mps15.h>
> > > #include <linux/mfd/samsung/s2mpu02.h>
> > > +#include <linux/mfd/samsung/s2mu005.h>
> > > #include <linux/mfd/samsung/s5m8767.h>
> > > #include <linux/mod_devicetable.h>
> > > #include <linux/module.h>
> > > @@ -130,6 +131,11 @@ static const struct regmap_config s2mpu05_regmap_config = {
> > > .val_bits = 8,
> > > };
> > >
> > > +static const struct regmap_config s2mu005_regmap_config = {
> > > + .reg_bits = 8,
> > > + .val_bits = 8,
> > > +};
> >
> > No cache? And what is the .max_register value?
> >
>
> This was in the previous revision, but I ended up removing it because
> (at least I thought at that time) interfered with interrupts firing in
> some way. The actual issue was unrelated, so I will add it back.
>
> However, there is also another thing I see in logs:
>
> sec-pmic-i2c 2-003d: using zero-initialized flat cache, this may cause unexpected behavior
>
> This is due to REGCACHE_FLAT, I am not sure if I should just ignore
> this.
I think the error might be because you should also specify num_reg_defaults_raw:
.max_register = xxx,
.num_reg_defaults_raw = xxx + 1,
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH 1/3] optee: simplify OP-TEE context match
From: Sumit Garg @ 2026-02-10 5:22 UTC (permalink / raw)
To: rouven.czerwinski
Cc: Jens Wiklander, Olivia Mackall, Herbert Xu,
Clément Léger, Alexandre Belloni, op-tee, linux-kernel,
linux-crypto, linux-rtc
In-Reply-To: <20260126-optee-simplify-context-match-v1-1-d4104e526cb6@linaro.org>
On Mon, Jan 26, 2026 at 11:11:24AM +0100, Rouven Czerwinski via B4 Relay wrote:
> From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
>
> Simplify the TEE implementor ID match by returning the boolean
> expression directly instead of going through an if/else.
>
> Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> ---
> drivers/tee/optee/device.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> index 950b4661d5df..4c85b04d6004 100644
> --- a/drivers/tee/optee/device.c
> +++ b/drivers/tee/optee/device.c
> @@ -13,10 +13,7 @@
>
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> {
> - if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> - return 1;
> - else
> - return 0;
> + return (ver->impl_id == TEE_IMPL_ID_OPTEE);
> }
>
> static int get_devices(struct tee_context *ctx, u32 session,
>
> --
> 2.52.0
>
>
>
^ permalink raw reply
* [PATCH] rtc: ds1390: fix number of bytes read from RTC
From: Andreas Gabriel-Platschek @ 2026-02-09 5:34 UTC (permalink / raw)
To: alexandre.belloni; +Cc: linux-rtc, linux-kernel, Andreas Gabriel-Platschek
The spi_write_then_read() reads 8 bytes starting from
DS1390_REG_SECONDS (== 0x01), so the last byte read would already
be part of the alarm (Tenths and Hundredths of Seconds) feature.
However 7 bytes are engouh -- seconds (0x01), minutes (0x02), hours (0x03),
day (0x04), date (0x05), month/century (0x06) and year (0x07).
Signed-off-by: Andreas Gabriel-Platschek <andi.platschek@gmail.com>
---
drivers/rtc/rtc-ds1390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1390.c b/drivers/rtc/rtc-ds1390.c
index f46428ca77cc..f7afd6bdeb4a 100644
--- a/drivers/rtc/rtc-ds1390.c
+++ b/drivers/rtc/rtc-ds1390.c
@@ -134,7 +134,7 @@ static int ds1390_read_time(struct device *dev, struct rtc_time *dt)
chip->txrx_buf[0] = DS1390_REG_SECONDS;
/* do the i/o */
- status = spi_write_then_read(spi, chip->txrx_buf, 1, chip->txrx_buf, 8);
+ status = spi_write_then_read(spi, chip->txrx_buf, 1, chip->txrx_buf, 7);
if (status != 0)
return status;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Jacek Anaszewski @ 2026-02-08 13:05 UTC (permalink / raw)
To: Kaustabh Chakraborty, Rob Herring
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DG7XJ6T9I7HU.1UVHH2QWX31O1@disroot.org>
Hi Kaustabh,
On 2/6/26 14:56, Kaustabh Chakraborty wrote:
> On 2026-02-06 07:38 -06:00, Rob Herring wrote:
>> On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
>>> Certain Samsung S2M series PMICs have a three-channel LED device with
>>> independent brightness control for each channel, typically used as
>>> status indicators in mobile phones. Document the devicetree schema from
>>> this device.
>>>
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> new file mode 100644
>>> index 0000000000000..6806b6d869ff7
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> @@ -0,0 +1,34 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: RGB LED Controller for Samsung S2M series PMICs
>>> +
>>> +maintainers:
>>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>>> +
>>> +description: |
>>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>>> + 8-bit brightness control for each channel, typically used as status
>>> + indicators in mobile phones.
>>> +
>>> + This is a part of device tree bindings for S2M and S5M family of Power
>>> + Management IC (PMIC).
>>> +
>>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>>> + additional information and example.
>>> +
>>> +allOf:
>>> + - $ref: common.yaml#
>>
>> This looks a bit lacking. Don't you need 3 child nodes for each or
>> reference to the multi-color schema?
>
> rgb {
> compatible = "samsung,s2mu005-rgb";
> label = "notification:rgb:indicator";
> color = <LED_COLOR_ID_RGB>;
> function = LED_FUNCTION_INDICATOR;
> linux,default-trigger = "pattern";
> };
Having label together with color and function doesn't make sense.
Please read label documentation in [0].
[0] Documentation/devicetree/bindings/leds/common.yaml
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-02-06 14:03 UTC (permalink / raw)
To: Kaustabh Chakraborty, Rob Herring
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DG7XJ6T9I7HU.1UVHH2QWX31O1@disroot.org>
On 2026-02-06 19:26 +05:30, Kaustabh Chakraborty wrote:
> On 2026-02-06 07:38 -06:00, Rob Herring wrote:
>> On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
>>> Certain Samsung S2M series PMICs have a three-channel LED device with
>>> independent brightness control for each channel, typically used as
>>> status indicators in mobile phones. Document the devicetree schema from
>>> this device.
>>>
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> new file mode 100644
>>> index 0000000000000..6806b6d869ff7
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> @@ -0,0 +1,34 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: RGB LED Controller for Samsung S2M series PMICs
>>> +
>>> +maintainers:
>>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>>> +
>>> +description: |
>>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>>> + 8-bit brightness control for each channel, typically used as status
>>> + indicators in mobile phones.
>>> +
>>> + This is a part of device tree bindings for S2M and S5M family of Power
>>> + Management IC (PMIC).
>>> +
>>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>>> + additional information and example.
>>> +
>>> +allOf:
>>> + - $ref: common.yaml#
>>
>> This looks a bit lacking. Don't you need 3 child nodes for each or
>> reference to the multi-color schema?
>
> rgb {
> compatible = "samsung,s2mu005-rgb";
> label = "notification:rgb:indicator";
> color = <LED_COLOR_ID_RGB>;
> function = LED_FUNCTION_INDICATOR;
> linux,default-trigger = "pattern";
> };
>
Message got deleted somehow? Anyways, the device has three channels but
a single LED, but is controlled by a single driver interface only. The
channels are not independent.
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - samsung,s2mu005-rgb
>>> +
>>> +required:
>>> + - compatible
>>> +
>>> +unevaluatedProperties: false
>>>
>>> --
>>> 2.52.0
>>>
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-02-06 13:56 UTC (permalink / raw)
To: Rob Herring, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260206133837.GA157817-robh@kernel.org>
On 2026-02-06 07:38 -06:00, Rob Herring wrote:
> On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
>> Certain Samsung S2M series PMICs have a three-channel LED device with
>> independent brightness control for each channel, typically used as
>> status indicators in mobile phones. Document the devicetree schema from
>> this device.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>> new file mode 100644
>> index 0000000000000..6806b6d869ff7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>> @@ -0,0 +1,34 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: RGB LED Controller for Samsung S2M series PMICs
>> +
>> +maintainers:
>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>> +
>> +description: |
>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> + 8-bit brightness control for each channel, typically used as status
>> + indicators in mobile phones.
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +allOf:
>> + - $ref: common.yaml#
>
> This looks a bit lacking. Don't you need 3 child nodes for each or
> reference to the multi-color schema?
rgb {
compatible = "samsung,s2mu005-rgb";
label = "notification:rgb:indicator";
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_INDICATOR;
linux,default-trigger = "pattern";
};
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - samsung,s2mu005-rgb
>> +
>> +required:
>> + - compatible
>> +
>> +unevaluatedProperties: false
>>
>> --
>> 2.52.0
>>
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: extcon: document Samsung S2M series PMIC extcon device
From: Kaustabh Chakraborty @ 2026-02-06 13:52 UTC (permalink / raw)
To: Rob Herring, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260206134915.GA171264-robh@kernel.org>
On 2026-02-06 07:49 -06:00, Rob Herring wrote:
> On Mon, Jan 26, 2026 at 12:37:10AM +0530, Kaustabh Chakraborty wrote:
>> Certain Samsung S2M series PMICs have a MUIC device which reports
>> various cable states by measuring the ID-GND resistance with an internal
>> ADC. Document the devicetree schema for this device.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> .../bindings/extcon/samsung,s2mu005-muic.yaml | 35 ++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
>> new file mode 100644
>> index 0000000000000..05828b7b5be13
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
>> @@ -0,0 +1,35 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/extcon/samsung,s2mu005-muic.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Extcon Device for Samsung S2M series PMICs
>> +
>> +maintainers:
>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>> +
>> +description: |
>> + The Samsung S2M series PMIC extcon device is a USB port accessory
>
> extcon is a Linuxism. Use usb-connector binding.
>
>> + detector. It reports multiple states depending on the ID-GND
>> + resistance measured by an internal ADC.
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - samsung,s2mu005-muic
>> +
>> + port:
>> + $ref: /schemas/graph.yaml#/properties/port
>
> What does the port connect to?
I have it connected to the USB PHY in device tree.
>
>> +
>> +required:
>> + - compatible
>> + - port
>> +
>> +additionalProperties: false
>>
>> --
>> 2.52.0
>>
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: extcon: document Samsung S2M series PMIC extcon device
From: Rob Herring @ 2026-02-06 13:49 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260126-s2mu005-pmic-v2-3-78f1a75f547a@disroot.org>
On Mon, Jan 26, 2026 at 12:37:10AM +0530, Kaustabh Chakraborty wrote:
> Certain Samsung S2M series PMICs have a MUIC device which reports
> various cable states by measuring the ID-GND resistance with an internal
> ADC. Document the devicetree schema for this device.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../bindings/extcon/samsung,s2mu005-muic.yaml | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
> new file mode 100644
> index 0000000000000..05828b7b5be13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
> @@ -0,0 +1,35 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/extcon/samsung,s2mu005-muic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Extcon Device for Samsung S2M series PMICs
> +
> +maintainers:
> + - Kaustabh Chakraborty <kauschluss@disroot.org>
> +
> +description: |
> + The Samsung S2M series PMIC extcon device is a USB port accessory
extcon is a Linuxism. Use usb-connector binding.
> + detector. It reports multiple states depending on the ID-GND
> + resistance measured by an internal ADC.
> +
> + This is a part of device tree bindings for S2M and S5M family of Power
> + Management IC (PMIC).
> +
> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
> + additional information and example.
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,s2mu005-muic
> +
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
What does the port connect to?
> +
> +required:
> + - compatible
> + - port
> +
> +additionalProperties: false
>
> --
> 2.52.0
>
^ 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