[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47C7FA8B.7040306@gmail.com>
Date: Fri, 29 Feb 2008 21:28:59 +0900
From: Tejun Heo <htejun@...il.com>
To: Jeff Garzik <jeff@...zik.org>
CC: Alan Cox <alan@...rguk.ukuu.org.uk>,
Linux IDE mailing list <linux-ide@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: devres and requesting resources
Jeff Garzik wrote:
> Only rare PCI devices are shareable among multiple drivers.
>
> sata_* at least intentionally used pci_request_regions() because it is
> obvious from the hardware spec that multiple regions accessed by
> multiple drivers is highly unlikely, without the driver being
> specifically coded to support such sharing. Such sharing code is far
> beyond simple resource reservation, to avoid stepping on toes when there
> is a single MMIO region and set of interrupt clearing registers.
>
> So reading your email it sounds like there are valid cases for both
> configurations.
>
> Its a design choice either way, not a bug either way.
I was thinking like Alan when I was writing pcim_request_regions() but I
agree reserving all the regions does avoid certain problems. Especially
true for controller which duals as native SATA and compatible SFF
controller like ICH AHCIs. ata_generic or ide generic might attach to a
controller which is already being driven by ahci under certain
configurations.
Please note that pcim_request_regions() is a helper to do
pci_request_region() calls and pcim_iomap() in one go. Drivers which
have different requirements can just open code pci_request_regions() and
pcim_iomap(). pcim_request_regions() should provide sensible default
behavior for common cases.
I think the best solution is to allow duplicate request regions for
managed devices which is okay as we know we're holding the resource and
let drivers which need to reserve all regions call pci_request_regions()
before calling pcim_request_regions().
How does it sound?
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists