| Message ID | 165051164674.3740862.4706111262486927842.stgit@dwillia2-desk3.amr.corp.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | ahci: Add a generic 'controller2' RAID id | expand |
On Wed, Apr 20, 2022 at 08:27:26PM -0700, Dan Williams wrote: > As mentioned here [1], the pain of continuing add new and different > device-ids for RAID mode to this file [2] has been heard. Ideally this > device-id would not matter and the class code would remain > PCI_CLASS_STORAGE_SATA_AHCI regardless of the RAID mode, but other > operating systems depend on the class code *not* being AHCI when the > device is in RAID mode. That said, going forward there is little reason > for new server RAID ids to be added as they can simply reuse one of the > existing ids even for a new controller. Server software RAID features > continue to be supported on Linux. Client software RAID features > continue to be not supported and the recommendation there remains to set > the device to AHCI mode in platform firmware. I thought client switched to vmd as well now? Either way the patch itself looks good: Reviewed-by: Christoph Hellwig <hch@lst.de>
On Wed, Apr 20, 2022 at 10:50 PM Christoph Hellwig <hch@lst.de> wrote: > > On Wed, Apr 20, 2022 at 08:27:26PM -0700, Dan Williams wrote: > > As mentioned here [1], the pain of continuing add new and different > > device-ids for RAID mode to this file [2] has been heard. Ideally this > > device-id would not matter and the class code would remain > > PCI_CLASS_STORAGE_SATA_AHCI regardless of the RAID mode, but other > > operating systems depend on the class code *not* being AHCI when the > > device is in RAID mode. That said, going forward there is little reason > > for new server RAID ids to be added as they can simply reuse one of the > > existing ids even for a new controller. Server software RAID features > > continue to be supported on Linux. Client software RAID features > > continue to be not supported and the recommendation there remains to set > > the device to AHCI mode in platform firmware. > > I thought client switched to vmd as well now? Yes, I believe so, but the RAID metadata and features like caching etc are still forked. > Either way the patch itself looks good: > > Reviewed-by: Christoph Hellwig <hch@lst.de> Thanks.
On 4/21/22 12:27, Dan Williams wrote: > Intel server platforms that support 'RAID', i.e. have platform firmware > support for software-RAID metadata + features that the kernel also > understands, maintain the same device-ids for RAID from generation to > generation. This is in contrast to client platforms that have tended to > roll new device-ids every platform generation. However, even though > server platform keep the ids there are still unique device-ids per > controller instance. To date there have only been 2 controllers on these > platforms, but platforms code named Emmitsburg add a third controller. > > Add the device-id for this third controller and collect it with the > other generic server RAID ids. > > As mentioned here [1], the pain of continuing add new and different > device-ids for RAID mode to this file [2] has been heard. Ideally this > device-id would not matter and the class code would remain > PCI_CLASS_STORAGE_SATA_AHCI regardless of the RAID mode, but other > operating systems depend on the class code *not* being AHCI when the > device is in RAID mode. That said, going forward there is little reason > for new server RAID ids to be added as they can simply reuse one of the > existing ids even for a new controller. Server software RAID features > continue to be supported on Linux. Client software RAID features > continue to be not supported and the recommendation there remains to set > the device to AHCI mode in platform firmware. > > Link: https://lore.kernel.org/all/8e61fb0104422e8d70701e2ddc7b1ca53f009797.camel@intel.com [1] > Link: https://lore.kernel.org/all/20201119165022.GA3582@infradead.org/ [2] > Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> Applied to for-5.19. Thanks !
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 397dfd27c90d..c1eca72b4575 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -324,7 +324,6 @@ static const struct pci_device_id ahci_pci_tbl[] = { { PCI_VDEVICE(INTEL, 0x1d02), board_ahci }, /* PBG AHCI */ { PCI_VDEVICE(INTEL, 0x1d04), board_ahci }, /* PBG RAID */ { PCI_VDEVICE(INTEL, 0x1d06), board_ahci }, /* PBG RAID */ - { PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* PBG/Lewisburg RAID*/ { PCI_VDEVICE(INTEL, 0x2323), board_ahci }, /* DH89xxCC AHCI */ { PCI_VDEVICE(INTEL, 0x1e02), board_ahci }, /* Panther Point AHCI */ { PCI_VDEVICE(INTEL, 0x1e03), board_ahci_low_power }, /* Panther M AHCI */ @@ -367,7 +366,9 @@ static const struct pci_device_id ahci_pci_tbl[] = { { PCI_VDEVICE(INTEL, 0x1f3e), board_ahci_avn }, /* Avoton RAID */ { PCI_VDEVICE(INTEL, 0x1f3f), board_ahci_avn }, /* Avoton RAID */ { PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Wellsburg/Lewisburg AHCI*/ - { PCI_VDEVICE(INTEL, 0x2827), board_ahci }, /* Wellsburg/Lewisburg RAID*/ + { PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* *burg SATA0 'RAID' */ + { PCI_VDEVICE(INTEL, 0x2827), board_ahci }, /* *burg SATA1 'RAID' */ + { PCI_VDEVICE(INTEL, 0x282f), board_ahci }, /* *burg SATA2 'RAID' */ { PCI_VDEVICE(INTEL, 0x43d4), board_ahci }, /* Rocket Lake PCH-H RAID */ { PCI_VDEVICE(INTEL, 0x43d5), board_ahci }, /* Rocket Lake PCH-H RAID */ { PCI_VDEVICE(INTEL, 0x43d6), board_ahci }, /* Rocket Lake PCH-H RAID */
Intel server platforms that support 'RAID', i.e. have platform firmware support for software-RAID metadata + features that the kernel also understands, maintain the same device-ids for RAID from generation to generation. This is in contrast to client platforms that have tended to roll new device-ids every platform generation. However, even though server platform keep the ids there are still unique device-ids per controller instance. To date there have only been 2 controllers on these platforms, but platforms code named Emmitsburg add a third controller. Add the device-id for this third controller and collect it with the other generic server RAID ids. As mentioned here [1], the pain of continuing add new and different device-ids for RAID mode to this file [2] has been heard. Ideally this device-id would not matter and the class code would remain PCI_CLASS_STORAGE_SATA_AHCI regardless of the RAID mode, but other operating systems depend on the class code *not* being AHCI when the device is in RAID mode. That said, going forward there is little reason for new server RAID ids to be added as they can simply reuse one of the existing ids even for a new controller. Server software RAID features continue to be supported on Linux. Client software RAID features continue to be not supported and the recommendation there remains to set the device to AHCI mode in platform firmware. Link: https://lore.kernel.org/all/8e61fb0104422e8d70701e2ddc7b1ca53f009797.camel@intel.com [1] Link: https://lore.kernel.org/all/20201119165022.GA3582@infradead.org/ [2] Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- drivers/ata/ahci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)