linux-kernel - Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

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: <CAGb2v66YUOcHXkE521zXNOmqCJ60oJ7+LQA=LS371ZPdEXdrqg@mail.gmail.com>
Date:   Wed, 14 Sep 2016 10:56:56 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        Mylene Josserand <mylene.josserand@...e-electrons.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Alexander Kaplan <alex@...tthing.co>
Subject: Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

Hi Linus,

On Mon, Sep 12, 2016 at 8:40 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Sep 8, 2016 at 9:37 AM, Maxime Ripard
> <maxime.ripard@...e-electrons.com> wrote:
>> On Thu, Sep 08, 2016 at 12:46:14PM +0800, Chen-Yu Tsai wrote:
>
>>> Also, I think we are needlessly using pin groups, 1 pin per group.
>>> Can pinconf/pinctrl work without them? Would there be any harm
>>> converting the sunxi driver to work directly with pins? This would
>>> make it match generic pinconf parsing, and make it easier to get
>>> both working together.
>>
>> I think it comes from a requirement that you had to have groups at
>> some point (I don't know if it's still the case), which is why we
>> ended up with single-pin groups, because we can mux each pins entirely
>> separately.
>>
>> If it's not required anymore, then yes, it makes total sense to remove
>> it.
>
> The groups vs individual pins is an eternal debate that has
> been going on since the inception of pinctrl.
>
> If you see it from the point of the programmer, you may just see
> a register for each pin and they seem all independent. This is
> why pinctrl-single exist, and that driver is for this purpose: one
> register per pin, software-wise independent.
>
> HOWEVER it often turns out that while you can programmatically
> and individually set pins to any function (and biasing etc), the
> person designing the hardware was not thinking that you should
> be able to do whatever you like, e.g. even if it is possible to
> take two pins and use one of them for half an SPI bus and the
> other for half an I2C bus, that doesn't mean that this is useful
> or makes any kind of electronic sense, it just makes "software
> sense".
>
> So for a deeper understanding, several SoCs (amongst them
> my own and Qualcomm etc) define groups that are not really
> about software restrictions for what you can do with the pins, but
> about usecase and electronic restrictions for what can be done
> with the pins.
>
> E.g. it makes *sense* to have a group for muxing I2C on two
> pins, and not allow one of them to be muxed to I2C and the other
> not, because it does not make electronic sense.
>
> One-group-per-pin groups is usually coming from a failure or
> inability to identify these electronically sound and usecase
> oriented pingroups.
>
> Some (like pinctrl-single) say they don't care, and wish to
> see things as the world is just software and one register per
> pin, removing those electric usecase restrictions, and only
> keeping the muxing restrictions to e.g. the four different functions
> that can be muxed on that pin, disregarding the bigger picture.
>
> I don't know about this driver or the pins it manages,
> I seldom have time or brains to dive in and review things
> deeply enough :(

Thanks for the explanation. I suppose sunxi falls into the "don't
care" group. We mainly enforce proper use cases through the DT
pinmux settings. Of course this doesn't prevent the user from
using weird settings out of tree, but then again what's preventing
them from hacking the kernel anyway.

Back to my original question: is it possible to drop the pin group
support completely? Looking at struct pinctrl_ops the answer seems
to be no.

Regards
ChenYu