Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.

At least one embedded x86 case cares, that I know of. They only needed to make two minor changes to make it work.

*It is not part of 2.6.20*

The code no long reserves resources for the "extra" PCI BAR that often exists on PCI controllers regardless of legacy/native mode. Previously, the code called pci_request_regions() to reserve ALL regions attached to the PCI device.

We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.

Translation: You want to hand-wave away an obvious regression that YOU have created with your fix-to-a-fix.


We can fix BAR5 in .21 when all the combined mode crap
goes away.

Translation: Problems disappear in 2.6.21 because Jeff will revert the code I touched to its previous state -- always calling pci_request_regions() -- and all the problems I introduced by avoiding pci_request_regions() will go away.

Why INTRODUCE these 2.6.20 Alan-isms, if they are going away in 2.6.21?


You have suddenly decided that it's OK to --not reserve at all-- these additional regions.

It's not ideal - but it is perfectly sufficient for 2.6.20

Proof: The AHCI PCI BAR (#5, zero-based) is clearly NOT reserved, even though we talk to it, in piix_disable_ahci() of ata_piix.c.

We always claim the other BARs so catch a collision.

Where?  AFAICS, it is crystal clear the behavior:

* Prior to your patch, ata_piix in legacy mode calls pci_request_regions() to intentionally reserve ALL regions on the PCI device.

* After your patch, the code explicitly calls pci_request_region() for BARs 0-4, but never for BAR5.

Another driver is now free to claim a PCI BAR, and start running the hardware in AHCI mode, whee!

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux