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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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