Re: [PATCH 0/4] PCI legacy I/O port free driver (take4)

[Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>]

Russell King wrote:
> On Thu, Mar 02, 2006 at 10:24:36AM -0700, Grant Grundler wrote:
>
> > On Thu, Mar 02, 2006 at 03:50:57PM +0000, Russell King wrote:
> >
> > > I've been wondering whether this "no_ioport" flag is the correct approach,
> > > or whether it's adding to complexity when it isn't really required.
> >
> > I think it's the simplest solution to allowing a driver
> > to indicate which resources it wants to use. It solves
> > the problem of I/O Port resource allocation sufficiently
> > well.
>
>
> I have another question (brought up by someone working on a series of
> ARM machines which make heavy use of MMIO.)
>
> Why isn't pci_enable_device_bars() sufficient - why do we have to
> have another interface to say "we don't want BARs XXX" ?
>
> Let's say that we have a device driver which does this sequence (with,
> of course, error checking):
>
> 	pci_enable_device_bars(dev, 1<<1);
> 	pci_request_regions(dev);
>
> (a) should PCI remember that only BAR 1 has been requested to be enabled,
>     and as such shouldn't pci_request_regions() ignore BAR 0?
>
> (b) should the PCI driver pass into pci_request_regions() (or even
>     pci_request_regions_bars()) a bitmask of the BARs it wants to have
>     requested, and similarly for pci_release_regions().
>
> Basically, if BAR0 hasn't been enabled, has pci_request_regions() got
> any business requesting it from the resource tree?

Hmm, pci_enable_device_bars() approach looks better and better to me.
If we use this approach, we need to consider which (a) and (b) we
should use, as you said.

The (b) option looks natural to me because pci_enable_device_bars() and
pci_request_regions_bars() becomes a pair. But the (b) option would have
a problem at resume time. If the driver doesn't have .resume() method,
default resume routine (i.e. pci_default_resume()) will be called, and
it calls pci_enable_device().

The (a) option doesn't have this kind of problem. But it looks a little
strange to me that we use pci_enable_device_bars() at probe time while
we use pci_enable_device() at resume time, though I might be too anxious.

To tell the truth, I've considered this before. I could not come up with
which is better between (a) and (b), and then I posted another approach
which introduce a new API. Now I came back to this approach again. Maybe
I'm being caught by the endless loop...

I would very much appreciate giving me any comments about (a) and (b).

Thanks,
Kenji Kaneshige
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/