On 25/10/2023 16:13, Richard Leitner wrote: > On Wed, Oct 25, 2023 at 02:58:44PM +0100, Conor Dooley wrote: >> On Wed, Oct 25, 2023 at 10:34:14AM +0000, Richard Leitner wrote: >>> Add ti,ina237 binding to ti,ina238 as they share the same driver. >>> >>> Signed-off-by: Richard Leitner <richard.leitner@xxxxxxxxx> >>> --- >>> Documentation/devicetree/bindings/hwmon/ti,ina238.yaml | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml >>> index aba89e5f34b3..17408076696c 100644 >>> --- a/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml >>> +++ b/Documentation/devicetree/bindings/hwmon/ti,ina238.yaml >>> @@ -22,6 +22,7 @@ description: | >>> properties: >>> compatible: >>> enum: >>> + - ti,ina237 >> >> The driver patch you have done implies no difference between the >> programming model for both of these devices. It'd seem to make more sense >> for the ina237 to fall back to the ina238, thereby requiring no change in >> the driver to support it. > > Thanks for the quick feedback, Conor. > > I first thought of just mentioning the ina237 in the documentation as > "compatible" to the ina238. But IMHO it is better understandable if it's > listed as compatible. Conor did not oppose listing it. The point is to use fall-back. > > And I would strongly encourage mentioning it somewhere (documentation or > compatible). So other people using the ina237 are able to find it and > don't have to compare the datasheets by themselves to find the right > driver. Sure, there is plenty of space in the driver code (.c or Kconfig) to document whatever you wish. We focus here on the bindings, though. Best regards, Krzysztof
