[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1473307105.10397.23.camel@aj.id.au>
Date: Thu, 08 Sep 2016 13:28:25 +0930
From: Andrew Jeffery <andrew@...id.au>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Joel Stanley <joel@....id.au>,
Alexandre Courbot <gnurou@...il.com>,
Mark Rutland <mark.rutland@....com>,
Rob Herring <robh+dt@...nel.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Jeremy Kerr <jk@...abs.org>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs
On Wed, 2016-09-07 at 16:50 +0200, Linus Walleij wrote:
> On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery <andrew@...id.au> wrote:
>
> >
> > The Aspeed SoCs typically provide more than 200 pins for GPIO and other
> > functions. The signal enabled on a pin is determined on a priority
> > basis, where a given pin can provide a number of different signal types.
> >
> > In addition to the priority levels, the Aspeed pin controllers describe
> > the signal active on a pin by compound logical expressions involving
> > multiple operators, registers and bits. Some difficulty arises as a
> > pin's function bit masks for each priority level are frequently not the
> > same (i.e. we cannot just flip a bit to change from a high to low
> > priority signal), or even in the same register(s). Some configuration
> > bits affect multiple pins, while in other cases the signals for a bus
> > must each be enabled individually.
> >
> > Together, these features give rise to some complexity in the
> > implementation. A more complete description of the complexities is
> > provided in the associated header file.
> >
> > The patch doesn't implement pinctrl/pinmux/pinconf for any particular
> > Aspeed SoC, rather it adds the framework for defining pinmux
> > configurations.
> >
> > Signed-off-by: Andrew Jeffery <andrew@...id.au>
> > Reviewed-by: Joel Stanley <joel@....id.au>
> Patch applied! It's not getting better than this through iteration, it is better
> to get the system up and develop inside the mainline tree from now on.
>
> >
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1027,6 +1027,7 @@ S: Maintained
> > F: arch/arm/mach-aspeed/
> > F: arch/arm/boot/dts/aspeed-*
> > F: drivers/*/*aspeed*
> > +F: drivers/pinctrl/aspeed/
> > F: Documentation/devicetree/bindings/*/*aspeed*
> I dropped this hunk of the patch, because:
>
> (A) I didn't merge the glob patch and
Okay
> (B) the glob covers this driver too, it is a tautology/truism
So experimenting with this my results don't agree - without the hunk
get_maintainer.pl falls back to git and s-o-bs to pick up the Aspeed
maintainer:
With the hunk:
$ ./scripts/get_maintainer.pl drivers/pinctrl/aspeed/pinctrl-aspeed.c
Joel Stanley < joel@....id.au > (maintainer:ARM/ASPEED MACHINE SUPPORT)
Linus Walleij < linus.walleij@...aro.org > (maintainer:PIN CONTROL SUBSYSTEM)
linux-gpio@...r.kernel.org (open list:PIN CONTROL SUBSYSTEM)
Without the hunk:
$ ./scripts/get_maintainer.pl drivers/pinctrl/aspeed/pinctrl-aspeed.c
Linus Walleij < linus.walleij@...aro.org > (maintainer:PIN CONTROL SUBSYSTEM)
Joel Stanley < joel@....id.au > (commit_signer:1/1=100%)
Andrew Jeffery < andrew@...id.au > (commit_signer:1/1=100%,authored:1/1=100%,added_lines:498/498=100%)
linux-gpio@...r.kernel.org (open list:PIN CONTROL SUBSYSTEM)
linux-kernel@...r.kernel.org (open list)
So removing git as a fallback Joel isn't listed as a relevant
maintainer despite the glob:
$ ./scripts/get_maintainer.pl --no-git-fallback drivers/pinctrl/aspeed/pinctrl-aspeed.c
Linus Walleij < linus.walleij@...aro.org > (maintainer:PIN CONTROL SUBSYSTEM)
linux-gpio@...r.kernel.org (open list:PIN CONTROL SUBSYSTEM)
linux-kernel@...r.kernel.org (open list)
I expect it's the case that the globbing doesn't match directories like
the hunk in question does with its trailing '/'. However, given we will
likely do something different in light of Arnd's suggestion it probably
doesn't matter.
Cheers,
Andrew
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists