linux-kernel - Re: [PATCH v3 2/3] pinctrl: core: configure pinmux from pins debug file

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: <1397253066.299778.1623400182022@mail1.libero.it>
Date:   Fri, 11 Jun 2021 10:29:41 +0200 (CEST)
From:   Dario Binacchi <dariobin@...ero.it>
To:     Tony Lindgren <tony@...mide.com>,
        Linus Walleij <linus.walleij@...aro.org>
Cc:     Vladimir Zapolskiy <vz@...ia.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Drew Fustini <drew@...gleboard.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] pinctrl: core: configure pinmux from pins debug
 file

Hi,

> Il 02/06/2021 07:03 Tony Lindgren <tony@...mide.com> ha scritto:
> 
>  
> * Linus Walleij <linus.walleij@...aro.org> [210528 09:08]:
> > On Thu, May 27, 2021 at 10:33 PM Dario Binacchi <dariobin@...ero.it> wrote:
> > > > Il 27/05/2021 21:57 Vladimir Zapolskiy <vz@...ia.com> ha scritto:
> > 
> > > > Unfortunately you continue to cling to the broken interface, while I see no
> > > > comments from you about asked to consider pin groups and pin group functions.
> > >
> > > Could you kindly explain to me, with some practical examples, what kind of interface
> > > would you implement ?
> > 
> > I am not fully understanding this discussion.
> > 
> > I get the feeling that this is caused by the early architectural decisions with
> > pinctrl-single to put all configuration of pin groups and functions per pin into
> > the device tree.
> >
> > Tony specifically wanted this because what he gets from TI are some raw
> > ASIC data dumps from the designers, that he could make a script to process
> > into device tree rather than into .h files, and get this out of the kernel.
> > (As I remember it, Tony correct me if I'm wrong.)
> 
> Yeah the idea was to avoid stuffing even more SoC specific data into the
> kernel and rather use devicetree data only for the booted SoC.
>  
> > This makes it hard to align some concepts of the pin control subsystem such
> > as functions and groups because pinctrl-single assume a 1-to-1 mapping
> > between one pin and one group, which in turn has a 1-to-many mapping
> > to functions.
> > 
> > Is the patch trying to debugfs around this somehow?
> > 
> > If this hack is only needed for pinctrl-single.c then it should be placed in
> > that driver, so Tony can review it and maintain it as applicable in that
> > driver's context only, not in the pinctrl core as it appears the general
> > applicability for other drivers is not there.
> > 
> > Would this really be useful for other drivers than pinctrl-single.c?
> 
> I'd rather go with a generic interface. I think it should work if we only
> allow enabling and disabling of unclaimed pingroups from sysfs. And then
> we can also allow creating new pingroups for unclaimed pins if needed.
> 

Could you kindly explain to me, with some practical examples, what kind of interface
would you implement ? Or something similar to start from that is already in the Kernel?

Thanks and regards,
Dario

> Regards,
> 
> Tony