| Message ID | 20221010150206.142615-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | x86/PCI: Disable E820 reserved region clipping for Clevo NL4XLU laptops | expand |
On Mon, Oct 10, 2022 at 05:02:06PM +0200, Hans de Goede wrote: > Clevo NL4XLU barebones have the same E820 reservation covering > the entire _CRS 32-bit window issue as the Lenovo *IIL* and > Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): > > BIOS-e820: [mem 0x000000005bc50000-0x00000000cfffffff] reserved > pci_bus 0000:00: root bus resource [mem 0x6d800000-0xbfffffff window] > > Note how the e820 reservation covers the entire PCI root mem window. > > Add a no_e820 quirk for these models to fix the touchpad not working > (due to Linux being unable to assign a PCI BAR for the i2c-controller). I do plan to apply this, but a little food for thought below. I explored this issue a little bit with the ACPI/UEFI folks (see https://members.uefi.org/wg/aswg/mail/thread/9265 if you have access). One aspect I had glossed over earlier is that on most recent machines, the "E820 map" Linux uses is actually constructed internally by Linux based on the UEFI memory map, and that construction conflates several EFI types into E820_TYPE_RESERVED; see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/x86-stub.c?id=v5.19#n576 We don't have a dmesg log with "efi=debug" for this case, but in most cases where E820 says the entire root mem window is reserved, I think it's because an EfiMemoryMappedIO entry was converted to E820_TYPE_RESERVED. From a response in the ACPI/UEFI discussion: The reason EfiMemoryMappedIO[1] exist in the UEFI memory map is to request a virtual mapping for UEFI Runtime Services. For example if the EFI Runtime Service needed to write to FLASH then the NOR FLASH would need a mapping. Also the NOR FLASH controller might also need a mapping and this could include PCI Config Space if needed registers existed in that space. Thus the EfiMemoryMappedIO entries just exist to pass up the EFI_MEMORY_RUNTIME attribute in the UEFI Memory Map. This is the part of the contract for UEFI Runtime Service to use virtual mappings provided by the OS. So from an OS point of view EfiMemoryMappedIO has no other purpose. [1] UEFI: Table 7-5 Memory Type Usage before ExitBootServices() "Used by system firmware to request that a memory-mapped IO region be mapped by the OS to a virtual address so it can be accessed by EFI runtime services." So the point here is that Linux currently converts EfiMemoryMappedIO to E820_TYPE_RESERVED, and that likely attaches more meaning to those regions than firmware intended. I'm a little leery of changing that UEFI->E820 conversion because of other possible implications, but it may be that omitting EfiMemoryMappedIO entries from the E820 map and keeping the original "avoid E820 regions" (4dc2287c1805) would also solve this problem. > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > arch/x86/pci/acpi.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c > index 2f82480fd430..45ef65d31a40 100644 > --- a/arch/x86/pci/acpi.c > +++ b/arch/x86/pci/acpi.c > @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { > DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), > }, > }, > + > + /* > + * Clevo NL4XLU barebones have the same E820 reservation covering > + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. > + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 > + */ > + { > + .callback = set_no_e820, > + .ident = "Clevo NL4XLU Barebone", > + .matches = { > + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), > + }, > + }, > {} > }; > > -- > 2.37.3 >
Hi, On 10/11/22 19:40, Bjorn Helgaas wrote: > On Mon, Oct 10, 2022 at 05:02:06PM +0200, Hans de Goede wrote: >> Clevo NL4XLU barebones have the same E820 reservation covering >> the entire _CRS 32-bit window issue as the Lenovo *IIL* and >> Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): >> >> BIOS-e820: [mem 0x000000005bc50000-0x00000000cfffffff] reserved >> pci_bus 0000:00: root bus resource [mem 0x6d800000-0xbfffffff window] >> >> Note how the e820 reservation covers the entire PCI root mem window. >> >> Add a no_e820 quirk for these models to fix the touchpad not working >> (due to Linux being unable to assign a PCI BAR for the i2c-controller). > > I do plan to apply this, but a little food for thought below. > > I explored this issue a little bit with the ACPI/UEFI folks (see > https://members.uefi.org/wg/aswg/mail/thread/9265 if you have access). > > One aspect I had glossed over earlier is that on most recent machines, > the "E820 map" Linux uses is actually constructed internally by Linux > based on the UEFI memory map, and that construction conflates several > EFI types into E820_TYPE_RESERVED; see > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/x86-stub.c?id=v5.19#n576 > > We don't have a dmesg log with "efi=debug" for this case, but in most > cases where E820 says the entire root mem window is reserved, I think > it's because an EfiMemoryMappedIO entry was converted to > E820_TYPE_RESERVED. > > From a response in the ACPI/UEFI discussion: > > The reason EfiMemoryMappedIO[1] exist in the UEFI memory map is to > request a virtual mapping for UEFI Runtime Services. > > For example if the EFI Runtime Service needed to write to FLASH then > the NOR FLASH would need a mapping. Also the NOR FLASH controller > might also need a mapping and this could include PCI Config Space if > needed registers existed in that space. > > Thus the EfiMemoryMappedIO entries just exist to pass up the > EFI_MEMORY_RUNTIME attribute in the UEFI Memory Map. This is the part > of the contract for UEFI Runtime Service to use virtual mappings > provided by the OS. So from an OS point of view EfiMemoryMappedIO has > no other purpose. > > [1] UEFI: Table 7-5 Memory Type Usage before ExitBootServices() "Used > by system firmware to request that a memory-mapped IO region be > mapped by the OS to a virtual address so it can be accessed by EFI > runtime services." > > So the point here is that Linux currently converts EfiMemoryMappedIO > to E820_TYPE_RESERVED, and that likely attaches more meaning to those > regions than firmware intended. > > I'm a little leery of changing that UEFI->E820 conversion because of > other possible implications, but it may be that omitting > EfiMemoryMappedIO entries from the E820 map and keeping the original > "avoid E820 regions" (4dc2287c1805) would also solve this problem. Actually during my many attempts to fix this I did write a patch adding a new E820_TYPE_MMIO to the generated e820-memmap which would only show up in the EFI -> E820 entry generation case and then used that to not exclude that E820 region, see this RFC series: https://lore.kernel.org/linux-pci/20220214151759.98267-1-hdegoede@redhat.com/ Unfortunately this series caused the same X1 carbon gen2 suspend/resume not working problem as the earlier set pci=no_e820 based on a BIOS date cutoff attempt which I did earlier and which even briefly was in some -rc kernels through Rafael's tree. I also did another series which used the EfiMemoryMappedIO type as an input to heuristics to automatically set pci=no_e820, see: https://lore.kernel.org/linux-pci/20220228105259.230903-1-hdegoede@redhat.com/ IIRC that patch eventually got replaced by a similar but simpler heuristic from you. Which IIRC eventually got dropped again because it was causing regressions on some models again. So we ended up with the current set pci=no_e820 using DMI based quirks + try to enable it for all BIOS-es with date >= 2023 approach, with the plan to do DMI quirks setting pci=use_e820 if any (buggy) 2023 BIOS-es show up which need this. Regards, Hans >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> arch/x86/pci/acpi.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c >> index 2f82480fd430..45ef65d31a40 100644 >> --- a/arch/x86/pci/acpi.c >> +++ b/arch/x86/pci/acpi.c >> @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { >> DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), >> }, >> }, >> + >> + /* >> + * Clevo NL4XLU barebones have the same E820 reservation covering >> + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. >> + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 >> + */ >> + { >> + .callback = set_no_e820, >> + .ident = "Clevo NL4XLU Barebone", >> + .matches = { >> + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), >> + }, >> + }, >> {} >> }; >> >> -- >> 2.37.3 >> >
On Wed, Oct 12, 2022 at 10:23:12AM +0200, Hans de Goede wrote: > On 10/11/22 19:40, Bjorn Helgaas wrote: > > On Mon, Oct 10, 2022 at 05:02:06PM +0200, Hans de Goede wrote: > >> Clevo NL4XLU barebones have the same E820 reservation covering > >> the entire _CRS 32-bit window issue as the Lenovo *IIL* and > >> Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): > >> ... > >> Add a no_e820 quirk for these models to fix the touchpad not working > >> (due to Linux being unable to assign a PCI BAR for the i2c-controller). > > > > I do plan to apply this, but a little food for thought below. > > > > I explored this issue a little bit with the ACPI/UEFI folks (see > > https://members.uefi.org/wg/aswg/mail/thread/9265 if you have access). > > > > One aspect I had glossed over earlier is that on most recent machines, > > the "E820 map" Linux uses is actually constructed internally by Linux > > based on the UEFI memory map, and that construction conflates several > > EFI types into E820_TYPE_RESERVED; see > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/x86-stub.c?id=v5.19#n576 Critical error on my part here: the E820 map is passed to Linux by the bootloader or the EFI stub, NOT constructed by Linux. > > From a response in the ACPI/UEFI discussion: > > > > The reason EfiMemoryMappedIO[1] exist in the UEFI memory map is to > > request a virtual mapping for UEFI Runtime Services. > > ... > > Thus the EfiMemoryMappedIO entries just exist to pass up the > > EFI_MEMORY_RUNTIME attribute in the UEFI Memory Map. This is the part > > of the contract for UEFI Runtime Service to use virtual mappings > > provided by the OS. So from an OS point of view EfiMemoryMappedIO has > > no other purpose. > > > > [1] UEFI: Table 7-5 Memory Type Usage before ExitBootServices() "Used > > by system firmware to request that a memory-mapped IO region be > > mapped by the OS to a virtual address so it can be accessed by EFI > > runtime services." > > I'm a little leery of changing that UEFI->E820 conversion because of > > other possible implications, but it may be that omitting > > EfiMemoryMappedIO entries from the E820 map and keeping the original > > "avoid E820 regions" (4dc2287c1805) would also solve this problem. > > Actually during my many attempts to fix this I did write a patch > adding a new E820_TYPE_MMIO to the generated e820-memmap which > would only show up in the EFI -> E820 entry generation case > and then used that to not exclude that E820 region, see > this RFC series: > > https://lore.kernel.org/linux-pci/20220214151759.98267-1-hdegoede@redhat.com/ Yes :) I tried something similar and of course it didn't work because it didn't change the E820 map coming from the bootloader. > I also did another series which used the EfiMemoryMappedIO type as > an input to heuristics to automatically set pci=no_e820, see: > > https://lore.kernel.org/linux-pci/20220228105259.230903-1-hdegoede@redhat.com/ > > IIRC that patch eventually got replaced by a similar but simpler > heuristic from you. Which IIRC eventually got dropped again because > it was causing regressions on some models again. > > So we ended up with the current set pci=no_e820 using DMI based quirks + > try to enable it for all BIOS-es with date >= 2023 approach, > with the plan to do DMI quirks setting pci=use_e820 if any (buggy) > 2023 BIOS-es show up which need this. I gave up on figuring out what went wrong in this path. Anyway, I've had the patch below in -next for a couple weeks, but I plan to drop it and replace it with the series here: https://lore.kernel.org/linux-pci/20221202211838.1061278-1-helgaas@kernel.org/ Bjorn > >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 > >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > >> --- > >> arch/x86/pci/acpi.c | 13 +++++++++++++ > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c > >> index 2f82480fd430..45ef65d31a40 100644 > >> --- a/arch/x86/pci/acpi.c > >> +++ b/arch/x86/pci/acpi.c > >> @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { > >> DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), > >> }, > >> }, > >> + > >> + /* > >> + * Clevo NL4XLU barebones have the same E820 reservation covering > >> + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. > >> + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 > >> + */ > >> + { > >> + .callback = set_no_e820, > >> + .ident = "Clevo NL4XLU Barebone", > >> + .matches = { > >> + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), > >> + }, > >> + }, > >> {} > >> }; > >> > >> -- > >> 2.37.3 > >> > > >
Hi Bjorn, On 12/2/22 22:58, Bjorn Helgaas wrote: > On Wed, Oct 12, 2022 at 10:23:12AM +0200, Hans de Goede wrote: >> On 10/11/22 19:40, Bjorn Helgaas wrote: >>> On Mon, Oct 10, 2022 at 05:02:06PM +0200, Hans de Goede wrote: >>>> Clevo NL4XLU barebones have the same E820 reservation covering >>>> the entire _CRS 32-bit window issue as the Lenovo *IIL* and >>>> Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): >>>> ... >>>> Add a no_e820 quirk for these models to fix the touchpad not working >>>> (due to Linux being unable to assign a PCI BAR for the i2c-controller). >>> >>> I do plan to apply this, but a little food for thought below. >>> >>> I explored this issue a little bit with the ACPI/UEFI folks (see >>> https://members.uefi.org/wg/aswg/mail/thread/9265 if you have access). >>> >>> One aspect I had glossed over earlier is that on most recent machines, >>> the "E820 map" Linux uses is actually constructed internally by Linux >>> based on the UEFI memory map, and that construction conflates several >>> EFI types into E820_TYPE_RESERVED; see >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/x86-stub.c?id=v5.19#n576 > > Critical error on my part here: the E820 map is passed to Linux by the > bootloader or the EFI stub, NOT constructed by Linux. > >>> From a response in the ACPI/UEFI discussion: >>> >>> The reason EfiMemoryMappedIO[1] exist in the UEFI memory map is to >>> request a virtual mapping for UEFI Runtime Services. >>> ... >>> Thus the EfiMemoryMappedIO entries just exist to pass up the >>> EFI_MEMORY_RUNTIME attribute in the UEFI Memory Map. This is the part >>> of the contract for UEFI Runtime Service to use virtual mappings >>> provided by the OS. So from an OS point of view EfiMemoryMappedIO has >>> no other purpose. >>> >>> [1] UEFI: Table 7-5 Memory Type Usage before ExitBootServices() "Used >>> by system firmware to request that a memory-mapped IO region be >>> mapped by the OS to a virtual address so it can be accessed by EFI >>> runtime services." > >>> I'm a little leery of changing that UEFI->E820 conversion because of >>> other possible implications, but it may be that omitting >>> EfiMemoryMappedIO entries from the E820 map and keeping the original >>> "avoid E820 regions" (4dc2287c1805) would also solve this problem. >> >> Actually during my many attempts to fix this I did write a patch >> adding a new E820_TYPE_MMIO to the generated e820-memmap which >> would only show up in the EFI -> E820 entry generation case >> and then used that to not exclude that E820 region, see >> this RFC series: >> >> https://lore.kernel.org/linux-pci/20220214151759.98267-1-hdegoede@redhat.com/ > > Yes :) I tried something similar and of course it didn't work because > it didn't change the E820 map coming from the bootloader. Ah that is a good point, which I did not realize when I was working on this back then. Note it depends on the bootloader actually, systemd-boot uses the in-kernel-EFI-stub and Fedora's grub is patched to also use the in-kernel-EFI-stub. But your solution should work regardless of the boot path (1), which is good. 1) As long as some form of EFI booting is used. > >> I also did another series which used the EfiMemoryMappedIO type as >> an input to heuristics to automatically set pci=no_e820, see: >> >> https://lore.kernel.org/linux-pci/20220228105259.230903-1-hdegoede@redhat.com/ >> >> IIRC that patch eventually got replaced by a similar but simpler >> heuristic from you. Which IIRC eventually got dropped again because >> it was causing regressions on some models again. >> >> So we ended up with the current set pci=no_e820 using DMI based quirks + >> try to enable it for all BIOS-es with date >= 2023 approach, >> with the plan to do DMI quirks setting pci=use_e820 if any (buggy) >> 2023 BIOS-es show up which need this. > > I gave up on figuring out what went wrong in this path. > > Anyway, I've had the patch below in -next for a couple weeks, but I > plan to drop it and replace it with the series here: > https://lore.kernel.org/linux-pci/20221202211838.1061278-1-helgaas@kernel.org/ As I mentioned in the email-thread about that patch-series (and there now is dmesg E820 output to confirm this) your generic fix will unfortunately only work when people boot in EFI mode. It will still be good to have the generic fix of course. But maybe we should also add this quirk to make sure these Clevo-s also work properly when booted in BIOS CSM mode ? Regards, Hans > > Bjorn > >>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>> --- >>>> arch/x86/pci/acpi.c | 13 +++++++++++++ >>>> 1 file changed, 13 insertions(+) >>>> >>>> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c >>>> index 2f82480fd430..45ef65d31a40 100644 >>>> --- a/arch/x86/pci/acpi.c >>>> +++ b/arch/x86/pci/acpi.c >>>> @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { >>>> DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), >>>> }, >>>> }, >>>> + >>>> + /* >>>> + * Clevo NL4XLU barebones have the same E820 reservation covering >>>> + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. >>>> + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 >>>> + */ >>>> + { >>>> + .callback = set_no_e820, >>>> + .ident = "Clevo NL4XLU Barebone", >>>> + .matches = { >>>> + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), >>>> + }, >>>> + }, >>>> {} >>>> }; >>>> >>>> -- >>>> 2.37.3 >>>> >>> >> >
On Sun, Dec 04, 2022 at 10:42:38AM +0100, Hans de Goede wrote: > On 12/2/22 22:58, Bjorn Helgaas wrote: > > On Wed, Oct 12, 2022 at 10:23:12AM +0200, Hans de Goede wrote: > >> On 10/11/22 19:40, Bjorn Helgaas wrote: > >>> On Mon, Oct 10, 2022 at 05:02:06PM +0200, Hans de Goede wrote: > >>>> Clevo NL4XLU barebones have the same E820 reservation covering > >>>> the entire _CRS 32-bit window issue as the Lenovo *IIL* and > >>>> Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): > >>>> ... > >>>> Add a no_e820 quirk for these models to fix the touchpad not working > >>>> (due to Linux being unable to assign a PCI BAR for the i2c-controller). > ... > As I mentioned in the email-thread about that patch-series (and there > now is dmesg E820 output to confirm this) your generic fix will > unfortunately only work when people boot in EFI mode. It will still > be good to have the generic fix of course. > > But maybe we should also add this quirk to make sure these > Clevo-s also work properly when booted in BIOS CSM mode ? Yes, if they can boot in CSM mode, we should probably add the quirk. But Florent doesn't see a way to boot his Clevo NL41LU2/NL4XLU in CSM mode, so I think we can postpone adding the quirk until we find a machine where it makes a difference: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948811/comments/8 I added a note to https://bugzilla.kernel.org/show_bug.cgi?id=216565 to that effect. > >>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 > >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > >>>> --- > >>>> arch/x86/pci/acpi.c | 13 +++++++++++++ > >>>> 1 file changed, 13 insertions(+) > >>>> > >>>> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c > >>>> index 2f82480fd430..45ef65d31a40 100644 > >>>> --- a/arch/x86/pci/acpi.c > >>>> +++ b/arch/x86/pci/acpi.c > >>>> @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { > >>>> DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), > >>>> }, > >>>> }, > >>>> + > >>>> + /* > >>>> + * Clevo NL4XLU barebones have the same E820 reservation covering > >>>> + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. > >>>> + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 > >>>> + */ > >>>> + { > >>>> + .callback = set_no_e820, > >>>> + .ident = "Clevo NL4XLU Barebone", > >>>> + .matches = { > >>>> + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), > >>>> + }, > >>>> + }, > >>>> {} > >>>> };
Hi Bjorn, On 12/6/22 18:26, Bjorn Helgaas wrote: > On Sun, Dec 04, 2022 at 10:42:38AM +0100, Hans de Goede wrote: >> On 12/2/22 22:58, Bjorn Helgaas wrote: >>> On Wed, Oct 12, 2022 at 10:23:12AM +0200, Hans de Goede wrote: >>>> On 10/11/22 19:40, Bjorn Helgaas wrote: >>>>> On Mon, Oct 10, 2022 at 05:02:06PM +0200, Hans de Goede wrote: >>>>>> Clevo NL4XLU barebones have the same E820 reservation covering >>>>>> the entire _CRS 32-bit window issue as the Lenovo *IIL* and >>>>>> Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): >>>>>> ... >>>>>> Add a no_e820 quirk for these models to fix the touchpad not working >>>>>> (due to Linux being unable to assign a PCI BAR for the i2c-controller). >> ... > >> As I mentioned in the email-thread about that patch-series (and there >> now is dmesg E820 output to confirm this) your generic fix will >> unfortunately only work when people boot in EFI mode. It will still >> be good to have the generic fix of course. >> >> But maybe we should also add this quirk to make sure these >> Clevo-s also work properly when booted in BIOS CSM mode ? > > Yes, if they can boot in CSM mode, we should probably add the quirk. > But Florent doesn't see a way to boot his Clevo NL41LU2/NL4XLU in CSM > mode, so I think we can postpone adding the quirk until we find a > machine where it makes a difference: Ack. > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1948811/comments/8 > > I added a note to https://bugzilla.kernel.org/show_bug.cgi?id=216565 > to that effect. Thank you for also following up on this in bugzilla. Regards, Hans ' > >>>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 >>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>>>>> --- >>>>>> arch/x86/pci/acpi.c | 13 +++++++++++++ >>>>>> 1 file changed, 13 insertions(+) >>>>>> >>>>>> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c >>>>>> index 2f82480fd430..45ef65d31a40 100644 >>>>>> --- a/arch/x86/pci/acpi.c >>>>>> +++ b/arch/x86/pci/acpi.c >>>>>> @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { >>>>>> DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), >>>>>> }, >>>>>> }, >>>>>> + >>>>>> + /* >>>>>> + * Clevo NL4XLU barebones have the same E820 reservation covering >>>>>> + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. >>>>>> + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 >>>>>> + */ >>>>>> + { >>>>>> + .callback = set_no_e820, >>>>>> + .ident = "Clevo NL4XLU Barebone", >>>>>> + .matches = { >>>>>> + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), >>>>>> + }, >>>>>> + }, >>>>>> {} >>>>>> }; >
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index 2f82480fd430..45ef65d31a40 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -189,6 +189,19 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = { DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"), }, }, + + /* + * Clevo NL4XLU barebones have the same E820 reservation covering + * the entire _CRS 32-bit window issue as the Lenovo *IIL* models. + * See https://bugzilla.kernel.org/show_bug.cgi?id=216565 + */ + { + .callback = set_no_e820, + .ident = "Clevo NL4XLU Barebone", + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "NL4XLU"), + }, + }, {} };
Clevo NL4XLU barebones have the same E820 reservation covering the entire _CRS 32-bit window issue as the Lenovo *IIL* and Clevo X170KM-G models, relevant dmesg bits (with pci=no_e820): BIOS-e820: [mem 0x000000005bc50000-0x00000000cfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x6d800000-0xbfffffff window] Note how the e820 reservation covers the entire PCI root mem window. Add a no_e820 quirk for these models to fix the touchpad not working (due to Linux being unable to assign a PCI BAR for the i2c-controller). Link: https://bugzilla.kernel.org/show_bug.cgi?id=216565 Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- arch/x86/pci/acpi.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)