linux-kernel - Re: [PATCH v10 1/2] dt-bindings: pinctrl: mt8195: add rsel define

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] [day] [month] [year] [list]

Message-ID: <CAGXv+5EUAVFJd7VZsDgpOK_6fhs12ztwKHioghq5ZQHzFKY89w@mail.gmail.com>
Date:   Wed, 18 Aug 2021 14:25:54 +0800
From:   Chen-Yu Tsai <wenst@...omium.org>
To:     "zhiyong.tao" <zhiyong.tao@...iatek.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Sean Wang <sean.wang@...nel.org>,
        srv_heupstream <srv_heupstream@...iatek.com>,
        hui.liu@...iatek.com, Eddie Huang <eddie.huang@...iatek.com>,
        Light Hsieh <light.hsieh@...iatek.com>,
        Biao Huang <biao.huang@...iatek.com>,
        Hongzhou Yang <hongzhou.yang@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Seiya Wang <seiya.wang@...iatek.com>,
        Devicetree List <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v10 1/2] dt-bindings: pinctrl: mt8195: add rsel define

On Wed, Aug 18, 2021 at 4:09 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Tue, Aug 17, 2021 at 9:51 AM zhiyong.tao <zhiyong.tao@...iatek.com> wrote:
>
> > In one chip, If GPIO is different, the MTXXXX_PULL_UP_RSEL_001 may
> > means different actual bias resistance setting.
> >
> > For example,
> >
> > KPROW IO
> > Paramters       Descriptions                   Min      Typ     Max
> >  UNIT
> > Rpd     Input pull-down resistance      40      75      190     Kohm
> > Rpu     Input pull-up resistance        40      75      190     Kohm
> > Rpd     Input pull-down resistance      0.8     1.6     2       Kohm
> > Rpu     Input pull-up resistance        0.8     1.6     2       Kohm
>
> This is exactly why we should try to use SI units in the device tree.
> I assume that the software can eventually configure which resistance
> it gets?
>
> The electronics people will say make sure it is pulled down by around
> 80 kOhm, they can put that on the device tree and your code can
> say, "hm 40 < 80 < 190 this is OK" and let the value pass.
>
> We do not define these exact semantics, it is up to the driver code
> to decide what to do with the Ohm value 80000 in this case, but
> it makes perfect sent for me to let it pass and fail if someone
> for example requests 20 kOhm, or at least print a helpful warning:
>
> dev_warn(dev, "the requested resistance %d is out of range, supported
> range %d to %d kOhm\n",
>                  val, low, high);
>
> This is what makes the SI units really helpful for people writing device
> trees: solve real integration tasks and make it easy to do the right thing.

I think this makes a lot of sense. The driver could select the closest
setting. And from what Zhiyong mentioned offline, the resistor values
aren't exact as specified in the datasheet. I suppose this is expected
with any electronics. So the hardware integration will say to pull up
or down by some value, and the driver will do its best to fulfill that
request. That precludes DT schema checking for the values used, but I
think that is a good compromise.

Zhiyong also mentioned that some of their downstream integrators might
not be able to deal with actual values, and would prefer symbols tied
to specific RSEL values. I think that would be doable together using
some _magic_ values, but I would prefer not to if it were avoidable.


Regards
ChenYu