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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 19 Apr 2011 15:54:06 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Grant Likely <grant.likely@...retlab.ca>
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

> I'm not at all concerned about this.  Users *must* know what a pin is
> when they start fiddling with it.  If you ask a pin to do something
> that it cannot do, then it just isn't going to work.  There's no real
> point in trying to enforce any behaviour in the API.

Disagree 8) - errors are better than silently and undetectably failing.
That might not be an error code but ideally it would WARN() or
similar so that errors get caught and fixed and you don't instead find
out something was poking the wrong pin and worked by chance a year later.

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

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