linux-kernel - Re: [RFC PATCH 1/2] dt-bindings: pincfg-node: Introduce an overridable way to set bias on pins

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3f70ac2-d097-b6ee-22d3-92fcfdd7c53f@linaro.org>
Date:   Tue, 31 Jan 2023 00:50:36 +0100
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Linus Walleij <linus.walleij@...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 31.01.2023 00:10, Linus Walleij wrote:
> On Mon, Jan 30, 2023 at 5:54 PM Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
> 
>> We came to a point where we sometimes we support a few dozen boards
>> with a given SoC. Sometimes, we have to take into consideration
>> configurations which deviate rather significatly from the reference
>> or most common designs. In the context of pinctrl, this often comes
>> down to wildly different pin configurations. While pins, function and
>> drive-strength are easily overridable, the (mostly) boolean properties
>> associated with setting bias, aren't. This wouldn't be much of a
>> problem if they didn't differ between boards so often, preventing us
>> from having a "nice" baseline setup without inevitably having to go
>> with an ugly /delete-property/.
> 
> I see what the problem is.
> 
> Have you considered pulling out *all* the pin config for a certain
> reference design into its own .dtsi file, simply? And then not include
> that to the next product.
> 
> This pattern is pretty common.
It's *a* solution, but we already have some soc-pmics.dtsi-s which
include PMICs and reference regulator-to-peripherals assignments.
Adding another soc-reference-pins.dtsi would open the doors for
other soc-abcxyz.dtsi-s which would in turn lead to exchanging the
problem of redefining the same sets of properties 50 times to
having to include 20 device trees for each and every device. Allow
that and we basically have msm-3.10 except in torvalds/linux.

Adding to that, some devices are 98% compliant with the reference
designs, but randomly swap out one pin etc.

> 
>> Introduce bias-type, a bias-type-
>> specific property and clone the pinconf-generic type enum into
>> dt-bindings to allow for setting the bias in an easily overridable
>> manner such as:
>>
>> // SoC DT
>> i2c0_pin: i2c0-pin-state {
>>         pins = "gpio10";
>>         function = "gpio";
>>         bias-type = <BIAS_PULL_UP>;
>> };
>>
>> // Deviant board DT
>> &i2c0_pin {
>>         bias-type = <BIAS_HIGH_IMPEDANCE>;
>> };
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> 
> The idea is pretty straight-forward.
> 
> But it applies to systems already using the bool flags. So what do
> we do the day we manage to have:
> 
> {
>     bias-type = <BIAS_HIGH_IMPEDANCE>;
>     bias-pull-up;
> };
> 
> As you see this makes it necessary to author some really nasty
> YAML to make sure this cannot happen or everyone has to make
> a runtime check for it.
oneOf:
- bias-type
- enum:
    - bias-pull-down
    - bias-...

Doesn't seem really nasty to me.. And a runtime check is basically
in place, as I made sure the code in 2/2 prefers bias-type and falls
back to the existing mechanism if it's not found.

> 
> Another problem is that I was just discussing with Bjorn for some
> specific i2c pull-up, was actually using the argument for
> bias-pull-up with a parameter:
> 
> bias-pull-up = <8000000>;  // 8kOhm pull-up
This is an easy fix. Count the elements and if there's more than
one, pass the second one as a value. Both of these things already
have common of_ functions made just for that.

> 
> Not to mention that other platforms than qcom use this and
> qcom use it for drive-strength I think?
> 
> +#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. I copied the entire enum
for completeness. But if we were to go with this approach,
having one for (in|out)put-*, where only having one of them
at a time makes sense could be beneficial too..

Konrad
> 
> Yours,
> Linus Walleij