search for: lnro0005

...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? >> >&...

...00644 --- a/hw/arm/virt-acpi-build.c +++ b/hw/arm/virt-acpi-build.c @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope, for (i = 0; i < num; i++) { Aml *dev = aml_device("VR%02u", i); - aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005"))); + aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F"))); aml_append(dev, aml_name_decl("_UID", aml_int(i))); Aml *crs = aml_resource_template(); -- MST

...00644 --- a/hw/arm/virt-acpi-build.c +++ b/hw/arm/virt-acpi-build.c @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope, for (i = 0; i < num; i++) { Aml *dev = aml_device("VR%02u", i); - aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005"))); + aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F"))); aml_append(dev, aml_name_decl("_UID", aml_int(i))); Aml *crs = aml_resource_template(); -- MST

...x/highmem.h> #include <linux/interrupt.h> #include <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", }, + { } +}; +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); +#endif + static struct platform_driver virtio_mmio_driver = { .probe = virtio_mmio_probe, .remove = virtio_mmio_remove, .driver = { .name = "virtio-mmio", .of_match_table = virtio_mmio_match, + .acpi...

...x/highmem.h> #include <linux/interrupt.h> #include <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", }, + { } +}; +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); +#endif + static struct platform_driver virtio_mmio_driver = { .probe = virtio_mmio_probe, .remove = virtio_mmio_remove, .driver = { .name = "virtio-mmio", .of_match_table = virtio_mmio_match, + .acpi...

...us way using "QEMUXXXX"? Something I missed? > > So that guests that bind to this interface will work fine with non QEMU > implementations of virtio-mmio. I don't understand this sentence. If there are pre-existing non-QEMU virtio-mmio implementations, then they're using LNRO0005, and we should use it too. If there are going to be implementations of virtio-mmio in future, then they will use whatever identifier we pick here. Either way, we get interoperability. I don't see any difference between our saying "the ID for virtio-mmio is QEMU0005" and saying "t...

...us way using "QEMUXXXX"? Something I missed? > > So that guests that bind to this interface will work fine with non QEMU > implementations of virtio-mmio. I don't understand this sentence. If there are pre-existing non-QEMU virtio-mmio implementations, then they're using LNRO0005, and we should use it too. If there are going to be implementations of virtio-mmio in future, then they will use whatever identifier we pick here. Either way, we get interoperability. I don't see any difference between our saying "the ID for virtio-mmio is QEMU0005" and saying "t...

...;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. I th...

...;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. I th...

...uild.c > +++ b/hw/arm/virt-acpi-build.c > @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope, > > for (i = 0; i < num; i++) { > Aml *dev = aml_device("VR%02u", i); > - aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005"))); > + aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F"))); > aml_append(dev, aml_name_decl("_UID", aml_int(i))); > > Aml *crs = aml_resource_template(); > -- Shannon

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 ID without breaking anything significant then I think the QEMU ID makes more sense; but it doesn't really gain us much beyond tidiness. PS: https://www.kernel.org/doc/Doc...

...-build.c > +++ b/hw/arm/virt-acpi-build.c > @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope, > > for (i = 0; i < num; i++) { > Aml *dev = aml_device("VR%02u", i); > - aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005"))); > + aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F"))); > aml_append(dev, aml_name_decl("_UID", aml_int(i))); So, I've just checked, and I believe that the kernel that RedHat are shipping in their RHEL7 dev preview for A...

...t/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e >> >> >> >> Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org> >> >> +#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? >> >&...

...t/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e >> >> >> >> Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org> >> >> +#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? >> >&...

....c >>> @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope, >>> >>> for (i = 0; i < num; i++) { >>> Aml *dev = aml_device("VR%02u", i); >>> - aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005"))); >>> + aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F"))); >>> aml_append(dev, aml_name_decl("_UID", aml_int(i))); >>> >>> Aml *crs = aml_resource_template(); >>> >> >...

....c >>> @@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope, >>> >>> for (i = 0; i < num; i++) { >>> Aml *dev = aml_device("VR%02u", i); >>> - aml_append(dev, aml_name_decl("_HID", aml_string("LNRO0005"))); >>> + aml_append(dev, aml_name_decl("_HID", aml_string("1AF4103F"))); >>> aml_append(dev, aml_name_decl("_UID", aml_int(i))); >>> >>> Aml *crs = aml_resource_template(); >>> >> >...

...today? Could we use that mechanism to > > identify vIOMMUs and then invent a purely para-virtualized method to > > enumerate devices behind each vIOMMU? > > Using DT, virtio-mmio devices are described with "virtio-mmio" compatible > node, and with ACPI they use _HID LNRO0005. Since the host already > describes available devices to a guest using a firmware interface, I think > we should reuse the tools provided by that interface for describing > relations between DMA masters and IOMMU. OK, I didn't realize virtio-mmio is defined to rely on DT for enumerati...

...today? Could we use that mechanism to > > identify vIOMMUs and then invent a purely para-virtualized method to > > enumerate devices behind each vIOMMU? > > Using DT, virtio-mmio devices are described with "virtio-mmio" compatible > node, and with ACPI they use _HID LNRO0005. Since the host already > describes available devices to a guest using a firmware interface, I think > we should reuse the tools provided by that interface for describing > relations between DMA masters and IOMMU. OK, I didn't realize virtio-mmio is defined to rely on DT for enumerati...

...rrupt.h> > #include <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? > +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); > +#endif > + > static struct platform_drive...