On Mon, Oct 24, 2016 at 10:55 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Mon, Oct 24, 2016 at 10:46:29AM -0700, Dan Williams wrote: >> On Mon, Oct 24, 2016 at 8:16 AM, Christoph Hellwig <hch@xxxxxx> wrote: >> > On Mon, Oct 24, 2016 at 10:46:29AM -0400, Keith Busch wrote: >> >> Amber is aware of this and was supportive in having Intel open the >> >> specs to enable this hardware. >> > >> > Ok, let's get the spec out first. >> >> The patch contents are it. > > Well. that's simply not acceptable. We will need a theory of > operation for this device to support it, because the patch as-is > simply doesn't make sense. The presence of ahci bar remapping is documented here: http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html The PCI memory space is remapped, the configuration space of the remapped device is not available, and interrupts are shared. > We'll also need to know where such device might show up, and why > Linux support for it matters. This is a capability of the "Intel® 100 Series Chipset Family". These patches matter because this chipset in this configuration appears in laptops that you can buy today and Linux is unable to access the NVMe device. >> > Do we expect to be able to use the >> > AHCI interface and the NVMe interface at the same time? >> >> Yes, simultaneous access. > > Yikes. I'm really tempted to say this is not acceptable - Intel > really must know better. > Linux users are unable to access storage without these patches. >> That said, the driver seems to already comprehend instances where the >> device does not support nvme_reset_subsystem() requests. I don't know >> how often those resets need to be issued in practice. > > It's not about how often reset are needed (and there are controller > resets in addition to function level resets), but how they are > defined to work. What state is a controller in after a host initiated > reset, after a PCIe hotplug or even warm plug. What state is the > PCI device in when the controller is in a failed state? Talking with Keith, subsystem-resets are a feature of enterprise-class NVMe devices. I think those features are out of scope for the class of devices that will find themselves in a platform with this configuration, same for hot-plug. >> > If it's the latter let's keep AHCI entirely out >> > of the game - add the affected PCI IDs to the NVMe driver itself, add >> > a quirk for them and implement the enable sequence inside the NVMe >> > driver. >> >> The PCI ID of the AHCI device is not uniquely identifiable when in this mode. >> >> We could flip the arrangement and have the ahci device as the platform >> device, but I'm not sure this makes the nvme reset problem much >> better. If we allow subsystem resets at all they would still need to >> be coordinated across 2 devices/drivers to reinitialize pci registers. > > I think the simple answer is to not support this device. It's not like > Intel doesn't know the AHCI and NVMe specs and had any reaoson to come > up with a piece of junk like this. Whatever answer we, in the Linux kernel community, come up with, leaving storage inaccessible is not an acceptable answer. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
