Re: [PATCHv3 0/7] gpio: extend basic_mmio_gpio for differentcontrollers

[Anton Vorontsov]

On Tue, May 03, 2011 at 11:04:08PM +0100, Jamie Iles wrote:
[...]
> The advantage that Grant's proposal has though is that the user can 
> override the gpio_chip callbacks.  When I tried porting over some 
> existing ARM platforms, one of the blocking issues was that lots of 
> platforms had some annoying small detail that was slightly different 
> (such as doing muxing in the _get() callback or needing a to_irq 
> callback).
> 
> If we make bgpio_chip public and return that from bgpio_probe 
> unregistered then the calling code can override some of the methods then 
> register the gpio_chip.

Oh, that makes sense, right.

> As a slight aside, if we don't want a platform_device per bank for 
> devices with multiple banks then I don't think the named resource 
> approach will work (at least I can't see a particularly nice mechanism).  
> Any ideas?

I think Grant misunderstood Alan's words. If a PCI device registers
platform devices to represent each of PCI device's banks -- that is not
good. It's waste of devices, complicates sysfs/device heirarchy and so
on. And that's why bgpio_probe() thing started, to not create platform
devices when you already have one.

But personally I think it's OK for platforms (arch/ code) to register
each bank as a separate device. In some cases, that describes hardware
even better. And that makes life easier for device-tree stuff as well.

And if you really don't want this behaviour for your platform, you can
create your own driver that would use "bgpio library", and would
register several banks for a single device (as in PCI case).

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/