I have no love lost for proprietary modules but changing
acpi_bus_get_device() symbol's license seems gratuitous considering
the symbol pre-dates the mainline git tree and the code is just
being moved from one source file to another.
Regards,
Peter Hurley
On Tuesday, October 01, 2013 12:59:53 PM Peter Hurley wrote:
> I have no love lost for proprietary modules but changing
> acpi_bus_get_device() symbol's license seems gratuitous considering
> the symbol pre-dates the mainline git tree and the code is just
> being moved from one source file to another.
Well, I didn't know whether or not any binary modules use that function in the
first place.
It looks like some of them do, so below is a revert of that change (that I'm
going to push for -rc4).
I wonder what module exactly you have in mind, though?
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Subject: ACPI: Use EXPORT_SYMBOL() for acpi_bus_get_device()
Commit caf5c03f (ACPI: Move acpi_bus_get_device() from bus.c to
scan.c) caused acpi_bus_get_device() to be exported using
EXPORT_SYMBOL_GPL(), but that broke some binary drivers in
existence, so revert that change.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/acpi/scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/drivers/acpi/scan.c
===================================================================
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -968,7 +968,7 @@ int acpi_bus_get_device(acpi_handle hand
}
return 0;
}
-EXPORT_SYMBOL_GPL(acpi_bus_get_device);
+EXPORT_SYMBOL(acpi_bus_get_device);
int acpi_device_add(struct acpi_device *device,
void (*release)(struct device *))
On 10/01/2013 05:00 PM, Rafael J. Wysocki wrote:
> On Tuesday, October 01, 2013 12:59:53 PM Peter Hurley wrote:
>> I have no love lost for proprietary modules but changing
>> acpi_bus_get_device() symbol's license seems gratuitous considering
>> the symbol pre-dates the mainline git tree and the code is just
>> being moved from one source file to another.
>
> Well, I didn't know whether or not any binary modules use that function in the
> first place.
>
> It looks like some of them do, so below is a revert of that change (that I'm
> going to push for -rc4).
>
> I wonder what module exactly you have in mind, though?
For 3.12, the nouveau driver wants to use MSIs by default.
Unfortunately, some hardware which should support it doesn't.
The binary driver recently migrated to MSIs by default as well,
so I was testing to see if the hardware could run stably with that
driver with MSIs on (since I don't use the binary driver, I needed to
experiment).
Switching back and forth between the drivers is really error-prone;
instead, I sacrificed an older partition/userspace, where I confirmed
that the binary driver does run stably with MSIs -- on kernel 3.2.x.
When I tried to repeat the testing on 3.12-rc2 & -rc3, I happened
upon this change.
Regards,
Peter Hurley