On 9/7/20 11:20 AM, Klaus Jensen wrote: > On Sep 7 10:58, Klaus Jensen wrote: >> On Sep 7 10:36, Philippe Mathieu-Daudé wrote: >>> On 9/7/20 9:23 AM, Klaus Jensen wrote: >>>> On Sep 7 04:28, Philippe Mathieu-Daudé wrote: >>>>> +David in case >>>>> >>>>> On 9/4/20 4:19 PM, Klaus Jensen wrote: >>>>>> From: Klaus Jensen <k.jen...@samsung.com> >>>>>> >>>>>> There are two reasons for changing this: >>>>>> >>>>>> 1. The nvme device currently uses an internal Intel device id. >>>>>> >>>>>> 2. Since commits "nvme: fix write zeroes offset and count" and "nvme: >>>>>> support multiple namespaces" the controller device no longer has >>>>>> the quirks that the Linux kernel think it has. >>>>>> >>>>>> As the quirks are applied based on pci vendor and device id, change >>>>>> them to get rid of the quirks. >>>>>> >>>>>> To keep backward compatibility, add a new 'x-use-intel-id' parameter to >>>>>> the nvme device to force use of the Intel vendor and device id. This is >>>>>> off by default but add a compat property to set this for 5.1 machines >>>>>> and older. >>>>> >>>>> So now what happens if you start a 5.1 machine with a recent kernel? >>>>> Simply the kernel will use unnecessary quirks, or are there more >>>>> changes in behavior? >>>>> >>>> >>>> Yes, the kernel will then just apply unneccesary quirks, these are: >>>> >>>> 1. NVME_QUIRK_IDENTIFY_CNS which says that the device does not support >>>> anything else than values 0x0 and 0x1 for CNS (Identify Namespace and >>>> Identify Namespace). With multiple namespace support, this just >>>> means that the kernel will "scan" namespaces instead of using >>>> "Active Namespace ID list" (CNS 0x2). >>>> >>>> 2. NVME_QUIRK_DISABLE_WRITE_ZEROES. The nvme device started out with a >>>> broken Write Zeroes implementation which has since been fixed in >>>> commit 9d6459d21a6e ("nvme: fix write zeroes offset and count"). >>> >>> OK thanks. Can you amend that information in the commit >>> description please? >>> >> >> Yes, absolutely. > > By the way. Is it correct use of an 'x-' parameter here - since it is > something that we might remove in the future? I was unable to find any > documentation on the purpose of the 'x-' prefix, but I was guessing it > was for stuff like this.
Probably not. 'x-' is for unstable debugging/testing features.