devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Svyatoslav Ryhel <clamor95@gmail.com>, Rob Herring <robh@kernel.org>
Cc: Sebastian Reichel <sre@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: power: supply: Document Maxim MAX8971 charger
Date: Wed, 12 Mar 2025 10:49:19 +0100	[thread overview]
Message-ID: <4d1c3eb1-5c42-490f-83e5-60de05ffad06@kernel.org> (raw)
In-Reply-To: <CAPVz0n09ZP1i2tasdTvnt8RvjhALvUYjv9u_EGRtnXPOYQtuqQ@mail.gmail.com>

On 12/03/2025 07:02, Svyatoslav Ryhel wrote:
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  interrupts:
>>> +    maxItems: 1
>>> +
>>> +  monitored-battery: true
>>> +
>>> +  maxim,usb-connector:
>>
>> Just 'connector', so when we have a 3rd case, we don't have a 3rd
>> vendor.
>>
> 
> Please, please be explicit and specific, you could not tell me this in

git grep -C 3 connector:

> v3, you could but you decided to fuck up v4 as well. So wise.

We got a lot to review thus we make reviews concise. I understand that
it might lead to insufficient guidance, so more help in removing
workload from maintainers is always appreciated.

Instead of using vulgar words towards us, please put a bit more effort
and look at other recent bindings how they do it.

Review is provided in good faith and if it is by any chance incorrect,
it is enough to disagree instead of throwing things like above. That's
not acceptable.

> Additionally, if you want a generic 'connector' which can be
> referenced as 'connector: true' then add one, ATM this is classified
> under your own terms as 'vendor property' and needs a vendor prefix.

richtek,usb-connector is not the good example here. Your previous code here:
https://lore.kernel.org/all/20250225090014.59067-2-clamor95@gmail.com/

looks correct - you have there port. So where does charger_input point?


> 
>>> +    description:
>>> +      Phandle to a USB connector according to usb-connector.yaml. The connector
>>> +      should be a child of the extcon device.
>>
>> 'extcon' is a Linuxism. Is there an actual requirement here that's not
>> *current* Linux requirements (which could change)? I assume the
>> requirement is to have vbus or some supply?
>>
> 
> Pardon me, this schema is part of Linux kernel, no? I have no clue why

Bindings are used by other projects as well and they live here because
of possibility of review by skilled people and due to size of the
community. It does not make them, in general, Linux specific.

> you collectively decided to just ignore external connector detection
> devices. Ignorance does not affect the fact that such devices exist.

We didn't. They are described.

> 
> And no, it does not need vbus not supply, it needs EXTCON

There is no such thing as "extcon" from hardware point of view. Point us
to any standard or even wikipedia article describing it.


Best regards,
Krzysztof

  reply	other threads:[~2025-03-12  9:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10  8:02 [PATCH v4 0/2] power: supply: Add support for Maxim MAX8971 charger Svyatoslav Ryhel
2025-03-10  8:02 ` [PATCH v4 1/2] dt-bindings: power: supply: Document " Svyatoslav Ryhel
2025-03-11 19:37   ` Rob Herring
2025-03-12  6:02     ` Svyatoslav Ryhel
2025-03-12  9:49       ` Krzysztof Kozlowski [this message]
2025-03-12  9:57         ` Svyatoslav Ryhel
2025-03-14  8:05         ` Svyatoslav Ryhel
2025-03-12 11:58       ` Rob Herring
2025-03-10  8:02 ` [PATCH v4 2/2] power: supply: Add support for " Svyatoslav Ryhel
2025-03-12  8:50   ` Sebastian Reichel
2025-03-12  9:15     ` Svyatoslav Ryhel
2025-03-12 12:28       ` Svyatoslav Ryhel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d1c3eb1-5c42-490f-83e5-60de05ffad06@kernel.org \
    --to=krzk@kernel.org \
    --cc=clamor95@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).