search for: acpi_device_id

...mt +#include <linux/acpi.h> #include <linux/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",...

...mt +#include <linux/acpi.h> #include <linux/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",...

...>> #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", }, >> + { } >> +}; > > 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 c...

...>> #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", }, >> + { } >> +}; > > 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 c...

...; >> >> http://git.linaro.org/people/shannon.zhao/qemu.git/commit/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...

...; >> >> http://git.linaro.org/people/shannon.zhao/qemu.git/commit/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...

...ed? > > So that guests that bind to this interface will work fine with non QEMU > implementations of virtio-mmio. > I think kernel driver supports multiple IDs. If they don't want to "QEMUXXXX" as ACPI ID, it's free to add a new one like below. +static const struct acpi_device_id virtio_mmio_acpi_match[] = { + { "QEMU0005", }, + { "1AF4103F", }, + { } +}; +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); > It's just playing nice with others. > > We could have done something similar to pvpanic as well, except we > didn'...

...ed? > > So that guests that bind to this interface will work fine with non QEMU > implementations of virtio-mmio. > I think kernel driver supports multiple IDs. If they don't want to "QEMUXXXX" as ACPI ID, it's free to add a new one like below. +static const struct acpi_device_id virtio_mmio_acpi_match[] = { + { "QEMU0005", }, + { "1AF4103F", }, + { } +}; +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match); > It's just playing nice with others. > > We could have done something similar to pvpanic as well, except we > didn'...

...clude <linux/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", }, > + { } > +}; 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); &...

...upt.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...

...clude <linux/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, >...

...http://git.linaro.org/people/shannon.zhao/qemu.git/commit/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 t...

...#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...

...#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...

...1260 1261 /* Device remove function. */ 1262 static int mlxbf_tmfifo_remove(struct platform_device *pdev) 1263 { 1264 struct mlxbf_tmfifo *fifo = platform_get_drvdata(pdev); 1265 1266 mlxbf_tmfifo_cleanup(fifo); 1267 1268 return 0; 1269 } 1270 1271 static const struct acpi_device_id mlxbf_tmfifo_acpi_match[] = { 1272 { "MLNXBF01", 0 }, 1273 {} 1274 }; 1275 MODULE_DEVICE_TABLE(acpi, mlxbf_tmfifo_acpi_match); 1276 1277 static struct platform_driver mlxbf_tmfifo_driver = { 1278 .probe = mlxbf_tmfifo_probe, 1279 .remove = mlxbf_tmfifo_remove, 1280...

On 2015/7/30 3:16, Michael S. 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 >

Hello, The following patches are a solution to a problem we have encountered when using the Xen hypervisor: - Need Pxx/Cxx states to save on power consumption when using Xen (we do want those datacenters to consume less power!), - Also need to figure out the Turbo mode so that the scheduler can properly boost a core for CPU bound guests. In essence the Xen hypervisor requires that

...acpi_device *device, + int type) +{ + int num_cpus = 0; + + mutex_lock(&xen_cpu_lock); + xen_acpi_pad_idle_cpus(&num_cpus); + mutex_unlock(&xen_cpu_lock); + + acpi_remove_notify_handler(device->handle, + ACPI_DEVICE_NOTIFY, xen_acpi_pad_notify); + return 0; +} + +static const struct acpi_device_id xen_pad_device_ids[] = { + {"ACPI000C", 0}, + {"", 0}, +}; + +static struct acpi_driver xen_acpi_pad_driver = { + .name = "processor_aggregator", + .class = ACPI_PROCESSOR_AGGREGATOR_CLASS, + .ids = xen_pad_device_ids, + .ops = { + .add = xen_acpi_pad_add, + .remove...

This is a resend of the patches yet to be applied. This patch-set addresses some of the bus/driver model cleanup that Greg sugested over the last couple of days. In this patch-set we deal with the following issues: 1) Cleanup error handling in the vmbus_probe() and vmbus_child_device_register() functions. Fixed a bug in the probe failure path as part of this cleanup. 2) The Windows

This is a resend of the patches yet to be applied. This patch-set addresses some of the bus/driver model cleanup that Greg sugested over the last couple of days. In this patch-set we deal with the following issues: 1) Cleanup error handling in the vmbus_probe() and vmbus_child_device_register() functions. Fixed a bug in the probe failure path as part of this cleanup. 2) The Windows