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:	Mon, 20 Oct 2008 19:48:35 +0400
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	David Brownell <david-b@...bell.net>
Cc:	linux-kernel@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	"Steven A. Falco" <sfalco@...ris.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Jean Delvare <khali@...ux-fr.org>,
	David Miller <davem@...emloft.net>, i2c@...sensors.org,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls

On Mon, Oct 20, 2008 at 12:29:57AM -0700, David Brownell wrote:
[...]
> > Anyway most of them need some modifications to work with OF...
> 
> The changes I saw were just to cope with not having
> the system-specific platform_data provided:  don't
> fail if that pointer is NULL, and arrange for dynamic
> allocation of some GPIO numbers.
> 
> With OpenFirmware, presumably the implication is that
> the relevant data is in the OF device tree...

Yes. Some data is in the device tree.

> I think that it *barely* makes sense to allow the chips
> to bind to drivers without platform data when there's
> not even OF in the environment. ONLY in the case where
> the GPIOs are exported through sysfs, in fact, since
> otherwise there's no way for other system components
> to know those GPIOs even exist!!  And even that seems
> pretty marginal to me...

Platform data is a completely different story. And yes, we can't
handle it properly with the device tree. By "properly" I mean without
adding an explicit OF stuff to the drivers, i.e. we should handle the
pdata transparently to the existing drivers.

I quite like the bus notifiers approach:

http://lkml.org/lkml/2008/6/5/209  (mmc_spi example)

But it doesn't work as a module (i.e. OF-specific bits should be
always in-kernel).

[...]
> > If you don't like it, I can readily implement hooks for
> > gpiochip_{add,remove}().
> 
> It seems a better way to a clean solution, IMO.

Ok. I will do it.

[...]
> Did you look at providing chip-aware OF glue drivers
> for this stuff?  Doing stuff like just turn the OF
> device properties into the right platform_data, and
> maybe runing FORTH bytecodes to do other configuration
> magic needed...

Yes. Few times already. To make the glue, every driver needs
some modifications, and it is always triggers huge discussions
about how to exactly refactor the driver to make it work with
the OF.

http://lkml.org/lkml/2008/5/23/297 (again mmc_spi example).

-- 
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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/