linux-kernel - Re: [PATCH 02/12] Blackfin arch: Add label to call new GPIO API

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: <8bd0f97a0708171245j74e856e0uce009de16c00f517@mail.gmail.com>
Date:	Fri, 17 Aug 2007 15:45:36 -0400
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"David Brownell" <david-b@...bell.net>
Cc:	"Bryan Wu" <bryan.wu@...log.com>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	"Michael Hennerich" <michael.hennerich@...log.com>
Subject: Re: [PATCH 02/12] Blackfin arch: Add label to call new GPIO API

On 8/17/07, David Brownell <david-b@...bell.net> wrote:
> Again, the patch descriptions need work.  This changes the
> IRQ code (to add those labels).  $SUBJECT doesn't mention IRQs,
> neither does the description ...
>
>
> On Tuesday 07 August 2007, Bryan Wu wrote:
> > --- a/arch/blackfin/mach-common/ints-priority-dc.c
> > +++ b/arch/blackfin/mach-common/ints-priority-dc.c
> > @@ -221,7 +221,7 @@ static unsigned int bf561_gpio_irq_startup(unsigned int irq)
> >
> > if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
> >
> > -ret = gpio_request(gpionr, NULL);
> > +ret = gpio_request(gpionr, "IRQ");
> > if (ret)
> > return ret;
> >
> > @@ -261,7 +261,7 @@ static int bf561_gpio_irq_type(unsigned int irq, unsigned int type)
> >
> > if (!(gpio_enabled[gpio_bank(gpionr)] & gpio_bit(gpionr))) {
> >
> > -ret = gpio_request(gpionr, NULL);
> > +ret = gpio_request(gpionr, "IRQ");
> > if (ret)
> > return ret;
> >
>
> Just for the record, this is an unusual way to use these calls.
>
> Other platforms completely decouple these issues from the
> IRQ infrastructure ... doing the pinmux and gpio claiming
> separately from the request_irq()/free_irq() paths, mostly
> as part of board setup.  Doing all of that "early":
>
>  - keeps those error returns from causing hard-to-track-down
>    runtime bugs;
>
>  - works always, even on platforms where a given IRQ may
>    appear on any of several pins/balls;
>
>  - makes it easier to cross-check against board schematics,
>    by keeping most board-specific setup in one source file;
>
>  - shrinks the kernel's runtime footprint;
>
>  - allows the label to be more descriptive ... describeing
>    exactly *which* IRQ, so that using the labels for better
>    diagnostics actually gives better diagnostics.
>
> Again, not "wrong"; but probably sub-optimal.  You might
> want to move towards earlier binding now, while Linux is
> still young on Blackfin and you don't have legacy code to
> worry about.

in the Blackfin port, if you want to use a pin as an IRQ rather than
GPIO, you use the normal request_irq/free_irq API ... those functions
will call back into the proper GPIO/PORTMUX code so that the pin is
setup properly.  this is done so that code isnt duplicated across
files and so that we can easily detect if someone does something
incorrect like try to take the same pin and use it as
irq/gpio/whatever at the same time ...

are you saying that other ports dont unify the backend code paths at all ?
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/