linux-kernel - Re: [PATCH] gpio: New driver for the Intel 82801 (ICH) GPIO pins

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=tzXyozCck9H03-2RErGsvSxrv1Q@mail.gmail.com>
Date:	Tue, 19 Apr 2011 09:05:44 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpio: New driver for the Intel 82801 (ICH) GPIO pins

On Tue, Apr 19, 2011 at 8:54 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> In this particular case, you've got a PCI device which looks to be
>> going into config space to get some information about how the chip is
>> layed out.  What I would do is keep your existing pci probe & remove
>> hooks, but use them to create and register child basic_mmio_gpio
>> platform_devices for each gpio bank.
>
> That means more devices, weird sysfs heirarchies and lots of mess with
> runtime power management in the general case.
>
> If the basic_mmio_gpio code is properly abstracted it ought not to need
> magic extra platform devices.
>
> That aside it'll be less code to keep it separate than do all the messing
> around with platform devices so it seems to be a gross overdoing of 'lets
> make everything use the same code however big a hammer is needed'
>
> If it was a platform device it might make sense, if the config was
> platform config to create a device it would certainly make sense, in the
> PCI case it's smaller, cleaner and saner not to add insane layers of glue
> and indirection IMHO.

Doing a platform device is one solution that is pretty simple to
implement and I don't think adding child devices is at all a problem.
However, I'm not mandating that approach, and if you or Jean prefer to
abstract out the gpio accessors from basic_mmio_gpio(), then that is
fine by me.  The key issue it to avoid merging yet another, probably
subtly broken, set of GPIO accessor functions if it can at all be
avoided.

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