Linux USB
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>,
	gregkh@linuxfoundation.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, davidm@egauge.net
Cc: ~lkcamp/patches@lists.sr.ht, linux-usb@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: usb: add yaml file for maxim,max3421
Date: Sat, 11 Oct 2025 01:27:29 +0200	[thread overview]
Message-ID: <0caca8b6-05b9-43a2-9108-9262a3ed1196@kernel.org> (raw)
In-Reply-To: <935dbd93-2b20-45fb-a5b1-04f6ac67615e@gmail.com>

On 10/10/2025 21:46, Rodrigo Gobbi wrote:
> On 10/9/25 22:34, Krzysztof Kozlowski wrote:
>> On 09/10/2025 03:15, Rodrigo Gobbi wrote:
>>> Convert maxim,max3421.txt to yaml format with a few extra properties like
>>
>>
>> Here and in subject, please do not use yaml at all. Look at other
>> commits, this is supposed to be:
>>
>> dt-bindings: usb: maxim,max3421: convert to DT schema
>>
>> (and all other things like "file for" are redundant")
>>
>>> maxim,vbus-en-pin, maxim,gpx-pin, reset pin and supplies. Also add a
>>
>> Why new properties? You must explain not only the difference but WHY you
>> are doing this.
>>
>> WHY is the most important question/answer.
> 
> The reason was that the device (the IC) supports that. Is it
> enough to justify? I mean, is a plausible answer in this case? If yes,
> I agree that my commit msg was not right since I didn`t mention that.


It's not relevant to conversion then, so must be done in separate commit.

> 
>>
>>> maxim,max3421e compatible with a fallback, since the actually PN is with
>>> the 'e' suffix.
>>
>> We don't add PNs usually, unless there is a need. So again, why?
>>
> 
> The PN of this is Maxim3421e, Maxim3421 without `e` doesn`t exists as far as I`ve
> searched it. If it exists, it`s a different thing. In this case, I would expect that
> the compatible string should be something that "matches" the device, but in this
> case, the compatible string is without the 'e'. In that way, I was suggesting in this patch to
> allow a more precisely compatible string to no break anyone using the original one. But if 
> it was a bad idea here, I can drop that for sure.

So again not relevant to conversion and you need separate commit with
its own rationale explaining WHY you are doing this.

> 
>>> +  spi-max-frequency:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>
>> No, drop $ref. Do you see any binding like that? No, there is none.
> 
> I`ve a previous patch recently at [1], that added a "similar" thing of frequency:
> 
> +  sampling-frequency:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 2500000
> +    maximum: 20000000
> +    description:
> +      Default sampling frequency of the ADC in Hz.
> 
> In that case, $ref and description were added. Why that case is different from this one here?
> [1] https://lore.kernel.org/all/20250522204130.21604-1-rodrigo.gobbi.7@gmail.com/

Yes it is very different. Please use git grep.

> 
>>
>>> +
>>> +  maxim,vbus-en-pin:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +    description:
>>> +      One of eight GPOUT pins to control external VBUS power and the polarity
>>> +      of the active level. It's an array of GPIO number and the active level of it.
>>> +    minItems: 2
>>> +    maxItems: 2
>>> +
>>> +  maxim,gpx-pin:
>>
>> I don't understand. There is no need for this property. Drop.
> 
> During my other reviews of new bindings, my final premise was that we should add every "capability" of
> a device (the IC) regardless of the driver support. In this case, the maxim,gpx-pin, is an example of that,
> the device supports that despite the driver support. I`m wondering here why we cannot add that here.


Read your commit msg. You are doing conversion. You cannot add random
stuff or missing hardware, just becase you are doing conversion.

You need to organize commits in logical way. Please ready carefully
submitting patches document.

Best regards,
Krzysztof

      reply	other threads:[~2025-10-10 23:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-09 18:15 [PATCH] dt-bindings: usb: add yaml file for maxim,max3421 Rodrigo Gobbi
2025-10-10  1:34 ` Krzysztof Kozlowski
2025-10-10 19:46   ` Rodrigo Gobbi
2025-10-10 23:27     ` Krzysztof Kozlowski [this message]

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=0caca8b6-05b9-43a2-9108-9262a3ed1196@kernel.org \
    --to=krzk@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=davidm@egauge.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rodrigo.gobbi.7@gmail.com \
    --cc=~lkcamp/patches@lists.sr.ht \
    /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