linux-kernel - Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

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: <200611131215.39888.david-b@pacbell.net>
Date:	Mon, 13 Nov 2006 12:15:39 -0800
From:	David Brownell <david-b@...bell.net>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>, jamey.hicks@...com,
	Kevin Hilman <khilman@...sta.com>,
	Nicolas Pitre <nico@....org>,
	Russell King <rmk@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Monday 13 November 2006 11:43 am, Bill Gatliff wrote:
> >
> >This API absolutely allows for multiple GPIO controllers ... all it does
> >is say "here are the numbers, handle them".  The platform's implementation
> >of the API is allowed to map to the relevant controller.
> 
> I think what Paul is saying here is that because your reference 
> implementation was "arch-omap" instead of "board-<something>", if I add 
> a PLD with some MMIO GPIO lines then I have to hack global OMAP code.  

Well, "example" implementation.

Linux doesn't handle PLDs as well as it might.  One example in the current
kernel is the original PXA reference platform, Intel's "Lubbock".  It's got
an FPGA with essential IRQs.  Look at the mess involved in coupling those
IRQs into the system ... not just adding a new irq_chip (easy!), but the
way the global PXA IRQ headers need to know about it.

Part of this is just that NR_IRQs is a global constant, and it's not
possible to allocate new IRQ banks after a kernel is built.  Like by
plugging in a few I2C chips with IRQ-capable GPIOs ...

Now, I think the way OMAP handles GPIOs could handle "add an FPGA" pretty
cleanly.  That is admittedly a platform-specific implementation issue ...
but then, so is "add an FPGA".  And in any case, It should be very clear
that such implementation issues don't need to affect the API, and that
right now only the API is being proposed.

> Maybe we should codify an approach for that now, i.e. add to the 
> reference implementation some code that hands off out-of-range GPIO 
> lines to a function in the machine descriptor:
> 
> 
> +static inline int gpio_direction_input(unsigned gpio)
> +	{ if (gpio < OMAP_MAX_ARCH_GPIO) return __gpio_set_direction(gpio, 1);
> +	  else if(mdesc->platform_gpio_set_direction) platform_gpio_set_direction(gpio, 1); }
> 
> 
> ... conveniently neglecting the way you find mdesc.  :)

Nah; look at arch/arm/plat-omap/gpio.c and ignore the mess, but observe
that what you see there is essentially a bunch of "gpio controller"
classes using the ugly "switch(type)" dispatch scheme instead of the
prettier "type->op()" dispatch scheme.  All that stuff needs to be
cleaner, but for now it'd suffice to add a new FPGA typecode.

> I do have a question now.  Is there any reason to consider shared GPIO 
> lines?  If so, then the request_gpio() would need a flag GPIO_SHARED or 
> something.

If two drivers agree to share a line -- how, why? -- they can come to a
private agreement.  We lack even a good example of why drivers would
want to share, much less knowledge that it's a general problem!

- Dave

-
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/