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

Message-ID: <CAGXv+5GCuNK=-z9VAOjkpJdZLUSZFPfUsQ09m1FhfTsbCYLLRw@mail.gmail.com>
Date:   Mon, 16 Aug 2021 23:37:51 +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 Mon, Aug 16, 2021 at 6:48 PM zhiyong.tao <zhiyong.tao@...iatek.com> wrote:
>
> On Mon, 2021-08-16 at 14:10 +0800, Chen-Yu Tsai wrote:
> > On Thu, Aug 5, 2021 at 7:02 AM Linus Walleij <
> > linus.walleij@...aro.org> wrote:
> > >
> > > On Thu, Jul 29, 2021 at 11:43 AM Chen-Yu Tsai <wenst@...omium.org>
> > > wrote:
> > > > On Thu, Jul 29, 2021 at 4:23 PM zhiyong.tao <
> > > > zhiyong.tao@...iatek.com> wrote:
> > > > > The rsel actual bias resistance of each setting is different in
> > > > > different IC. we think that the define "MTK_PULL_SET_RSEL_000"
> > > > > is more
> > > > > common for all different IC.
> > > >
> > > > I see. I personally prefer having things clearly described. I can
> > > > understand this might be an extra burden to support different
> > > > chips
> > > > with different parameters, though this should be fairly
> > > > straightforward
> > > > with lookup tables tied to the compatible strings.
> > > >
> > > > Let's see if Rob and Linus have anything to add.
> > >
> > > Not much. We have "soft pushed" for this to be described as generic
> > > as possible, using SI units (ohms). But we also allow vendor-
> > > specific
> > > numbers in this attribute. Especially when reverse engineering SoCs
> > > that the contributor don't really have specs on (example M1 Mac).
> > >
> > > The intent with the SI units is especially for people like you
> > > folks working
> > > with Chromium to be able to use different SoCs and not feel lost
> > > to a forest of different ways of doing things and associated
> > > mistakes because vendors have hopelessly idiomatic pin configs.
> >
> > I'll take that as "use SI units whenever possible and reasonable".
>
> ==> so It doesn't need to change the define, is it right?
> we will keep the common define.

Actually I think it would be possible and reasonable to use SI units
in this case, since you are the vendor and have the resistor values
to implement the support. Having different sets of values for different
chips is nothing out of the ordinary. We already have to account for
different number of pins and different pin functions. That is what
compatible strings are for.

Now if you have _many_ different sets of values within the same chip,
that could make things more difficult. However the clearness of having
the real values visible in the device tree would likely benefit both
software and hardware engineers outside of Mediatek. That is what we
should be aiming for.


Regards
ChenYu