devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Richard Leitner <richard.leitner@linux.dev>
Cc: Conor Dooley <conor@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Jean Delvare <jdelvare@suse.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/4] dt-bindings: hwmon: add ti,ina238
Date: Wed, 25 Oct 2023 16:27:18 +0200	[thread overview]
Message-ID: <d68f1109-9e99-4a94-98d8-676be4af920f@linaro.org> (raw)
In-Reply-To: <2syaha4sapfpegvdsvef76egcqfebkuapxok6uripdbrgbk2vn@2xq5oi33zz2j>

On 25/10/2023 16:23, Richard Leitner wrote:
> On Wed, Oct 25, 2023 at 04:18:31PM +0200, Krzysztof Kozlowski wrote:
>> On 25/10/2023 16:11, Conor Dooley wrote:
>>> On Wed, Oct 25, 2023 at 04:07:31PM +0200, Richard Leitner wrote:
>>>> On Wed, Oct 25, 2023 at 03:00:01PM +0100, Conor Dooley wrote:
>>>>> On Wed, Oct 25, 2023 at 10:34:12AM +0000, Richard Leitner wrote:
>>>>>> The ina238 driver is available since 2021 but lacks a dt-bindings file.
>>>>>> Therefore add the missing file now.
>>>>>
>>>>> Seemingly it is documented in Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
>>>>
>>>> Thanks for the feedback. True. So is it fine if it's left there or
>>>> should it be removed from ti,ina2xxx.yml as this is a separate driver
>>>> with different properties?
>>>
>>> Merging them would seem like the most straightforward thing to do, no?
>>
>> Sorry folks, I don't quite get what do you want to merge or move and
>> why. Drivers are not related to bindings. The point is the compatible is
>> already documented, so is anything wrong with existing documentation?
> 
> ina238 is a separate driver which doesn't evaluate the same properties as
> the ina2xx driver. So I thought it would be reasonable to split those
> bindings and therefore reflect the drivers capabilities.

I do not see different properties in the bindings, so what do you mean
that it evaluates something else?

Anyway, whatever driver does is rarely good argument for change in
bindings, because we focus here on the hardware, not on one, chosen OS
implementation.

> 
> If it's fine if there are additional properties in the dt-bindings which

Where are they? Or rather which additional properties?

> are not evaluated by the driver then it's of course fine with me to just
> add the ina327 compatible in ina2xx.yaml.

Depends. What driver does, might not matter in some cases. What matters
is if these properties are applicable to this hardware.

Best regards,
Krzysztof


  reply	other threads:[~2023-10-25 14:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 10:34 [PATCH 0/4] hwmon: add ti,ina237 support to ina238 driver Richard Leitner
2023-10-25 10:34 ` [PATCH 1/4] MAINTAINERS: Add entry for " Richard Leitner
2023-10-26  1:03   ` Guenter Roeck
2023-10-26  6:46     ` Richard Leitner
2023-10-25 10:34 ` [PATCH 2/4] dt-bindings: hwmon: add ti,ina238 Richard Leitner
2023-10-25 14:00   ` Conor Dooley
2023-10-25 14:07     ` Richard Leitner
2023-10-25 14:11       ` Conor Dooley
2023-10-25 14:18         ` Krzysztof Kozlowski
2023-10-25 14:23           ` Richard Leitner
2023-10-25 14:27             ` Krzysztof Kozlowski [this message]
2023-10-25 14:32               ` Richard Leitner
2023-10-25 15:26                 ` Krzysztof Kozlowski
2023-10-25 14:25           ` Conor Dooley
2023-10-25 14:28             ` Krzysztof Kozlowski
2023-10-25 10:34 ` [PATCH 3/4] hwmon: ina238: add ina237 support Richard Leitner
2023-10-25 10:34 ` [PATCH 4/4] dt-bindings: hwmon: ti,ina238: add ti,ina237 Richard Leitner
2023-10-25 13:58   ` Conor Dooley
2023-10-25 14:13     ` Richard Leitner
2023-10-25 14:22       ` Krzysztof Kozlowski

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=d68f1109-9e99-4a94-98d8-676be4af920f@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=richard.leitner@linux.dev \
    --cc=robh+dt@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).