search for: lnro

ACPI spec 5.0 allows the use of PCI vendor IDs. Since we have one for virtio, it seems neater to use that rather than LNRO. For the device ID, use 103F which is a legacy ID that isn't used in virtio PCI spec - seems to make sense since virtio-mmio is a legacy device but we don't know the correct device type. Guests should probably match everything in the range 1000-103F (just like legacy pci drivers do) which...

ACPI spec 5.0 allows the use of PCI vendor IDs. Since we have one for virtio, it seems neater to use that rather than LNRO. For the device ID, use 103F which is a legacy ID that isn't used in virtio PCI spec - seems to make sense since virtio-mmio is a legacy device but we don't know the correct device type. Guests should probably match everything in the range 1000-103F (just like legacy pci drivers do) which...

...struct of_device_id virtio_mmio_match[] = { >> >> }; >> >> MODULE_DEVICE_TABLE(of, virtio_mmio_match); >> >> >> >> +#ifdef CONFIG_ACPI >> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> >> + { "LNRO0005", }, >> >> + { } >> >> +}; >> > >> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >> > >> > Pater - do you think it's a good idea to change this before QEMU 2.4 >> > is released? >> &...

...struct of_device_id virtio_mmio_match[] = { >> >> }; >> >> MODULE_DEVICE_TABLE(of, virtio_mmio_match); >> >> >> >> +#ifdef CONFIG_ACPI >> >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> >> + { "LNRO0005", }, >> >> + { } >> >> +}; >> > >> > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. >> > >> > Pater - do you think it's a good idea to change this before QEMU 2.4 >> > is released? >> &...

...The table is > > constructed by QEMU and read by the kernel (and possibly > > also by UEFI?), so everybody needs to agree on what the > > string is... > > I agree with Peter. Maybe we should record these IDs at some place. Right. And it should apply even if you keep using LNRO. Pls create docs/specs/acpi_ids.txt and list them there. For simplicity, I'd just replace LNRO with QEMU. > Since QEMU is owner of this device and we register QEMU in ASWG, the > official ID can be assigned by QEMU and the ID could(or should) be > "QEMUXXXX". But what's...

On 2015/7/29 5:10, Peter Maydell wrote: > On 28 July 2015 at 21:28, G Gregory <graeme.gregory at linaro.org> wrote: >> > On 28 July 2015 at 21:12, Peter Maydell <peter.maydell at linaro.org> wrote: >>> >> Mmm. I'm not terribly happy about stuff being in QEMU before the >>> >> ACPI spec for it has been finalised. We should not be picking

On 2015/7/29 5:10, Peter Maydell wrote: > On 28 July 2015 at 21:28, G Gregory <graeme.gregory at linaro.org> wrote: >> > On 28 July 2015 at 21:12, Peter Maydell <peter.maydell at linaro.org> wrote: >>> >> Mmm. I'm not terribly happy about stuff being in QEMU before the >>> >> ACPI spec for it has been finalised. We should not be picking

...Tsirkin wrote: > ACPI spec 5.0 allows the use of PCI vendor IDs. > But virtio-mmio is not a PCI device, it's a platform device. Why do we drop the previous way using "QEMUXXXX"? Something I missed? > Since we have one for virtio, it seems neater to use that > rather than LNRO. For the device ID, use 103F which is a legacy ID that > isn't used in virtio PCI spec - seems to make sense since virtio-mmio is > a legacy device but we don't know the correct device type. > > Guests should probably match everything in the range 1000-103F > (just like lega...

...e with others. > > We could have done something similar to pvpanic as well, except we > didn't and guests using the QEMU prefix have been released, > so we have to keep using that. > >>> Since we have one for virtio, it seems neater to use that >>> rather than LNRO. For the device ID, use 103F which is a legacy ID that >>> isn't used in virtio PCI spec - seems to make sense since virtio-mmio is >>> a legacy device but we don't know the correct device type. >>> >>> Guests should probably match everything in the range...

...e with others. > > We could have done something similar to pvpanic as well, except we > didn't and guests using the QEMU prefix have been released, > so we have to keep using that. > >>> Since we have one for virtio, it seems neater to use that >>> rather than LNRO. For the device ID, use 103F which is a legacy ID that >>> isn't used in virtio PCI spec - seems to make sense since virtio-mmio is >>> a legacy device but we don't know the correct device type. >>> >>> Guests should probably match everything in the range...

On 28 July 2015 at 11:33, G Gregory <graeme.gregory at linaro.org> wrote: > We assigned LNRO in ASWG to avoid collisions with our prototypes/real > platforms so it makes sense to me to switch to QEMUXXXX. So just to check, if we switch virtio-mmio from an LNRO0005 ID to a QEMUxxxx ID we aren't going to break any existing widely shipped or deployed code, right? If we can change the...

On 29 July 2015 at 20:16, Michael S. Tsirkin <mst at redhat.com> wrote: > ACPI spec 5.0 allows the use of PCI vendor IDs. > > Since we have one for virtio, it seems neater to use that > rather than LNRO. For the device ID, use 103F which is a legacy ID that > isn't used in virtio PCI spec - seems to make sense since virtio-mmio is > a legacy device but we don't know the correct device type. > > Guests should probably match everything in the range 1000-103F > (just like legac...

...mio. It's just playing nice with others. We could have done something similar to pvpanic as well, except we didn't and guests using the QEMU prefix have been released, so we have to keep using that. > > Since we have one for virtio, it seems neater to use that > > rather than LNRO. For the device ID, use 103F which is a legacy ID that > > isn't used in virtio PCI spec - seems to make sense since virtio-mmio is > > a legacy device but we don't know the correct device type. > > > > Guests should probably match everything in the range 1000-103F...

...;linux/io.h> >> @@ -732,12 +733,21 @@ static struct of_device_id virtio_mmio_match[] = { >> }; >> MODULE_DEVICE_TABLE(of, virtio_mmio_match); >> >> +#ifdef CONFIG_ACPI >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> + { "LNRO0005", }, >> + { } >> +}; > > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. > > Pater - do you think it's a good idea to change this before QEMU 2.4 > is released? Shannon's call, I guess. I don't know enough about ACPI to say....

...;linux/io.h> >> @@ -732,12 +733,21 @@ static struct of_device_id virtio_mmio_match[] = { >> }; >> MODULE_DEVICE_TABLE(of, virtio_mmio_match); >> >> +#ifdef CONFIG_ACPI >> +static const struct acpi_device_id virtio_mmio_acpi_match[] = { >> + { "LNRO0005", }, >> + { } >> +}; > > Hmm - we have reserved QEMUXXXX in ASWG explicitly for this purpose. > > Pater - do you think it's a good idea to change this before QEMU 2.4 > is released? Shannon's call, I guess. I don't know enough about ACPI to say....