LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux IDE mailing list <linux-ide@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: devres and requesting resources
Date: Fri, 29 Feb 2008 21:28:59 +0900	[thread overview]
Message-ID: <47C7FA8B.7040306@gmail.com> (raw)
In-Reply-To: <47C7F664.5040102@garzik.org>

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

  reply	other threads:[~2008-02-29 12:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  0:36 Jeff Garzik
2008-02-29 11:26 ` Alan Cox
2008-02-29 12:11   ` Jeff Garzik
2008-02-29 12:28     ` Tejun Heo [this message]
2008-02-29 14:01       ` Alan Cox
2008-02-29 14:17         ` Tejun Heo
2008-02-29 19:25           ` Jeff Garzik
2008-02-29 17:04         ` Bartlomiej Zolnierkiewicz
2008-02-29 17:04           ` Alan Cox
2008-02-29 13:55     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47C7FA8B.7040306@gmail.com \
    --to=htejun@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: devres and requesting resources' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).