On Mon, Feb 14, 2005 at 02:46:38PM -0800, Roland Dreier wrote:
> OK, I'm happy to go along with that (it definitely simplifies my
> driver code). Here's the patch.
>
>
> Remove the call to request_mem_region() in msix_capability_init() to
> grab the MSI-X vector table. Drivers should be using
>
> OTOH this will introduce more buglets to broken drivers which don't
> call pci_disable_device() properly. Consequently, the ad hoc fix to
> each driver like Jeff's patch might be most practical...
This is true but it does provide the mechanism to fix such devices. It
also fails safe because a
At Mon, 14 Feb 2005 21:05:58 -0500,
Jeff Garzik wrote:
>
> Arjan van de Ven wrote:
> >>No. You also need to consider situations such as out-of-tree drivers
> >>for the same hardware (might not use PCI API), and situations where you
> >>have peer devices discovered and used (PCI API doesn't have
Arjan van de Ven wrote:
No. You also need to consider situations such as out-of-tree drivers
for the same hardware (might not use PCI API), and situations where you
have peer devices discovered and used (PCI API doesn't have "hey,
device is associated with , too" capability)
there's not a lot
> No. You also need to consider situations such as out-of-tree drivers
> for the same hardware (might not use PCI API), and situations where you
> have peer devices discovered and used (PCI API doesn't have "hey,
> device is associated with , too" capability)
there's not a lot you or anyone
OK, I'm happy to go along with that (it definitely simplifies my
driver code). Here's the patch.
Remove the call to request_mem_region() in msix_capability_init() to
grab the MSI-X vector table. Drivers should be using
pci_request_regions() so that they own all of the PCI BARs, and the
MSI-X co
Roland Dreier wrote:
Jeff> That's an MSI bug.
Jeff> A current PCI driver -should- be using pci_request_regions().
Hmm... I'm not sure everyone would agree with that. It does make
sense that the MSI-X core wants to make sure that it owns the MSI-X
table without having someone else stomp on
Jeff> That's an MSI bug.
Jeff> A current PCI driver -should- be using pci_request_regions().
Hmm... I'm not sure everyone would agree with that. It does make
sense that the MSI-X core wants to make sure that it owns the MSI-X
table without having someone else stomp on it.
- R.
-
To uns
On Mon, Feb 14, 2005 at 11:58:38AM -0800, Roland Dreier wrote:
> Jeff> * pci_request_regions() should be axiomatic. By that I mean,
> Jeff> pci_enable_device() should
> Jeff> (a) handle pci_request_regions() completely
> Jeff> (b) fail if regions are not available
>
> Ther
Jeff> * pci_request_regions() should be axiomatic. By that I mean,
Jeff> pci_enable_device() should
Jeff> (a) handle pci_request_regions() completely
Jeff> (b) fail if regions are not available
There's one pitfall here: for a device using MSI-X, the MSI-X table is
goin
Takashi Iwai wrote:
At Mon, 14 Feb 2005 11:34:13 -0800,
Greg KH wrote:
On Mon, Feb 14, 2005 at 08:24:29PM +0100, Takashi Iwai wrote:
At Mon, 14 Feb 2005 11:06:19 -0800,
Greg KH wrote:
As a result, I have committed the attached patch to libata-2.6. In many
cases, it is a "semantic fix", addressing
Greg KH wrote:
On Sun, Feb 13, 2005 at 08:42:55PM -0500, Jeff Garzik wrote:
Currently, in almost every PCI driver, if pci_request_regions() fails --
indicating another driver is using the hardware -- then
pci_disable_device() is called on the error path, disabling a device
that another driver is
At Mon, 14 Feb 2005 11:34:13 -0800,
Greg KH wrote:
>
> On Mon, Feb 14, 2005 at 08:24:29PM +0100, Takashi Iwai wrote:
> > At Mon, 14 Feb 2005 11:06:19 -0800,
> > Greg KH wrote:
> > >
> > > > As a result, I have committed the attached patch to libata-2.6. In
> > > > many
> > > > cases, it is a "
On Mon, Feb 14, 2005 at 08:24:29PM +0100, Takashi Iwai wrote:
> At Mon, 14 Feb 2005 11:06:19 -0800,
> Greg KH wrote:
> >
> > > As a result, I have committed the attached patch to libata-2.6. In many
> > > cases, it is a "semantic fix", addressing the case
> > >
> > > * pci_request_regions() i
At Mon, 14 Feb 2005 11:06:19 -0800,
Greg KH wrote:
>
> > As a result, I have committed the attached patch to libata-2.6. In many
> > cases, it is a "semantic fix", addressing the case
> >
> > * pci_request_regions() indicates hardware is in use
> > * we rudely disable the in-use hardwar
> > I'm hoping one or two things will happen now:
> > * janitors fix up the other PCI drivers along these lines
> > * improve the PCI API so that pci_request_regions() is axiomatic
>
> Do you have any suggestions for how to do this?
One would be to keep an "enabler" count.
If the device is enabl
On Sun, Feb 13, 2005 at 08:42:55PM -0500, Jeff Garzik wrote:
>
> Currently, in almost every PCI driver, if pci_request_regions() fails --
> indicating another driver is using the hardware -- then
> pci_disable_device() is called on the error path, disabling a device
> that another driver is usi
On Mon, Feb 14, 2005 at 11:43:02AM +0100, Michal Rokos wrote:
> Hello,
>
> > Currently, in almost every PCI driver, if pci_request_regions() fails --
> > indicating another driver is using the hardware -- then
> > pci_disable_device() is called on the error path, disabling a device
> > that ano
Hello,
> Currently, in almost every PCI driver, if pci_request_regions() fails --
> indicating another driver is using the hardware -- then
> pci_disable_device() is called on the error path, disabling a device
> that another driver is using
>
> To call this "rather rude" is an understatement
Currently, in almost every PCI driver, if pci_request_regions() fails --
indicating another driver is using the hardware -- then
pci_disable_device() is called on the error path, disabling a device
that another driver is using
To call this "rather rude" is an understatement :)
Fortunately, the
20 matches
Mail list logo
