linux-kernel - Re: [PATCH 4/7] gpiolib: implement dev_gpiochip

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]

Date:	Wed, 22 Oct 2008 23:06:01 -0700
From:	David Brownell <david-b@...bell.net>
To:	benh@...nel.crashing.org
Cc:	avorontsov@...mvista.com, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org, i2c@...sensors.org,
	Jean Delvare <khali@...ux-fr.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls

On Wednesday 22 October 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
> > > So if we register the board infos after 
> > > the controller registered, then nobody will probe the board infos.
> > 
> > See above.  If you're doing it right, there's no problem.
> > That is, scan the OF tables early.  Just like PNP tables
> > get scanned early, for example.
> 
> It's still pretty yucky in that case to scan the device-tree to convert
> it into some kind of fugly board info ... I'd rather have the end
> drivers that actually use those GPIOs scan the device-tree directly.

Keep in mind that these problems are not specific to GPIOs.

And, very important!!, most of the drivers run without OF...

Pretty much any little device that needs board-specific
customization has the same class of problems:  drivers
will need a variety of parameters that may are often not
sharable with other devices, with idiosyncratic usage.
And they hook up to other drivers in arbitrary ways.

When PCs have such issues, ACPI hides them from Linux.

If those parameters -- potentially including callbacks
that escape to FORTH -- are stored in the OF device tree,
so be it.  But "fugly" sounds like part of that problem
domain, so it's no surprise that it maps onto the solution
space too...

Specifically with respect to GPIOs ... what do you mean
by "end driver" though?  I previously pointed at one
example (Davinci EVM) where one bank of GPIOs is used
by about six different drivers ... none of which have
any reason to know they're using a pcf8574a vs any other
kind of GPIO.  Is the "end driver" the IDE/CF driver?
The USB OTG driver?  The driver sitting the next layer
above of one of those?  *Some* of the drivers need to
touch the GPIOs.  Others don't.

> But then, I'm not a believer in generic drivers for things
> like GPIOs, i2c devices, etc.. :-)

I kind of like being able to re-use code myself.  ;)

It's a win to have *one* pcf8574/5 driver that can be
reused -- with a bit of care configuring it into the
system -- instead of having every board contribute yet
another board-specific hack in drivers/i2c/chips ...

And I think such stuff can be done even with OF.

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