Some smart batteries store their manufacture date, which is
useful to identify the battery and/or to know about the cell
quality.
Signed-off-by: Sebastian Reichel <[email protected]>
---
Documentation/ABI/testing/sysfs-class-power | 28 +++++++++++++++++++++
drivers/power/supply/power_supply_sysfs.c | 3 +++
include/linux/power_supply.h | 3 +++
3 files changed, 34 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
index 2f896555ae23..e6d7348766b2 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -680,3 +680,31 @@ Description:
Valid values:
- 1: enabled
- 0: disabled
+
+What: /sys/class/power_supply/<supply_name>/manufacture_year
+Date: January 2020
+Contact: [email protected]
+Description:
+ Reports the year (following Gregorian calendar) when the device has been
+ manufactured.
+
+ Access: Read
+ Valid values: Reported as integer
+
+What: /sys/class/power_supply/<supply_name>/manufacture_month
+Date: January 2020
+Contact: [email protected]
+Description:
+ Reports the month when the device has been manufactured.
+
+ Access: Read
+ Valid values: 1-12
+
+What: /sys/class/power_supply/<supply_name>/manufacture_day
+Date: January 2020
+Contact: [email protected]
+Description:
+ Reports the day of month when the device has been manufactured.
+
+ Access: Read
+ Valid values: 1-31
diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
index e664774a2d1e..78d5382e69f1 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -198,6 +198,9 @@ static struct power_supply_attr power_supply_attrs[] = {
POWER_SUPPLY_ATTR(PRECHARGE_CURRENT),
POWER_SUPPLY_ATTR(CHARGE_TERM_CURRENT),
POWER_SUPPLY_ATTR(CALIBRATE),
+ POWER_SUPPLY_ATTR(MANUFACTURE_YEAR),
+ POWER_SUPPLY_ATTR(MANUFACTURE_MONTH),
+ POWER_SUPPLY_ATTR(MANUFACTURE_DAY),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(MODEL_NAME),
POWER_SUPPLY_ATTR(MANUFACTURER),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 453a85f25635..63ffe2a0a87b 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -159,6 +159,9 @@ enum power_supply_property {
POWER_SUPPLY_PROP_PRECHARGE_CURRENT,
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
POWER_SUPPLY_PROP_CALIBRATE,
+ POWER_SUPPLY_PROP_MANUFACTURE_YEAR,
+ POWER_SUPPLY_PROP_MANUFACTURE_MONTH,
+ POWER_SUPPLY_PROP_MANUFACTURE_DAY,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
--
2.26.2
Hi Sebastian,
On 2020/05/13, Sebastian Reichel wrote:
> Some smart batteries store their manufacture date, which is
> useful to identify the battery and/or to know about the cell
> quality.
>
Have you considered exposing this as a single file? Say following the ISO8601
format - YYYY-MM-DD.
-Emil
Hi,
On Fri, May 15, 2020 at 03:47:32PM +0100, Emil Velikov wrote:
> On 2020/05/13, Sebastian Reichel wrote:
> > Some smart batteries store their manufacture date, which is
> > useful to identify the battery and/or to know about the cell
> > quality.
> >
> Have you considered exposing this as a single file? Say following
> the ISO8601 format - YYYY-MM-DD.
Yes. My initial implementation was exactly that. The thing is, that
I suspect some fuel gauge implementations may only expose the year
or just year + month. I chose 3 files, since receiving 'YYYY-MM'
instead of full ISO code might be more unexpected than not having
the DAY file available. But I don't have a strong opinion on this.
-- Sebastian
On 2020/05/15, Sebastian Reichel wrote:
> Hi,
>
> On Fri, May 15, 2020 at 03:47:32PM +0100, Emil Velikov wrote:
> > On 2020/05/13, Sebastian Reichel wrote:
> > > Some smart batteries store their manufacture date, which is
> > > useful to identify the battery and/or to know about the cell
> > > quality.
> > >
> > Have you considered exposing this as a single file? Say following
> > the ISO8601 format - YYYY-MM-DD.
>
> Yes. My initial implementation was exactly that. The thing is, that
> I suspect some fuel gauge implementations may only expose the year
> or just year + month. I chose 3 files, since receiving 'YYYY-MM'
> instead of full ISO code might be more unexpected than not having
> the DAY file available. But I don't have a strong opinion on this.
>
Fwiw the ISO 8601 allows for YYYY-MM, although you're spot on. Having
the three fields separate makes perfect sense.
Thanks
Emil