Documentation/ABI/testing/sysfs-class-power | 20 ++ .../bindings/connector/usb-connector.yaml | 8 + .../devicetree/bindings/usb/maxim,max33359.yaml | 1 + Documentation/power/power_supply_class.rst | 11 ++ drivers/power/supply/power_supply_core.c | 60 ++++++ drivers/power/supply/power_supply_sysfs.c | 2 + drivers/usb/typec/tcpm/tcpm.c | 217 ++++++++++++++++++++- include/linux/power_supply.h | 7 + include/linux/usb/pd.h | 65 ++++++ 9 files changed, 388 insertions(+), 3 deletions(-)
Support for Battery Status & Battery Caps messages in response to
Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices
powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message
Applicability" section. This patchset adds support for these AMSes
to achieve greater compliance with the spec.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
---
Amit Sunil Dhamne (5):
dt-bindings: connector: add fixed-batteries property
power: supply: core: add function to get supplies from fwnode
usb: typec: tcpm: Add support for Battery Status response message
power: supply: core: add vendor and product id properties
usb: typec: tcpm: Add support for Battery Cap response message
Documentation/ABI/testing/sysfs-class-power | 20 ++
.../bindings/connector/usb-connector.yaml | 8 +
.../devicetree/bindings/usb/maxim,max33359.yaml | 1 +
Documentation/power/power_supply_class.rst | 11 ++
drivers/power/supply/power_supply_core.c | 60 ++++++
drivers/power/supply/power_supply_sysfs.c | 2 +
drivers/usb/typec/tcpm/tcpm.c | 217 ++++++++++++++++++++-
include/linux/power_supply.h | 7 +
include/linux/usb/pd.h | 65 ++++++
9 files changed, 388 insertions(+), 3 deletions(-)
---
base-commit: 80e54e84911a923c40d7bee33a34c1b4be148d7a
change-id: 20250311-batt_ops-be1bd71ca254
Best regards,
--
Amit Sunil Dhamne <amitsd@google.com>
On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: > Support for Battery Status & Battery Caps messages in response to > Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices > powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message > Applicability" section. This patchset adds support for these AMSes > to achieve greater compliance with the spec. Which board uses it? I would be happy to see that connection between batteries and USB connector on the schematics of some real device. How does it look like? Best regards, Krzysztof
Hi Krzysztof, Thanks for the review! On 3/13/25 1:50 AM, Krzysztof Kozlowski wrote: > On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: >> Support for Battery Status & Battery Caps messages in response to >> Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices >> powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message >> Applicability" section. This patchset adds support for these AMSes >> to achieve greater compliance with the spec. > Which board uses it? I would be happy to see that connection between > batteries and USB connector on the schematics of some real device. How > does it look like? Any board that uses a USB Type-C connector that supplies power into or out of a battery while operating in sink or source mode respectively. The VBUS is connected to the (battery + buck boost IC's CHGin/Vin) or a companion IFPMIC connected to a battery. In our board we have USB Connector <-> IFPMIC <-> Battery. Thanks, Amit > Best regards, > Krzysztof >
On 15/03/2025 01:49, Amit Sunil Dhamne wrote: > Hi Krzysztof, > > Thanks for the review! > > On 3/13/25 1:50 AM, Krzysztof Kozlowski wrote: >> On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: >>> Support for Battery Status & Battery Caps messages in response to >>> Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices >>> powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message >>> Applicability" section. This patchset adds support for these AMSes >>> to achieve greater compliance with the spec. >> Which board uses it? I would be happy to see that connection between >> batteries and USB connector on the schematics of some real device. How >> does it look like? > Any board that uses a USB Type-C connector that supplies power into or If you keep responding like this, you will got nowhere, so let me re-iterate: Which upstream DTS (or upstream supported hardware) is going to use this binding, so I can see how you are going to implement it there in the entire system? > out of a battery while operating in sink or source mode respectively. > The VBUS is connected to the (battery + buck boost IC's CHGin/Vin) or a > companion IFPMIC connected to a battery. In our board we have USB > Connector <-> IFPMIC <-> Battery. Which board is that? Best regards, Krzysztof
On 3/16/25 9:52 AM, Krzysztof Kozlowski wrote: > On 15/03/2025 01:49, Amit Sunil Dhamne wrote: >> Hi Krzysztof, >> >> Thanks for the review! >> >> On 3/13/25 1:50 AM, Krzysztof Kozlowski wrote: >>> On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: >>>> Support for Battery Status & Battery Caps messages in response to >>>> Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices >>>> powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message >>>> Applicability" section. This patchset adds support for these AMSes >>>> to achieve greater compliance with the spec. >>> Which board uses it? I would be happy to see that connection between >>> batteries and USB connector on the schematics of some real device. How >>> does it look like? >> Any board that uses a USB Type-C connector that supplies power into or > If you keep responding like this, you will got nowhere, so let me > re-iterate: > > Which upstream DTS (or upstream supported hardware) is going to use this > binding, so I can see how you are going to implement it there in the > entire system? This is for maxim,max33359 Type-C controller. This would property would have been present for the connector present in the typec device for gs101-oriole board (that uses the max33359 controller). However, I will be exploring existing bindings to describe the relationship for now. >> out of a battery while operating in sink or source mode respectively. >> The VBUS is connected to the (battery + buck boost IC's CHGin/Vin) or a >> companion IFPMIC connected to a battery. In our board we have USB >> Connector <-> IFPMIC <-> Battery. > Which board is that? gs101-oriole board. Thanks, Amit > > Best regards, > Krzysztof
On 20/03/2025 22:11, Amit Sunil Dhamne wrote: > On 3/16/25 9:52 AM, Krzysztof Kozlowski wrote: >> On 15/03/2025 01:49, Amit Sunil Dhamne wrote: >>> Hi Krzysztof, >>> >>> Thanks for the review! >>> >>> On 3/13/25 1:50 AM, Krzysztof Kozlowski wrote: >>>> On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: >>>>> Support for Battery Status & Battery Caps messages in response to >>>>> Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices >>>>> powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message >>>>> Applicability" section. This patchset adds support for these AMSes >>>>> to achieve greater compliance with the spec. >>>> Which board uses it? I would be happy to see that connection between >>>> batteries and USB connector on the schematics of some real device. How >>>> does it look like? >>> Any board that uses a USB Type-C connector that supplies power into or >> If you keep responding like this, you will got nowhere, so let me >> re-iterate: >> >> Which upstream DTS (or upstream supported hardware) is going to use this >> binding, so I can see how you are going to implement it there in the >> entire system? > > This is for maxim,max33359 Type-C controller. Stop deflecting the questions. max33359 is not a board. I already asked two times. Apparently admitting "no upstream users" is impossible, so let's state the obvious: There are no upstream users of this. > > This would property would have been present for the connector present in > the typec device for gs101-oriole board (that uses the max33359 > controller). But it is not. > > However, I will be exploring existing bindings to describe the > relationship for now. > >>> out of a battery while operating in sink or source mode respectively. >>> The VBUS is connected to the (battery + buck boost IC's CHGin/Vin) or a >>> companion IFPMIC connected to a battery. In our board we have USB >>> Connector <-> IFPMIC <-> Battery. >> Which board is that? > > gs101-oriole board. Then why this is not used? The board was released some years ago, so I do not see a problem in using it. Best regards, Krzysztof
On 3/21/25 12:51 AM, Krzysztof Kozlowski wrote: > On 20/03/2025 22:11, Amit Sunil Dhamne wrote: >> On 3/16/25 9:52 AM, Krzysztof Kozlowski wrote: >>> On 15/03/2025 01:49, Amit Sunil Dhamne wrote: >>>> Hi Krzysztof, >>>> >>>> Thanks for the review! >>>> >>>> On 3/13/25 1:50 AM, Krzysztof Kozlowski wrote: >>>>> On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: >>>>>> Support for Battery Status & Battery Caps messages in response to >>>>>> Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices >>>>>> powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message >>>>>> Applicability" section. This patchset adds support for these AMSes >>>>>> to achieve greater compliance with the spec. >>>>> Which board uses it? I would be happy to see that connection between >>>>> batteries and USB connector on the schematics of some real device. How >>>>> does it look like? >>>> Any board that uses a USB Type-C connector that supplies power into or >>> If you keep responding like this, you will got nowhere, so let me >>> re-iterate: >>> >>> Which upstream DTS (or upstream supported hardware) is going to use this >>> binding, so I can see how you are going to implement it there in the >>> entire system? >> This is for maxim,max33359 Type-C controller. > Stop deflecting the questions. max33359 is not a board. I already asked > two times. > > Apparently admitting "no upstream users" is impossible, so let's state > the obvious: > > There are no upstream users of this. max33359 controller has an upstream user i.e., gs101-oriole (Pixel 6) board. Totally agree that at the moment there are no upstream devices/drivers for the Fuel Gauge (that my patchset has a dependency on) in gs101-oriole board. gs101-oriole uses max77759 fuel gauge device. I see that there's an effort for upstreaming it (https://lore.kernel.org/all/20250102-b4-gs101_max77759_fg-v2-0-87959abeb7ff@uclouvain.be/). I will mark my patches as dependent on it + demonstrate the relationship of the devices in the gs101-oriole board. Hope that's okay? Thanks, Amit >> This would property would have been present for the connector present in >> the typec device for gs101-oriole board (that uses the max33359 >> controller). > > But it is not. > > >> However, I will be exploring existing bindings to describe the >> relationship for now. >> >>>> out of a battery while operating in sink or source mode respectively. >>>> The VBUS is connected to the (battery + buck boost IC's CHGin/Vin) or a >>>> companion IFPMIC connected to a battery. In our board we have USB >>>> Connector <-> IFPMIC <-> Battery. >>> Which board is that? >> gs101-oriole board. > > Then why this is not used? The board was released some years ago, so I > do not see a problem in using it. > > Best regards, > Krzysztof
On 03/04/2025 05:41, Amit Sunil Dhamne wrote: > > On 3/21/25 12:51 AM, Krzysztof Kozlowski wrote: >> On 20/03/2025 22:11, Amit Sunil Dhamne wrote: >>> On 3/16/25 9:52 AM, Krzysztof Kozlowski wrote: >>>> On 15/03/2025 01:49, Amit Sunil Dhamne wrote: >>>>> Hi Krzysztof, >>>>> >>>>> Thanks for the review! >>>>> >>>>> On 3/13/25 1:50 AM, Krzysztof Kozlowski wrote: >>>>>> On Wed, Mar 12, 2025 at 04:42:00PM -0700, Amit Sunil Dhamne wrote: >>>>>>> Support for Battery Status & Battery Caps messages in response to >>>>>>> Get_Battery_Status & Get_Battery_Cap request is required by USB PD devices >>>>>>> powered by battery, as per "USB PD R3.1 V1.8 Spec", "6.13 Message >>>>>>> Applicability" section. This patchset adds support for these AMSes >>>>>>> to achieve greater compliance with the spec. >>>>>> Which board uses it? I would be happy to see that connection between >>>>>> batteries and USB connector on the schematics of some real device. How >>>>>> does it look like? >>>>> Any board that uses a USB Type-C connector that supplies power into or >>>> If you keep responding like this, you will got nowhere, so let me >>>> re-iterate: >>>> >>>> Which upstream DTS (or upstream supported hardware) is going to use this >>>> binding, so I can see how you are going to implement it there in the >>>> entire system? >>> This is for maxim,max33359 Type-C controller. >> Stop deflecting the questions. max33359 is not a board. I already asked >> two times. >> >> Apparently admitting "no upstream users" is impossible, so let's state >> the obvious: >> >> There are no upstream users of this. > > max33359 controller has an upstream user i.e., gs101-oriole (Pixel 6) > board. Totally agree that at the moment there are no upstream > devices/drivers for the Fuel Gauge (that my patchset has a dependency > on) in gs101-oriole board. gs101-oriole uses max77759 fuel gauge device. > I see that there's an effort for upstreaming it > (https://lore.kernel.org/all/20250102-b4-gs101_max77759_fg-v2-0-87959abeb7ff@uclouvain.be/). > I will mark my patches as dependent on it + demonstrate the relationship > of the devices in the gs101-oriole board. Hope that's okay? Then please send the DTS for GS101 Oriole using this binding. I don't understand the point of adding binding for some user and in the same time not doing anything for that user. Best regards, Krzysztof
On 03/04/2025 10:00, Krzysztof Kozlowski wrote: >>>>> >>>>> Which upstream DTS (or upstream supported hardware) is going to use this >>>>> binding, so I can see how you are going to implement it there in the >>>>> entire system? >>>> This is for maxim,max33359 Type-C controller. >>> Stop deflecting the questions. max33359 is not a board. I already asked >>> two times. >>> >>> Apparently admitting "no upstream users" is impossible, so let's state >>> the obvious: >>> >>> There are no upstream users of this. >> >> max33359 controller has an upstream user i.e., gs101-oriole (Pixel 6) >> board. Totally agree that at the moment there are no upstream >> devices/drivers for the Fuel Gauge (that my patchset has a dependency >> on) in gs101-oriole board. gs101-oriole uses max77759 fuel gauge device. >> I see that there's an effort for upstreaming it >> (https://lore.kernel.org/all/20250102-b4-gs101_max77759_fg-v2-0-87959abeb7ff@uclouvain.be/). >> I will mark my patches as dependent on it + demonstrate the relationship >> of the devices in the gs101-oriole board. Hope that's okay? > > Then please send the DTS for GS101 Oriole using this binding. I don't > understand the point of adding binding for some user and in the same > time not doing anything for that user. ... and just a reminder: DTS goes to separate patchset (!) from USB drivers one, with lore link in changelog or cover letter to the binding. Best regards, Krzysztof
On 4/3/25 1:02 AM, Krzysztof Kozlowski wrote: > On 03/04/2025 10:00, Krzysztof Kozlowski wrote: >>>>>> Which upstream DTS (or upstream supported hardware) is going to use this >>>>>> binding, so I can see how you are going to implement it there in the >>>>>> entire system? >>>>> This is for maxim,max33359 Type-C controller. >>>> Stop deflecting the questions. max33359 is not a board. I already asked >>>> two times. >>>> >>>> Apparently admitting "no upstream users" is impossible, so let's state >>>> the obvious: >>>> >>>> There are no upstream users of this. >>> max33359 controller has an upstream user i.e., gs101-oriole (Pixel 6) >>> board. Totally agree that at the moment there are no upstream >>> devices/drivers for the Fuel Gauge (that my patchset has a dependency >>> on) in gs101-oriole board. gs101-oriole uses max77759 fuel gauge device. >>> I see that there's an effort for upstreaming it >>> (https://lore.kernel.org/all/20250102-b4-gs101_max77759_fg-v2-0-87959abeb7ff@uclouvain.be/). >>> I will mark my patches as dependent on it + demonstrate the relationship >>> of the devices in the gs101-oriole board. Hope that's okay? >> Then please send the DTS for GS101 Oriole using this binding. I don't >> understand the point of adding binding for some user and in the same >> time not doing anything for that user. > > ... and just a reminder: DTS goes to separate patchset (!) from USB > drivers one, with lore link in changelog or cover letter to the binding. Sure thing! Thanks > > Best regards, > Krzysztof
© 2016 - 2025 Red Hat, Inc.