linux-kernel - Re: [PATCH v2 0/3] Renesas R9A06G032 PINCTRL Driver

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: <CACRpkdaVXiE70Ux_-idKz6ovgGz1KEZ7qau-i_3FpN_q=w5npQ@mail.gmail.com>
Date:   Mon, 10 Sep 2018 09:45:44 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     jacopo <jacopo@...ndi.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Cc:     Phil Edworthy <phil.edworthy@...esas.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Simon Horman <horms@...ge.net.au>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] Renesas R9A06G032 PINCTRL Driver

On Mon, Sep 3, 2018 at 1:25 PM jacopo mondi <jacopo@...ndi.org> wrote:
> On Mon, Sep 03, 2018 at 11:03:18AM +0000, Phil Edworthy wrote:
> > On 03 September 2018 11:34, jacopo mondi wrote:
> > > On Thu, Aug 30, 2018 at 02:12:52PM +0100, Phil Edworthy wrote:
> > > > This implements the pinctrl driver for the RZ/N1 family of devices, including
> > > > the R9A06G032 (RZ/N1D) device.
(...)
> > > Using standard pinctroller bindings pin configuration properties:
> > >
> > >          &pinctrl {
> > >                  pinsuart0: uart0  {
> > >                         pinsuart_tx0 {
> > >                                 pinmux = <103, UART0_I>;  /* UART0_TXD */
> > >                         };
> > >
> > >                         pinsuart_rx0 {
> > >                                  pinmux = <104, UART0_I>; /* UART0_RXD */
> > >                                  bias-pull-up;
> > >                         };
> > >                  };
> > >          };
> > >
> > > Is there anything I am missing? Maybe from the interaction with
> > > "another OS/core running concurrently" you mentioned? In this case if
> > > you only have to perform pin configuration (because muxing is handled
> > > already) things are even simpler, just use the pin configuration
> > > bindings, without involving muxing at all:
> > >
> > >         &pinctrl {
> > >                 pinsuart_conf: uart0 {
> > >                         pins = <103, 104>;
> > >                         bias-pull-up;
> > >                  };
> > >          };
> >
> > Sorry I didn’t address your point.
> > The only reason we want to use new properties is so the driver can process
> > dts files that have been generated from an existing PinMux App. That output
> > is used by VxWorks as well as our out-of-tree Linux port. If that is not a
> > good enough reason to add new properties, then I can't see any technical
> > reason not to use the existing bindings.
>
> I see. I step back then and let this to be handled by the pinctrl
> subsystem people and maintainer :)

I rely on Geert Uytterhoeven and Laurent Pinchart to tell me
what is best for Renesas.

A good hint is that Geert will merge this driver when finished and
send it to me, so if he's not happy it is unlikely to get merged.
So make sure Geert is happy and I will be happy too.

Geert, as I, likely rely on the DT maintainers to tell me what is
best for DT. But with pinctrl they often pass it back to us.

Yours,
Linus Walleij