[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbD+vtiFnPHoSR9fpV5zwtdNo923frROR7Nb1nkAMP4wQ@mail.gmail.com>
Date: Tue, 31 Jan 2023 14:21:38 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, andersson@...nel.org,
agross@...nel.org, krzysztof.kozlowski@...aro.org,
marijn.suijten@...ainline.org, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] dt-bindings: pincfg-node: Introduce an
overridable way to set bias on pins
On Tue, Jan 31, 2023 at 12:50 AM Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
> > +#define DRIVE_STRENGTH 9
> > +#define DRIVE_STRENGTH_UA 10
> >
> > drive-strength = <8>; // 8mA drive strength
> >
> > bias-type = <DRIVE_STRENGTH>;
> >
> > OK where do I put my 8 mA now?
> >
> If you look at the 2/2 patch, this property only reads BIAS_
> values, which can't coexist anyway.
Well the DT bindings have to be consistent and clear on their
own, no matter how Linux implements it.
But I'm sure you can make YAML verification such that it is
impossible to use both schemes at the same time, and it's not
like I don't understand what you're getting at.
What I need as input is mainly the DT bindings people opinion
on introducing another orthogonal way of doing something
that is already possible to do another way, just more convenient.
Because that is essentially what is happening here.
Yours,
Linus Walleij
Powered by blists - more mailing lists