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

Message-ID: <20160908073748.GF8913@lukather>
Date:   Thu, 8 Sep 2016 09:37:48 +0200
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Chen-Yu Tsai <wens@...e.org>
Cc:     Linus Walleij <linus.walleij@...aro.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

On Thu, Sep 08, 2016 at 12:46:14PM +0800, Chen-Yu Tsai wrote:
> > I mean it like supporting these in *addition* to the custom ones, so there can
> > be a smooth phase-over.
> >
> > Check for example Laurent's commit for SH-PFC:
> > commit 16ccaf5bb5a52372bfebd3dfbb79dd810ad49c09
> > "pinctrl: sh-pfc: Accept standard function, pins and groups properties"
> > It's awesome, and since, they have improved the looks of Renesas
> > DTS files a lot.
> >
> > It could look a bit like this nice thing from
> > lpc4337-ciaa.dts:
> >
> > &pinctrl {
> >         enet_rmii_pins: enet-rmii-pins {
> >                 enet_rmii_rxd_cfg {
> >                         pins = "p1_15", "p0_0";
> >                         function = "enet";
> >                         slew-rate = <1>;
> >                         bias-disable;
> >                         input-enable;
> >                         input-schmitt-disable;
> >                 };
> >
> >                 enet_rmii_txd_cfg {
> >                         pins = "p1_18", "p1_20";
> >                         function = "enet";
> >                         slew-rate = <1>;
> >                         bias-disable;
> >                         input-enable;
> >                         input-schmitt-disable;
> >                 };
> > (etc)
> 
> This looks nice.

Indeed.

> I've slightly looked at the generic pinconf stuff.  I think we
> should be able to support them, though the sunxi pinctrl driver
> currently doesn't work well with it though. For example, it doesn't
> declare ".is_generic = true", it doesn't filter unsupported pinconf
> parameters, and it doesn't reply to queries correctly. I will fix
> these bits.
> 
> 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.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)