[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/1] tools/libacpi: clear ASL warning about PCI0
On Monday, December 16, 2024 12:38 CET, Jan Beulich <jbeulich@xxxxxxxx> wrote: > On 16.12.2024 12:31, Ariel Otilibili-Anieli wrote: > > On Monday, December 16, 2024 12:01 CET, Jan Beulich <jbeulich@xxxxxxxx> > > wrote: > > > >> On 16.12.2024 11:36, Ariel Otilibili-Anieli wrote: > >>> On Monday, December 16, 2024 10:53 CET, Jan Beulich <jbeulich@xxxxxxxx> > >>> wrote: > >>> > >>>> On 15.12.2024 16:40, Ariel Otilibili wrote: > >>>>> * iasl complains _HID and _ADR cannot be used at the same time > >>>>> > >>>>> ``` > >>>>> /usr/bin/iasl -vs -p tools/firmware/hvmloader/dsdt_anycpu.tmp -tc > >>>>> tools/firmware/hvmloader/dsdt_anycpu.asl 2>&1 | grep -B10 HID > >>>>> tools/firmware/hvmloader/dsdt_anycpu.asl 40: Device (PCI0) > >>>>> Warning 3073 - Multiple types ^ > >>>>> (Device object requires either a _HID or _ADR, but not both) > >>>>> ``` > >>>>> > >>>>> * generally _HID devices are enumerated and have their drivers loaded > >>>>> by ACPI > >>>>> * this is from "ASL 2.0 Introduction and Overview" (page 4). > >>>>> * removing _ADR, the warning is cleared out. > >>>> > >>>> Okay, that's the positive aspect. Yet what about the potential fallout > >>>> thereof? > >>>> Can you confirm that there's no risk of regressions with older guest > >>>> OSes, for > >>>> example? > >>> > >>> OSes that were released after ACPI 2.0 should work [1]; including WinXP: > >>> The 2.0 specs says either _HID or _ADR should be included [2], not both > >>> (Section 6.1, page 146). > >> > >> We must be looking at two different variants of the spec then. My copy says > >> "device object must contain either an _HID object or an _ADR object, but > >> can > >> contain both." Also still in 2.0c. I agree that in e.g. 6.5 the wording has > >> changed. I also agree that the use of "either" doesn't help clarity. > > > > I looked up 2.0 (July 2000); indeed, it said "can contain both". My bad. > >> > >>> I chose WinXP because, on another patch, it came up in the discussion [3]. > > > > The change should work down to WinXP: the name _HID is kept. > > > > ``` > > $ git grep -B2 -A2 -n PNP0A03 > > tools/libacpi/dsdt.asl-40- Device (PCI0) > > tools/libacpi/dsdt.asl-41- { > > tools/libacpi/dsdt.asl:42: Name (_HID, EisaId ("PNP0A03")) > > tools/libacpi/dsdt.asl-43- Name (_UID, 0x00) > > tools/libacpi/dsdt.asl-44- Name (_ADR, 0x00) > > ``` > > > > Its EISA ID is "PNP0A03"; the namespace is reserved for Microsoft. > > Microsoft identifies "PNP0A03" as PCI devices [1]. > > You again say "should" without explaining what you derive this from. Is it > written down somewhere that no OS we (remotely) care about ever evaluated > _ADR when _HID was there? As before, along side mentioning the benefits of > the change, I'd like to also see a discussion of risks. > I derive this knowledge only from the APCI specs. Indeed, I've not researched how every OS interprets _HID and _ADR.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |