Add bindings for Maxim MAX8971 charger.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../bindings/power/supply/maxim,max8971.yaml | 140 ++++++++++++++++++
1 file changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml
new file mode 100644
index 000000000000..91d9fec1d46a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/maxim,max8971.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/maxim,max8971.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim MAX8971 IC charger
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ The MAX8971 is a compact, high-frequency, high-efficiency switch-mode charger
+ for a one-cell lithium-ion (Li+) battery.
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: maxim,max8971
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ maxim,fcharge-current-limit-microamp:
+ description:
+ Fast-Charge current limit
+ minimum: 250000
+ default: 500000
+ maximum: 1550000
+
+ maxim,fcharge-timer-hours:
+ description:
+ Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher
+ will disable Fast-Charge timer.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 5
+
+ maxim,fcharge-rst-threshold-high:
+ description:
+ Set Fast-Charge reset threshold to -100 mV
+ type: boolean
+
+ maxim,in-current-limit-microamp:
+ description:
+ Input current limit
+ minimum: 100000
+ default: 500000
+ maximum: 1500000
+
+ maxim,topoff-timer-minutes:
+ description:
+ Top-Off timer minutes
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 10, 20, 30, 40, 50, 60, 70]
+ default: 30
+
+ maxim,topoff-current-threshold-microamp:
+ description:
+ Top-Off current threshold
+ enum: [50000, 100000, 150000, 200000]
+ default: 50000
+
+ maxim,fcharge-usb-current-limit-microamp:
+ description:
+ Fast-Charge USB current limit
+ minimum: 100000
+ default: 500000
+ maximum: 1500000
+
+ maxim,fcharge-ac-current-limit-microamp:
+ description:
+ Fast-Charge AC current limit
+ minimum: 100000
+ default: 500000
+ maximum: 1500000
+
+ maxim,usb-in-current-limit-microamp:
+ description:
+ USB Input current limit
+ minimum: 100000
+ default: 500000
+ maximum: 1500000
+
+ maxim,ac-in-current-limit-microamp:
+ description:
+ AC Input current limit
+ minimum: 100000
+ default: 500000
+ maximum: 1500000
+
+ port:
+ description:
+ An optional port node to link the extcon device to detect type of plug.
+ $ref: /schemas/graph.yaml#/properties/port
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@35 {
+ compatible = "maxim,max8971";
+ reg = <0x35>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <74 IRQ_TYPE_LEVEL_LOW>;
+
+ maxim,fcharge-ac-current-limit-microamp = <900000>;
+ maxim,fcharge-timer-hours = <0>;
+
+ maxim,fcharge-rst-threshold-high;
+ maxim,ac-in-current-limit-microamp = <1200000>;
+
+ maxim,topoff-timer-minutes = <0>;
+ maxim,topoff-current-threshold-microamp = <200000>;
+
+ port {
+ charger_input: endpoint {
+ remote-endpoint = <&extcon_output>;
+ };
+ };
+ };
+ };
+...
--
2.43.0On Wed, Feb 26, 2025 at 11:36:59AM +0200, Svyatoslav Ryhel wrote: > + maxim,fcharge-current-limit-microamp: > + description: > + Fast-Charge current limit > + minimum: 250000 > + default: 500000 > + maximum: 1550000 > + > + maxim,fcharge-timer-hours: > + description: > + Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher > + will disable Fast-Charge timer. > + $ref: /schemas/types.yaml#/definitions/uint32 > + default: 5 You still did not answer why this is board specific. This was rejected in the past because of that reason and nothing here changed. Nothing will change without detailed explanation, so use other interfaces if you need user-space to configure it (see other drivers, e.g. maxim) > + > + maxim,fcharge-rst-threshold-high: > + description: > + Set Fast-Charge reset threshold to -100 mV > + type: boolean > + > + maxim,in-current-limit-microamp: > + description: > + Input current limit > + minimum: 100000 > + default: 500000 > + maximum: 1500000 > + > + maxim,topoff-timer-minutes: > + description: > + Top-Off timer minutes > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 10, 20, 30, 40, 50, 60, 70] > + default: 30 Same. > + > + maxim,topoff-current-threshold-microamp: > + description: > + Top-Off current threshold > + enum: [50000, 100000, 150000, 200000] > + default: 50000 > + > + maxim,fcharge-usb-current-limit-microamp: > + description: > + Fast-Charge USB current limit > + minimum: 100000 > + default: 500000 > + maximum: 1500000 > + > + maxim,fcharge-ac-current-limit-microamp: > + description: > + Fast-Charge AC current limit > + minimum: 100000 > + default: 500000 > + maximum: 1500000 > + > + maxim,usb-in-current-limit-microamp: > + description: > + USB Input current limit > + minimum: 100000 > + default: 500000 > + maximum: 1500000 > + > + maxim,ac-in-current-limit-microamp: > + description: > + AC Input current limit > + minimum: 100000 > + default: 500000 > + maximum: 1500000 Half of these properties as well are not suitable and duplicate existing sysfs interface. And for remaining, still no battery. Best regards, Krzysztof
чт, 27 лют. 2025 р. о 12:45 Krzysztof Kozlowski <krzk@kernel.org> пише: > > On Wed, Feb 26, 2025 at 11:36:59AM +0200, Svyatoslav Ryhel wrote: > > + maxim,fcharge-current-limit-microamp: > > + description: > > + Fast-Charge current limit > > + minimum: 250000 > > + default: 500000 > > + maximum: 1550000 > > + > > + maxim,fcharge-timer-hours: > > + description: > > + Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher > > + will disable Fast-Charge timer. > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + default: 5 > > You still did not answer why this is board specific. This was rejected > in the past because of that reason and nothing here changed. Nothing > will change without detailed explanation, so use other interfaces if you > need user-space to configure it (see other drivers, e.g. maxim) > Btw, I have used this awesome example you have provided. Take a look https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml?h=v6.14-rc4 Oh, I wonder why it uses so much values which duplicate battery? I know, it lacks battery, I assume that is why? > > + > > + maxim,fcharge-rst-threshold-high: > > + description: > > + Set Fast-Charge reset threshold to -100 mV > > + type: boolean > > + > > + maxim,in-current-limit-microamp: > > + description: > > + Input current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,topoff-timer-minutes: > > + description: > > + Top-Off timer minutes > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 10, 20, 30, 40, 50, 60, 70] > > + default: 30 > > Same. > > > + > > + maxim,topoff-current-threshold-microamp: > > + description: > > + Top-Off current threshold > > + enum: [50000, 100000, 150000, 200000] > > + default: 50000 > > + > > + maxim,fcharge-usb-current-limit-microamp: > > + description: > > + Fast-Charge USB current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,fcharge-ac-current-limit-microamp: > > + description: > > + Fast-Charge AC current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,usb-in-current-limit-microamp: > > + description: > > + USB Input current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,ac-in-current-limit-microamp: > > + description: > > + AC Input current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > Half of these properties as well are not suitable and duplicate existing > sysfs interface. > > And for remaining, still no battery. > > Best regards, > Krzysztof >
On 27/02/2025 12:03, Svyatoslav Ryhel wrote: > чт, 27 лют. 2025 р. о 12:45 Krzysztof Kozlowski <krzk@kernel.org> пише: >> >> On Wed, Feb 26, 2025 at 11:36:59AM +0200, Svyatoslav Ryhel wrote: >>> + maxim,fcharge-current-limit-microamp: >>> + description: >>> + Fast-Charge current limit >>> + minimum: 250000 >>> + default: 500000 >>> + maximum: 1550000 >>> + >>> + maxim,fcharge-timer-hours: >>> + description: >>> + Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher >>> + will disable Fast-Charge timer. >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + default: 5 >> >> You still did not answer why this is board specific. This was rejected >> in the past because of that reason and nothing here changed. Nothing >> will change without detailed explanation, so use other interfaces if you >> need user-space to configure it (see other drivers, e.g. maxim) >> > > Btw, I have used this awesome example you have provided. Take a look Where did I provide this example? > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml?h=v6.14-rc4 I opened it and I do not see anything about time. Please point to specific line. But regardless, how did I propose to use 12 year old binding? Where did I suggest that one? > > Oh, I wonder why it uses so much values which duplicate battery? I > know, it lacks battery, I assume that is why? No. You added to DT something which is not a hardware property, but user-space choice or policy. Best regards, Krzysztof
пн, 3 бер. 2025 р. о 09:52 Krzysztof Kozlowski <krzk@kernel.org> пише: > > On 27/02/2025 12:03, Svyatoslav Ryhel wrote: > > чт, 27 лют. 2025 р. о 12:45 Krzysztof Kozlowski <krzk@kernel.org> пише: > >> > >> On Wed, Feb 26, 2025 at 11:36:59AM +0200, Svyatoslav Ryhel wrote: > >>> + maxim,fcharge-current-limit-microamp: > >>> + description: > >>> + Fast-Charge current limit > >>> + minimum: 250000 > >>> + default: 500000 > >>> + maximum: 1550000 > >>> + > >>> + maxim,fcharge-timer-hours: > >>> + description: > >>> + Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher > >>> + will disable Fast-Charge timer. > >>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>> + default: 5 > >> > >> You still did not answer why this is board specific. This was rejected > >> in the past because of that reason and nothing here changed. Nothing > >> will change without detailed explanation, so use other interfaces if you > >> need user-space to configure it (see other drivers, e.g. maxim) > >> > > > > Btw, I have used this awesome example you have provided. Take a look > > Where did I provide this example? > Its presence in the docs is an example on its no? You have explicitly told to check other maxim devices, I did so, they all have similar set of convifurations. > > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml?h=v6.14-rc4 > > I opened it and I do not see anything about time. Please point to > specific line. > > But regardless, how did I propose to use 12 year old binding? Where did > I suggest that one? > > > > > Oh, I wonder why it uses so much values which duplicate battery? I > > know, it lacks battery, I assume that is why? > > No. You added to DT something which is not a hardware property, but > user-space choice or policy. > It is NOT a user-space choice or policy! > > > Best regards, > Krzysztof
On 03/03/2025 09:13, Svyatoslav Ryhel wrote: > пн, 3 бер. 2025 р. о 09:52 Krzysztof Kozlowski <krzk@kernel.org> пише: >> >> On 27/02/2025 12:03, Svyatoslav Ryhel wrote: >>> чт, 27 лют. 2025 р. о 12:45 Krzysztof Kozlowski <krzk@kernel.org> пише: >>>> >>>> On Wed, Feb 26, 2025 at 11:36:59AM +0200, Svyatoslav Ryhel wrote: >>>>> + maxim,fcharge-current-limit-microamp: >>>>> + description: >>>>> + Fast-Charge current limit >>>>> + minimum: 250000 >>>>> + default: 500000 >>>>> + maximum: 1550000 >>>>> + >>>>> + maxim,fcharge-timer-hours: >>>>> + description: >>>>> + Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher >>>>> + will disable Fast-Charge timer. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + default: 5 >>>> >>>> You still did not answer why this is board specific. This was rejected >>>> in the past because of that reason and nothing here changed. Nothing Where are the arguments to existing/previous decisions? >>>> will change without detailed explanation, so use other interfaces if you Again, where is detailed explanation why time is determined per board, unlike previously agreed that it is not? >>>> need user-space to configure it (see other drivers, e.g. maxim) >>>> >>> >>> Btw, I have used this awesome example you have provided. Take a look >> >> Where did I provide this example? >> > > Its presence in the docs is an example on its no? You have explicitly > told to check other maxim devices, I did so, they all have similar set > of convifurations. Choose rather later or latest, not 12 YO, binding as an example. > >>> >>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml?h=v6.14-rc4 >> >> I opened it and I do not see anything about time. Please point to >> specific line. >> >> But regardless, how did I propose to use 12 year old binding? Where did >> I suggest that one? >> >>> >>> Oh, I wonder why it uses so much values which duplicate battery? I >>> know, it lacks battery, I assume that is why? >> >> No. You added to DT something which is not a hardware property, but >> user-space choice or policy. >> > > It is NOT a user-space choice or policy! Previous discussions on the lists - since you mention 12 year old binding, so also discussions 12 years ago - determined that they are closer to them than board configuration. I already said - this was rejected in the past - so now I am repeating myself. You did not bring any arguments just keep repeating "no", so I suggest reading previous discussions and coming with arguments against them. Best regards, Krzysztof
чт, 27 лют. 2025 р. о 12:45 Krzysztof Kozlowski <krzk@kernel.org> пише: > > On Wed, Feb 26, 2025 at 11:36:59AM +0200, Svyatoslav Ryhel wrote: > > + maxim,fcharge-current-limit-microamp: > > + description: > > + Fast-Charge current limit > > + minimum: 250000 > > + default: 500000 > > + maximum: 1550000 > > + > > + maxim,fcharge-timer-hours: > > + description: > > + Fast-Charge timer in hours. Setting this value 3 and lower or 11 and higher > > + will disable Fast-Charge timer. > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + default: 5 > > You still did not answer why this is board specific. This was rejected > in the past because of that reason and nothing here changed. Nothing > will change without detailed explanation, so use other interfaces if you > need user-space to configure it (see other drivers, e.g. maxim) > > > + > > + maxim,fcharge-rst-threshold-high: > > + description: > > + Set Fast-Charge reset threshold to -100 mV > > + type: boolean > > + > > + maxim,in-current-limit-microamp: > > + description: > > + Input current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,topoff-timer-minutes: > > + description: > > + Top-Off timer minutes > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 10, 20, 30, 40, 50, 60, 70] > > + default: 30 > > Same. > > > + > > + maxim,topoff-current-threshold-microamp: > > + description: > > + Top-Off current threshold > > + enum: [50000, 100000, 150000, 200000] > > + default: 50000 > > + > > + maxim,fcharge-usb-current-limit-microamp: > > + description: > > + Fast-Charge USB current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,fcharge-ac-current-limit-microamp: > > + description: > > + Fast-Charge AC current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,usb-in-current-limit-microamp: > > + description: > > + USB Input current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > + > > + maxim,ac-in-current-limit-microamp: > > + description: > > + AC Input current limit > > + minimum: 100000 > > + default: 500000 > > + maximum: 1500000 > > Half of these properties as well are not suitable and duplicate existing > sysfs interface. > All these properties allow configure the charger to suit the device on which it is used. None of them are required but are a nice addition. Why you are denying me an ability to fully utilize hardware I have and tune it to the device? All those values represent hardware registers which can be customized for the device, not for the end user to mess with. > And for remaining, still no battery. > reference to power-supply IS included, hence the battery option is there as well. > Best regards, > Krzysztof >
On 27/02/2025 11:55, Svyatoslav Ryhel wrote: >>> + Please kindly trim the replies from unnecessary context. It makes it much easier to find new content. >>> + maxim,usb-in-current-limit-microamp: >>> + description: >>> + USB Input current limit >>> + minimum: 100000 >>> + default: 500000 >>> + maximum: 1500000 >>> + >>> + maxim,ac-in-current-limit-microamp: >>> + description: >>> + AC Input current limit >>> + minimum: 100000 >>> + default: 500000 >>> + maximum: 1500000 >> >> Half of these properties as well are not suitable and duplicate existing >> sysfs interface. >> > > All these properties allow configure the charger to suit the device on > which it is used. None of them are required but are a nice addition. > Why you are denying me an ability to fully utilize hardware I have and > tune it to the device? All those values represent hardware registers > which can be customized for the device, not for the end user to mess > with. Because you put user-space choice or OS policy into the DT and DT is not for that. > >> And for remaining, still no battery. >> > > reference to power-supply IS included, hence the battery option is > there as well. I don't see it being used at all and you explicitly duplicated properties which means that reference is redundant and should be dropped with such binding. So how did you solve my request to add reference which then you make redundant? Add reference and use it. Best regards, Krzysztof
пн, 3 бер. 2025 р. о 09:54 Krzysztof Kozlowski <krzk@kernel.org> пише: > > On 27/02/2025 11:55, Svyatoslav Ryhel wrote: > >>> + > > Please kindly trim the replies from unnecessary context. It makes it > much easier to find new content. > > >>> + maxim,usb-in-current-limit-microamp: > >>> + description: > >>> + USB Input current limit > >>> + minimum: 100000 > >>> + default: 500000 > >>> + maximum: 1500000 > >>> + > >>> + maxim,ac-in-current-limit-microamp: > >>> + description: > >>> + AC Input current limit > >>> + minimum: 100000 > >>> + default: 500000 > >>> + maximum: 1500000 > >> > >> Half of these properties as well are not suitable and duplicate existing > >> sysfs interface. > >> > > > > All these properties allow configure the charger to suit the device on > > which it is used. None of them are required but are a nice addition. > > Why you are denying me an ability to fully utilize hardware I have and > > tune it to the device? All those values represent hardware registers > > which can be customized for the device, not for the end user to mess > > with. > > Because you put user-space choice or OS policy into the DT and DT is not > for that. > Those are NOT user-space choice or OS policy those are vendor configuration for a specific device and are NOT and NEVER were exposed to user configurations EVER. User messing with those may lead to device breaking. > > > >> And for remaining, still no battery. > >> > > > > reference to power-supply IS included, hence the battery option is > > there as well. > > I don't see it being used at all and you explicitly duplicated > properties which means that reference is redundant and should be dropped > with such binding. So how did you solve my request to add reference > which then you make redundant? Add reference and use it. > Which properties I have duplicated? > Best regards, > Krzysztof
On 03/03/2025 09:11, Svyatoslav Ryhel wrote: > пн, 3 бер. 2025 р. о 09:54 Krzysztof Kozlowski <krzk@kernel.org> пише: >> >> On 27/02/2025 11:55, Svyatoslav Ryhel wrote: >>>>> + >> >> Please kindly trim the replies from unnecessary context. It makes it >> much easier to find new content. >> >>>>> + maxim,usb-in-current-limit-microamp: >>>>> + description: >>>>> + USB Input current limit >>>>> + minimum: 100000 >>>>> + default: 500000 >>>>> + maximum: 1500000 >>>>> + >>>>> + maxim,ac-in-current-limit-microamp: >>>>> + description: >>>>> + AC Input current limit >>>>> + minimum: 100000 >>>>> + default: 500000 >>>>> + maximum: 1500000 >>>> >>>> Half of these properties as well are not suitable and duplicate existing >>>> sysfs interface. >>>> >>> >>> All these properties allow configure the charger to suit the device on >>> which it is used. None of them are required but are a nice addition. >>> Why you are denying me an ability to fully utilize hardware I have and >>> tune it to the device? All those values represent hardware registers >>> which can be customized for the device, not for the end user to mess >>> with. >> >> Because you put user-space choice or OS policy into the DT and DT is not >> for that. >> > > Those are NOT user-space choice or OS policy those are vendor > configuration for a specific device and are NOT and NEVER were exposed Then look at existing devices. We had these discussions in the past and these are usually exposed to user-space. > to user configurations EVER. User messing with those may lead to > device breaking. > >>> >>>> And for remaining, still no battery. >>>> >>> >>> reference to power-supply IS included, hence the battery option is >>> there as well. >> >> I don't see it being used at all and you explicitly duplicated >> properties which means that reference is redundant and should be dropped >> with such binding. So how did you solve my request to add reference >> which then you make redundant? Add reference and use it. >> > > Which properties I have duplicated? All the current limits. > >> Best regards, >> Krzysztof Best regards, Krzysztof
пн, 3 бер. 2025 р. о 10:18 Krzysztof Kozlowski <krzk@kernel.org> пише: > > On 03/03/2025 09:11, Svyatoslav Ryhel wrote: > > пн, 3 бер. 2025 р. о 09:54 Krzysztof Kozlowski <krzk@kernel.org> пише: > >> > >> On 27/02/2025 11:55, Svyatoslav Ryhel wrote: > >>>>> + > >> > >> Please kindly trim the replies from unnecessary context. It makes it > >> much easier to find new content. > >> > >>>>> + maxim,usb-in-current-limit-microamp: > >>>>> + description: > >>>>> + USB Input current limit > >>>>> + minimum: 100000 > >>>>> + default: 500000 > >>>>> + maximum: 1500000 > >>>>> + > >>>>> + maxim,ac-in-current-limit-microamp: > >>>>> + description: > >>>>> + AC Input current limit > >>>>> + minimum: 100000 > >>>>> + default: 500000 > >>>>> + maximum: 1500000 > >>>> > >>>> Half of these properties as well are not suitable and duplicate existing > >>>> sysfs interface. > >>>> > >>> > >>> All these properties allow configure the charger to suit the device on > >>> which it is used. None of them are required but are a nice addition. > >>> Why you are denying me an ability to fully utilize hardware I have and > >>> tune it to the device? All those values represent hardware registers > >>> which can be customized for the device, not for the end user to mess > >>> with. > >> > >> Because you put user-space choice or OS policy into the DT and DT is not > >> for that. > >> > > > > Those are NOT user-space choice or OS policy those are vendor > > configuration for a specific device and are NOT and NEVER were exposed > > Then look at existing devices. We had these discussions in the past and > these are usually exposed to user-space. > Provide an example, where there is same or similar configuration. > > to user configurations EVER. User messing with those may lead to > > device breaking. > > > >>> > >>>> And for remaining, still no battery. > >>>> > >>> > >>> reference to power-supply IS included, hence the battery option is > >>> there as well. > >> > >> I don't see it being used at all and you explicitly duplicated > >> properties which means that reference is redundant and should be dropped > >> with such binding. So how did you solve my request to add reference > >> which then you make redundant? Add reference and use it. > >> > > > > Which properties I have duplicated? > > All the current limits. > Those are blank works, show me an example of such duplication. > > > >> Best regards, > >> Krzysztof > > > Best regards, > Krzysztof
On 03/03/2025 09:20, Svyatoslav Ryhel wrote: > пн, 3 бер. 2025 р. о 10:18 Krzysztof Kozlowski <krzk@kernel.org> пише: >> >> On 03/03/2025 09:11, Svyatoslav Ryhel wrote: >>> пн, 3 бер. 2025 р. о 09:54 Krzysztof Kozlowski <krzk@kernel.org> пише: >>>> >>>> On 27/02/2025 11:55, Svyatoslav Ryhel wrote: >>>>>>> + >>>> >>>> Please kindly trim the replies from unnecessary context. It makes it >>>> much easier to find new content. >>>> >>>>>>> + maxim,usb-in-current-limit-microamp: >>>>>>> + description: >>>>>>> + USB Input current limit >>>>>>> + minimum: 100000 >>>>>>> + default: 500000 >>>>>>> + maximum: 1500000 >>>>>>> + >>>>>>> + maxim,ac-in-current-limit-microamp: >>>>>>> + description: >>>>>>> + AC Input current limit >>>>>>> + minimum: 100000 >>>>>>> + default: 500000 >>>>>>> + maximum: 1500000 >>>>>> >>>>>> Half of these properties as well are not suitable and duplicate existing >>>>>> sysfs interface. >>>>>> >>>>> >>>>> All these properties allow configure the charger to suit the device on >>>>> which it is used. None of them are required but are a nice addition. >>>>> Why you are denying me an ability to fully utilize hardware I have and >>>>> tune it to the device? All those values represent hardware registers >>>>> which can be customized for the device, not for the end user to mess >>>>> with. >>>> >>>> Because you put user-space choice or OS policy into the DT and DT is not >>>> for that. >>>> >>> >>> Those are NOT user-space choice or OS policy those are vendor >>> configuration for a specific device and are NOT and NEVER were exposed >> >> Then look at existing devices. We had these discussions in the past and >> these are usually exposed to user-space. >> > > Provide an example, where there is same or similar configuration. If you tried even a bit, you would easily find them by grep for timer/hours/minutes. You do not even try but put this work on maintainer. Do the homework and try a bit harder instead of pushing this on me. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.