[PATCH 08/10] dell-laptop: Sync current block state to BIOS on hw switch change
This is necessary for 3 reasons:
1) To apply sw_state changes made while hw-blocked
2) To set all the blocked bits for hw-switch controlled radios to 1 when the
switch gets changed to off, this is necessary on some models to actually
turn the radio status LEDs off.
3) On some models non hw-switch controlled radios will have their block bit
cleared (potentially undoing a soft-block) on hw-switch toggle, this
restores the sw-block in this case.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 834f499..7f59624 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -422,10 +422,16 @@ out:
return 0;
}
+/* Must be called with the buffer held */
static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
int status)
{
- if (!(status BIT(0))) {
+ if (status BIT(0)) {
+ /* Has hw-switch, sync sw_state to BIOS */
+ int block = rfkill_blocked(rfkill);
+ buffer-input[0] = (1 | (radio 8) | (block 16));
+ dell_send_request(buffer, 17, 11);
+ } else {
/* No hw-switch, sync BIOS state to sw_state */
rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
}
@@ -445,9 +451,10 @@ static void dell_rfkill_query(struct rfkill *rfkill, void
*data)
get_buffer();
dell_send_request(buffer, 17, 11);
status = buffer-output[1];
- release_buffer();
dell_rfkill_update_hw_state(rfkill, (unsigned long)data, status);
+
+ release_buffer();
}
static const struct rfkill_ops dell_rfkill_ops = {
@@ -531,7 +538,6 @@ static void dell_update_rfkill(struct work_struct *ignored)
get_buffer();
dell_send_request(buffer, 17, 11);
status = buffer-output[1];
- release_buffer();
if (wifi_rfkill) {
dell_rfkill_update_hw_state(wifi_rfkill, 1, status);
@@ -545,6 +551,8 @@ static void dell_update_rfkill(struct work_struct *ignored)
dell_rfkill_update_hw_state(wwan_rfkill, 3, status);
dell_rfkill_update_sw_state(wwan_rfkill, 3, status);
}
+
+ release_buffer();
}
static DECLARE_DELAYED_WORK(dell_rfkill_work, dell_update_rfkill);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] dell-laptop: Bring back (limited) rfkill support
Hi Matthew et al, As the subject already says this patch-set intends to bring back (and fixup) dell-laptop rfkill support. I know this was killed with a good reason, still I want to bring it back. I've 3 different Latitudes in use in my home, spanning 6 generations of Latitudes, and without dell-laptop rfkill support these have the following issues: 1) If the hardware radio switch is set to disable the radio, then userspace will still think it can use wireless and bluetooth, this sometimes greatly confuses other users (wife and children) of these laptops. 2) The wwan / 3g modem in one of them cannot be disabled 3) When turning off bluetooth or wife in the UI, the status leds on the laptop for these will stay on Now this may not seem like big issues, but with these fixed the overall user experience of the laptop when there is a need to disable radios just feels much better. AFAIK the rfkill functionality was removed from the dell-laptop driver because it caused more problems then it fixed, and the blacklist for it was growing out of control. But in the thread discussing this Dell mentioned that they only QA the rfkill acpi interface on Latitudes and indeed there have been no blacklist entries for Latitudes. This combined with me owning a bunch of Latitudes has lead to this patchset, which brings back rfkill functionality, but for Latitudes only, getting rid of the blacklist. Note that only limiting the support to Latitudes is not enough to get rid of all the rough edges of the rfkill support. Because the driver itself has some issues / bad interactions with the firmware too. I've spend the last 2 days doing a lot of testing on 3 different Latitudes, a D620, E6400 and E6430, and this has resulted in a bunch of fixes to the rfkill support, hence this patch-set has 10 patches total. I've tested the final result of the patch set on all 3 models in various different circumstances, booting with the hwswitch on / off, suspend/resume, changing hwswitch state during suspend in either direction, etc. This now all works flawless on the Latitude series, therefor I'm confident that bringing back rfkill support for Latitudes only should not cause any issues. Moreover I'm willing to put my time where my mouth is and I'm willing to maintain the rfkill portion of the driver, deal with any bugreports, etc. Open questions: 1) Should we maybe also bring back rfkill for Vostros ? Looking at the blacklist and mailinglist archives it seems that all models with issues were Inspirons. I honestly don't know what the best answer to this question is, one option would be adding a module option which allows by-passing the Latitude check and to gather feedback, then decide based on that. 2) Should we maybe limit support to models with a hw kill switch ? One big difference between Latitudes/Vostros and Inspirons is that the former tend to have a hw kill switch, where as the later uses a keyboard combo which gets intercepted by the firmware to toggle the radio, and the latter seems to be where most of the troubles are. More over my own testbed only has machines with a hw kill switch (there are some older Latitude models which lack a hardware switch). I tend towards limiting support to only models with a hardware switch, with an option to override this check using a module option. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] dell-laptop: Don't set sw_state from the query callback
The query callback should only update the hw_state, see the comment in
net/rfkill/core.c in rfkill_set_block, which is its only caller.
rfkill_set_block will modify the sw_state directly after calling query so
calling set_sw_state is an expensive NOP.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 06f281b..7f47396 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -425,10 +425,15 @@ out:
return ret;
}
-static void dell_rfkill_update(struct rfkill *rfkill, int radio, int status)
+static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
+ int status)
{
rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+}
+static void dell_rfkill_update_hw_state(struct rfkill *rfkill, int radio,
+ int status)
+{
if (hwswitch_state (BIT(radio - 1)))
rfkill_set_hw_state(rfkill, !(status BIT(16)));
}
@@ -442,7 +447,7 @@ static void dell_rfkill_query(struct rfkill *rfkill, void
*data)
status = buffer-output[1];
release_buffer();
- dell_rfkill_update(rfkill, (unsigned long)data, status);
+ dell_rfkill_update_hw_state(rfkill, (unsigned long)data, status);
}
static const struct rfkill_ops dell_rfkill_ops = {
@@ -528,12 +533,18 @@ static void dell_update_rfkill(struct work_struct
*ignored)
status = buffer-output[1];
release_buffer();
- if (wifi_rfkill)
- dell_rfkill_update(wifi_rfkill, 1, status);
- if (bluetooth_rfkill)
- dell_rfkill_update(bluetooth_rfkill, 2, status);
- if (wwan_rfkill)
- dell_rfkill_update(wwan_rfkill, 3, status);
+ if (wifi_rfkill) {
+ dell_rfkill_update_hw_state(wifi_rfkill, 1, status);
+ dell_rfkill_update_sw_state(wifi_rfkill, 1, status);
+ }
+ if (bluetooth_rfkill) {
+ dell_rfkill_update_hw_state(bluetooth_rfkill, 2, status);
+ dell_rfkill_update_sw_state(bluetooth_rfkill, 2, status);
+ }
+ if (wwan_rfkill) {
+ dell_rfkill_update_hw_state(wwan_rfkill, 3, status);
+ dell_rfkill_update_sw_state(wwan_rfkill, 3, status);
+ }
}
static DECLARE_DELAYED_WORK(dell_rfkill_work, dell_update_rfkill);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] dell-laptop: Don't read-back sw_state on machines with a hardware switch
On machines with a hardware switch, the blocking settings can not be changed
through a Fn + wireless-key combo, so there is no reason to read back the
blocking state from the BIOS.
Reading back is not only not necessary it is actually harmful, since on some
machines the blocking state will be cleared to all 0 after a wireless switch
toggle, even for radios not controlled by the hw-switch (yeah firmware bugs).
This causes magic changes to the sw_state. This is inconsistent with other
rfkill drivers which preserve the sw_state over a hw kill on / off.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 7f47396..80de0cc 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -428,7 +428,10 @@ out:
static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
int status)
{
- rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+ if (!(status BIT(0))) {
+ /* No hw-switch, sync BIOS state to sw_state */
+ rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+ }
}
static void dell_rfkill_update_hw_state(struct rfkill *rfkill, int radio,
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] dell-laptop: If there is no hwswitch, then clear all hw-controlled bits
To ensure we don't enter any hw-switch related code paths on machines without
a hw-switch.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index bae932b..48fabf6 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -548,6 +548,9 @@ static int __init dell_setup_rfkill(void)
buffer-input[0] = 0x2;
dell_send_request(buffer, 17, 11);
hwswitch_state = buffer-output[1];
+ /* If there is no hwswitch, then clear all hw-controlled bits */
+ if (!(status BIT(0)))
+ hwswitch_state = ~7;
release_buffer();
if ((status (12|18)) == (12|18)) {
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] dell-laptop: Only enable rfkill on Latitudes
The rfkill functionality was removed from the dell-laptop driver because it
was causing problems on various non Latitude models, and the blacklist kept
growing and growing. In the thread discussing this Dell mentioned that they
only QA the rfkill acpi interface on Latitudes and indeed there have been
no blacklist entries for Latitudes.
Note that the blacklist contained no Vostros either, and most Vostros have
a hardware switch too, so we could consider supporting Vostros with a
hardware switch too.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 57 +-
1 file changed, 7 insertions(+), 50 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 55f75a2..bae932b 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -119,53 +119,6 @@ static const struct dmi_system_id dell_device_table[]
__initconst = {
};
MODULE_DEVICE_TABLE(dmi, dell_device_table);
-static struct dmi_system_id dell_blacklist[] = {
- /* Supported by compal-laptop */
- {
- .ident = Dell Mini 9,
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
- DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 910),
- },
- },
- {
- .ident = Dell Mini 10,
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
- DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1010),
- },
- },
- {
- .ident = Dell Mini 10v,
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
- DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1011),
- },
- },
- {
- .ident = Dell Mini 1012,
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
- DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1012),
- },
- },
- {
- .ident = Dell Inspiron 11z,
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
- DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1110),
- },
- },
- {
- .ident = Dell Mini 12,
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
- DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1210),
- },
- },
- {}
-};
-
static struct dmi_system_id dell_quirks[] = {
{
.callback = dmi_matched,
@@ -579,11 +532,15 @@ static int __init dell_setup_rfkill(void)
{
int status;
int ret;
+ const char *product;
- if (dmi_check_system(dell_blacklist)) {
- pr_info(Blacklisted hardware detected - not enabling
rfkill\n);
+ /*
+* rfkill causes trouble on various non Latitudes, according to Dell
+* actually testing the rfkill functionality is only done on Latitudes.
+*/
+ product = dmi_get_system_info(DMI_PRODUCT_NAME);
+ if (!product || strncmp(product, Latitude, 8))
return 0;
- }
get_buffer();
dell_send_request(buffer, 17, 11);
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] Revert dell-laptop: Remove rfkill code
Without rfkill functionality in dell-laptop I have the following problems:
-If the hardware radio switch is set to disable the radio, then userspace
will still think it can use wireless and bluetooth.
-The wwan / 3g modem cannot be soft blocked without the dell-laptop rfkill
functionality
I know the rfkill functionality was removed from the dell-laptop driver because
it caused more problems then it fixed, and the blacklist for it was growing out
of control.
But in the thread discussing this Dell mentioned that they only QA the rfkill
acpi interface on Latitudes and indeed there have been no blacklist entries
for Latitudes. Therefor I would like to bring the rfkill functionality back
only for Latitudes. This patch is a straight-forward revert. The next patch
in this set will drop the blacklist and replace it with a Latitude check.
This reverts commit a6c2390cd6d2083d27a2359658e08f2d3df375ac.
Conflicts:
drivers/platform/x86/dell-laptop.c
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 289 +
1 file changed, 289 insertions(+)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index bb77e18..55f75a2 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -21,6 +21,7 @@
#include linux/err.h
#include linux/dmi.h
#include linux/io.h
+#include linux/rfkill.h
#include linux/power_supply.h
#include linux/acpi.h
#include linux/mm.h
@@ -89,6 +90,9 @@ static struct platform_driver platform_driver = {
static struct platform_device *platform_device;
static struct backlight_device *dell_backlight_device;
+static struct rfkill *wifi_rfkill;
+static struct rfkill *bluetooth_rfkill;
+static struct rfkill *wwan_rfkill;
static const struct dmi_system_id dell_device_table[] __initconst = {
{
@@ -115,6 +119,53 @@ static const struct dmi_system_id dell_device_table[]
__initconst = {
};
MODULE_DEVICE_TABLE(dmi, dell_device_table);
+static struct dmi_system_id dell_blacklist[] = {
+ /* Supported by compal-laptop */
+ {
+ .ident = Dell Mini 9,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 910),
+ },
+ },
+ {
+ .ident = Dell Mini 10,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1010),
+ },
+ },
+ {
+ .ident = Dell Mini 10v,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1011),
+ },
+ },
+ {
+ .ident = Dell Mini 1012,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1012),
+ },
+ },
+ {
+ .ident = Dell Inspiron 11z,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1110),
+ },
+ },
+ {
+ .ident = Dell Mini 12,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, Inspiron 1210),
+ },
+ },
+ {}
+};
+
static struct dmi_system_id dell_quirks[] = {
{
.callback = dmi_matched,
@@ -355,6 +406,94 @@ dell_send_request(struct calling_interface_buffer *buffer,
int class,
return buffer;
}
+/* Derived from information in DellWirelessCtl.cpp:
+ Class 17, select 11 is radio control. It returns an array of 32-bit values.
+
+ Input byte 0 = 0: Wireless information
+
+ result[0]: return code
+ result[1]:
+ Bit 0: Hardware switch supported
+ Bit 1: Wifi locator supported
+ Bit 2: Wifi is supported
+ Bit 3: Bluetooth is supported
+ Bit 4: WWAN is supported
+ Bit 5: Wireless keyboard supported
+ Bits 6-7: Reserved
+ Bit 8: Wifi is installed
+ Bit 9: Bluetooth is installed
+ Bit 10: WWAN is installed
+ Bits 11-15: Reserved
+ Bit 16: Hardware switch is on
+ Bit 17: Wifi is blocked
+ Bit 18: Bluetooth is blocked
+ Bit 19: WWAN is blocked
+ Bits 20-31: Reserved
+ result[2]: NVRAM size in bytes
+ result[3]: NVRAM format version number
+
+ Input byte 0 = 2: Wireless switch configuration
+ result[0]: return code
+ result[1]:
+ Bit 0: Wifi controlled by switch
+ Bit 1: Bluetooth controlled by switch
+ Bit 2: WWAN controlled by switch
+ Bits 3-6: Reserved
+ Bit 7: Wireless switch config locked
+ Bit 8
[PATCH 06/12] dell-laptop: Don't read-back sw_state on machines with a hardware switch
On machines with a hardware switch, the blocking settings can not be changed
through a Fn + wireless-key combo, so there is no reason to read back the
blocking state from the BIOS.
Reading back is not only not necessary it is actually harmful, since on some
machines the blocking state will be cleared to all 0 after a wireless switch
toggle, even for radios not controlled by the hw-switch (yeah firmware bugs).
This causes magic changes to the sw_state. This is inconsistent with other
rfkill drivers which preserve the sw_state over a hw kill on / off.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 7f47396..80de0cc 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -428,7 +428,10 @@ out:
static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
int status)
{
- rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+ if (!(status BIT(0))) {
+ /* No hw-switch, sync BIOS state to sw_state */
+ rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+ }
}
static void dell_rfkill_update_hw_state(struct rfkill *rfkill, int radio,
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] dell-laptop: Only get status from BIOS once when updating
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 48fabf6..06f281b 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -425,21 +425,24 @@ out:
return ret;
}
+static void dell_rfkill_update(struct rfkill *rfkill, int radio, int status)
+{
+ rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+
+ if (hwswitch_state (BIT(radio - 1)))
+ rfkill_set_hw_state(rfkill, !(status BIT(16)));
+}
+
static void dell_rfkill_query(struct rfkill *rfkill, void *data)
{
int status;
- int bit = (unsigned long)data + 16;
- int hwswitch_bit = (unsigned long)data - 1;
get_buffer();
dell_send_request(buffer, 17, 11);
status = buffer-output[1];
release_buffer();
- rfkill_set_sw_state(rfkill, !!(status BIT(bit)));
-
- if (hwswitch_state (BIT(hwswitch_bit)))
- rfkill_set_hw_state(rfkill, !(status BIT(16)));
+ dell_rfkill_update(rfkill, (unsigned long)data, status);
}
static const struct rfkill_ops dell_rfkill_ops = {
@@ -518,12 +521,19 @@ static const struct file_operations dell_debugfs_fops = {
static void dell_update_rfkill(struct work_struct *ignored)
{
+ int status;
+
+ get_buffer();
+ dell_send_request(buffer, 17, 11);
+ status = buffer-output[1];
+ release_buffer();
+
if (wifi_rfkill)
- dell_rfkill_query(wifi_rfkill, (void *)1);
+ dell_rfkill_update(wifi_rfkill, 1, status);
if (bluetooth_rfkill)
- dell_rfkill_query(bluetooth_rfkill, (void *)2);
+ dell_rfkill_update(bluetooth_rfkill, 2, status);
if (wwan_rfkill)
- dell_rfkill_query(wwan_rfkill, (void *)3);
+ dell_rfkill_update(wwan_rfkill, 3, status);
}
static DECLARE_DELAYED_WORK(dell_rfkill_work, dell_update_rfkill);
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] dell-laptop: Do not skip setting blocked bit rfkill_set while hw-blocked
Instead when hw-blocked always write 1 to the blocked bit for the radio in question. This is necessary to properly set all the blocked bits for hw-switch controlled radios to 1 after power-on and resume. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/dell-laptop.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c index 7f59624..b33b779 100644 --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -409,15 +409,14 @@ static int dell_rfkill_set(void *data, bool blocked) dell_send_request(buffer, 17, 11); /* If the hardware switch controls this radio, and the hardware - switch is disabled, don't allow changing the software state */ + switch is disabled, always disable the radio */ if ((hwswitch_state BIT(hwswitch_bit)) !(buffer-output[1] BIT(16))) - goto out; + disable = 1; buffer-input[0] = (1 | (radio8) | (disable 16)); dell_send_request(buffer, 17, 11); -out: release_buffer(); return 0; } -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] dell-laptop: Wait less long before updating rfkill after an rfkill keypress
Some time is needed for the BIOS to do its work, but 250ms should be plenty.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index b33b779..fe20f67 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -759,7 +759,7 @@ static bool dell_laptop_i8042_filter(unsigned char data,
unsigned char str,
switch (data) {
case 0x8:
schedule_delayed_work(dell_rfkill_work,
- round_jiffies_relative(HZ));
+ round_jiffies_relative(HZ / 4));
break;
}
extended = false;
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] dell-laptop: Only enable rfkill functionality on laptops with a hw killswitch
All my testing has been on laptops with a hw killswitch, so to be on the
safe side disable rfkill functionality on models without a hw killswitch for
now. Once we gather some feedback on laptops without a hw killswitch this
decision maybe reconsidered.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index bd67c89..c608b1d 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -580,11 +580,18 @@ static int __init dell_setup_rfkill(void)
buffer-input[0] = 0x2;
dell_send_request(buffer, 17, 11);
hwswitch_state = buffer-output[1];
- /* If there is no hwswitch, then clear all hw-controlled bits */
- if (!(status BIT(0)))
- hwswitch_state = ~7;
release_buffer();
+ if (!(status BIT(0))) {
+ if (force_rfkill) {
+ /* No hwsitch, clear all hw-controlled bits */
+ hwswitch_state = ~7;
+ } else {
+ /* rfkill is only tested on laptops with a hwswitch */
+ return 0;
+ }
+ }
+
if ((status (12|18)) == (12|18)) {
wifi_rfkill = rfkill_alloc(dell-wifi, platform_device-dev,
RFKILL_TYPE_WLAN,
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/12] dell-laptop: Don't set sw_state from the query callback
The query callback should only update the hw_state, see the comment in
net/rfkill/core.c in rfkill_set_block, which is its only caller.
rfkill_set_block will modify the sw_state directly after calling query so
calling set_sw_state is an expensive NOP.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 06f281b..7f47396 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -425,10 +425,15 @@ out:
return ret;
}
-static void dell_rfkill_update(struct rfkill *rfkill, int radio, int status)
+static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
+ int status)
{
rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
+}
+static void dell_rfkill_update_hw_state(struct rfkill *rfkill, int radio,
+ int status)
+{
if (hwswitch_state (BIT(radio - 1)))
rfkill_set_hw_state(rfkill, !(status BIT(16)));
}
@@ -442,7 +447,7 @@ static void dell_rfkill_query(struct rfkill *rfkill, void
*data)
status = buffer-output[1];
release_buffer();
- dell_rfkill_update(rfkill, (unsigned long)data, status);
+ dell_rfkill_update_hw_state(rfkill, (unsigned long)data, status);
}
static const struct rfkill_ops dell_rfkill_ops = {
@@ -528,12 +533,18 @@ static void dell_update_rfkill(struct work_struct
*ignored)
status = buffer-output[1];
release_buffer();
- if (wifi_rfkill)
- dell_rfkill_update(wifi_rfkill, 1, status);
- if (bluetooth_rfkill)
- dell_rfkill_update(bluetooth_rfkill, 2, status);
- if (wwan_rfkill)
- dell_rfkill_update(wwan_rfkill, 3, status);
+ if (wifi_rfkill) {
+ dell_rfkill_update_hw_state(wifi_rfkill, 1, status);
+ dell_rfkill_update_sw_state(wifi_rfkill, 1, status);
+ }
+ if (bluetooth_rfkill) {
+ dell_rfkill_update_hw_state(bluetooth_rfkill, 2, status);
+ dell_rfkill_update_sw_state(bluetooth_rfkill, 2, status);
+ }
+ if (wwan_rfkill) {
+ dell_rfkill_update_hw_state(wwan_rfkill, 3, status);
+ dell_rfkill_update_sw_state(wwan_rfkill, 3, status);
+ }
}
static DECLARE_DELAYED_WORK(dell_rfkill_work, dell_update_rfkill);
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] dell-laptop: Add a force_rfkill module parameter
Setting force_rfkill will cause the dell-laptop rfkill code to skip its
whitelist checks, this will allow individual users to override the whitelist,
as well as to gather info from users to improve the checks.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index fe20f67..bd67c89 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -93,6 +93,10 @@ static struct backlight_device *dell_backlight_device;
static struct rfkill *wifi_rfkill;
static struct rfkill *bluetooth_rfkill;
static struct rfkill *wwan_rfkill;
+static bool force_rfkill;
+
+module_param(force_rfkill, bool, 0444);
+MODULE_PARM_DESC(force_rfkill, enable rfkill on non whitelisted models);
static const struct dmi_system_id dell_device_table[] __initconst = {
{
@@ -567,7 +571,7 @@ static int __init dell_setup_rfkill(void)
* actually testing the rfkill functionality is only done on Latitudes.
*/
product = dmi_get_system_info(DMI_PRODUCT_NAME);
- if (!product || strncmp(product, Latitude, 8))
+ if (!force_rfkill (!product || strncmp(product, Latitude, 8)))
return 0;
get_buffer();
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] dell-laptop: Allow changing the sw_state while the radio is blocked by hw
This makes dell-laptop's rfkill code consistent with other drivers which
allow sw_state changes while hw blocked.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 80de0cc..834f499 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -404,7 +404,6 @@ static int dell_rfkill_set(void *data, bool blocked)
int disable = blocked ? 1 : 0;
unsigned long radio = (unsigned long)data;
int hwswitch_bit = (unsigned long)data - 1;
- int ret = 0;
get_buffer();
dell_send_request(buffer, 17, 11);
@@ -412,17 +411,15 @@ static int dell_rfkill_set(void *data, bool blocked)
/* If the hardware switch controls this radio, and the hardware
switch is disabled, don't allow changing the software state */
if ((hwswitch_state BIT(hwswitch_bit))
- !(buffer-output[1] BIT(16))) {
- ret = -EINVAL;
+ !(buffer-output[1] BIT(16)))
goto out;
- }
buffer-input[0] = (1 | (radio8) | (disable 16));
dell_send_request(buffer, 17, 11);
out:
release_buffer();
- return ret;
+ return 0;
}
static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/12] dell-laptop: Sync current block state to BIOS on hw switch change
This is necessary for 3 reasons:
1) To apply sw_state changes made while hw-blocked
2) To set all the blocked bits for hw-switch controlled radios to 1 when the
switch gets changed to off, this is necessary on some models to actually
turn the radio status LEDs off.
3) On some models non hw-switch controlled radios will have their block bit
cleared (potentially undoing a soft-block) on hw-switch toggle, this
restores the sw-block in this case.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/dell-laptop.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index 834f499..7f59624 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -422,10 +422,16 @@ out:
return 0;
}
+/* Must be called with the buffer held */
static void dell_rfkill_update_sw_state(struct rfkill *rfkill, int radio,
int status)
{
- if (!(status BIT(0))) {
+ if (status BIT(0)) {
+ /* Has hw-switch, sync sw_state to BIOS */
+ int block = rfkill_blocked(rfkill);
+ buffer-input[0] = (1 | (radio 8) | (block 16));
+ dell_send_request(buffer, 17, 11);
+ } else {
/* No hw-switch, sync BIOS state to sw_state */
rfkill_set_sw_state(rfkill, !!(status BIT(radio + 16)));
}
@@ -445,9 +451,10 @@ static void dell_rfkill_query(struct rfkill *rfkill, void
*data)
get_buffer();
dell_send_request(buffer, 17, 11);
status = buffer-output[1];
- release_buffer();
dell_rfkill_update_hw_state(rfkill, (unsigned long)data, status);
+
+ release_buffer();
}
static const struct rfkill_ops dell_rfkill_ops = {
@@ -531,7 +538,6 @@ static void dell_update_rfkill(struct work_struct *ignored)
get_buffer();
dell_send_request(buffer, 17, 11);
status = buffer-output[1];
- release_buffer();
if (wifi_rfkill) {
dell_rfkill_update_hw_state(wifi_rfkill, 1, status);
@@ -545,6 +551,8 @@ static void dell_update_rfkill(struct work_struct *ignored)
dell_rfkill_update_hw_state(wwan_rfkill, 3, status);
dell_rfkill_update_sw_state(wwan_rfkill, 3, status);
}
+
+ release_buffer();
}
static DECLARE_DELAYED_WORK(dell_rfkill_work, dell_update_rfkill);
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dell-laptop: Only install the i8042 filter when rfkill is active
Hi, On 12/24/2013 08:34 PM, Hans de Goede wrote: Installing the i8042 filter is not useful on machines where rfkill is not whitelisted, so move the filter installation into dell_setup_rfkill, after the whitelist check. p.s. Note the cleanup paths are not changed, I did not bother with tracking if we have installed the filter and only calling i8042_remove_filter if we have, because i8042_remove_filter is a nop of the passed in filter is not installed. -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on T440s
The T440s user guide says that when Fn-lock is not active, the T440s' F9 - F12 keys should be mapped to: control-panel, search, show-all-windows and Computer. These keys generate the sofar unused 28 - 31 hotkey scancodes. For the first 2 this nicely matches the icons on the keys, for the latter 2 the icons are somewhat creative, which is why I ended up looking them up in the user manual. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/thinkpad_acpi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index defb6af..ecb4bc2 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -3167,8 +3167,10 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) KEY_MICMUTE,/* 0x1a: Mic mute (since ?400 or so) */ /* (assignments unknown, please report if found) */ - KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, + + /* Extra keys found on the T440(s) */ + KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_COMPUTER, }, }; -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] input/serio: Add a firmware_id sysfs attribute
serio devices exposed via platform firmware interfaces such as ACPI
may provide additional identifying information of use to userspace.
We don't associate the serio devices with the firmware device (we don't
set it as parent), so there's no way for userspace to make use of this
information.
We cannot change the parent for serio devices instantiated though a firmware
interface as that would break suspend / resume ordering.
Therefor this patch adds a new firmware_id sysfs attribute so that userspace
can get a string from there with any additional identifying information the
firmware interface may provide.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/input/serio/serio.c | 12
include/linux/serio.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 8f4c4ab..1788a4d 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -451,6 +451,13 @@ static ssize_t serio_set_bind_mode(struct device *dev,
struct device_attribute *
return retval;
}
+static ssize_t firmware_id_show(struct device *dev, struct device_attribute
*attr, char *buf)
+{
+ struct serio *serio = to_serio_port(dev);
+
+ return sprintf(buf, %s\n, serio-firmware_id);
+}
+
static DEVICE_ATTR_RO(type);
static DEVICE_ATTR_RO(proto);
static DEVICE_ATTR_RO(id);
@@ -473,12 +480,14 @@ static DEVICE_ATTR_RO(modalias);
static DEVICE_ATTR_WO(drvctl);
static DEVICE_ATTR(description, S_IRUGO, serio_show_description, NULL);
static DEVICE_ATTR(bind_mode, S_IWUSR | S_IRUGO, serio_show_bind_mode,
serio_set_bind_mode);
+static DEVICE_ATTR_RO(firmware_id);
static struct attribute *serio_device_attrs[] = {
dev_attr_modalias.attr,
dev_attr_description.attr,
dev_attr_drvctl.attr,
dev_attr_bind_mode.attr,
+ dev_attr_firmware_id.attr,
NULL
};
@@ -923,6 +932,9 @@ static int serio_uevent(struct device *dev, struct
kobj_uevent_env *env)
SERIO_ADD_UEVENT_VAR(SERIO_EXTRA=%02x, serio-id.extra);
SERIO_ADD_UEVENT_VAR(MODALIAS=serio:ty%02Xpr%02Xid%02Xex%02X,
serio-id.type, serio-id.proto, serio-id.id,
serio-id.extra);
+ if (serio-firmware_id[0])
+ SERIO_ADD_UEVENT_VAR(SERIO_FIRMWARE_ID=%s,
+serio-firmware_id);
return 0;
}
diff --git a/include/linux/serio.h b/include/linux/serio.h
index 36aac73..9f779c7 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -23,6 +23,7 @@ struct serio {
char name[32];
char phys[32];
+ char firmware_id[128];
bool manual_bind;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] input/serio/8042: Add firmware_id support
Fill in the new serio firmware_id sysfs attribute for pnp instantiated
8042 serio ports.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/input/serio/i8042-x86ia64io.h | 26 ++
drivers/input/serio/i8042.c | 6 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 0ec9abb..3f9da83 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -704,6 +704,8 @@ static char i8042_pnp_aux_name[32];
static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id
*did)
{
+ struct pnp_id *id = dev-id;
+
if (pnp_port_valid(dev, 0) pnp_port_len(dev, 0) == 1)
i8042_pnp_data_reg = pnp_port_start(dev,0);
@@ -719,6 +721,17 @@ static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const
struct pnp_device_id *
strlcat(i8042_pnp_kbd_name, pnp_dev_name(dev),
sizeof(i8042_pnp_kbd_name));
}
+ if (id) {
+ strlcpy(i8042_kbd_firmware_id, id-id,
+ sizeof(i8042_kbd_firmware_id));
+ for (id = id-next; id; id = id-next) {
+ strlcat(i8042_kbd_firmware_id, ,
+ sizeof(i8042_kbd_firmware_id));
+ strlcat(i8042_kbd_firmware_id, id-id,
+ sizeof(i8042_kbd_firmware_id));
+ }
+ }
+
/* Keyboard ports are always supposed to be wakeup-enabled */
device_set_wakeup_enable(dev-dev, true);
@@ -728,6 +741,8 @@ static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const
struct pnp_device_id *
static int i8042_pnp_aux_probe(struct pnp_dev *dev, const struct pnp_device_id
*did)
{
+ struct pnp_id *id = dev-id;
+
if (pnp_port_valid(dev, 0) pnp_port_len(dev, 0) == 1)
i8042_pnp_data_reg = pnp_port_start(dev,0);
@@ -743,6 +758,17 @@ static int i8042_pnp_aux_probe(struct pnp_dev *dev, const
struct pnp_device_id *
strlcat(i8042_pnp_aux_name, pnp_dev_name(dev),
sizeof(i8042_pnp_aux_name));
}
+ if (id) {
+ strlcpy(i8042_aux_firmware_id, id-id,
+ sizeof(i8042_aux_firmware_id));
+ for (id = id-next; id; id = id-next) {
+ strlcat(i8042_aux_firmware_id, ,
+ sizeof(i8042_aux_firmware_id));
+ strlcat(i8042_aux_firmware_id, id-id,
+ sizeof(i8042_aux_firmware_id));
+ }
+ }
+
i8042_pnp_aux_devices++;
return 0;
}
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 020053f..3807c3e 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -87,6 +87,8 @@ MODULE_PARM_DESC(debug, Turn i8042 debugging mode on and
off);
#endif
static bool i8042_bypass_aux_irq_test;
+static char i8042_kbd_firmware_id[128];
+static char i8042_aux_firmware_id[128];
#include i8042.h
@@ -1218,6 +1220,8 @@ static int __init i8042_create_kbd_port(void)
serio-dev.parent = i8042_platform_device-dev;
strlcpy(serio-name, i8042 KBD port, sizeof(serio-name));
strlcpy(serio-phys, I8042_KBD_PHYS_DESC, sizeof(serio-phys));
+ strlcpy(serio-firmware_id, i8042_kbd_firmware_id,
+ sizeof(serio-firmware_id));
port-serio = serio;
port-irq = I8042_KBD_IRQ;
@@ -1244,6 +1248,8 @@ static int __init i8042_create_aux_port(int idx)
if (idx 0) {
strlcpy(serio-name, i8042 AUX port, sizeof(serio-name));
strlcpy(serio-phys, I8042_AUX_PHYS_DESC, sizeof(serio-phys));
+ strlcpy(serio-firmware_id, i8042_aux_firmware_id,
+ sizeof(serio-firmware_id));
serio-close = i8042_port_close;
} else {
snprintf(serio-name, sizeof(serio-name), i8042 AUX%d port,
idx);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] input/serio: Add a firmware_id sysfs attribute
Hi All, For firmware instantiated serio devices, such as devices instantiated through ACPI, it may be useful for userspace to know the firmware-id (pnp-id in case of ACPI) through which the device was instantiated. One concrete example of this is the new ps/2 touchpads found in Lenovo Thinkpad X240 T440 and T540 laptops, which not only have a special bottom right click area to emulate right clicks, but also top middle and top right areas to emulate middle and right clicks for the trackpoint. Lenove has given these touchpads a unique LEN pnp-id and we would like to use this to automatically enable emulation of middle and right buttons in the top area of the clickpad. Matthew Garret wrote a patch to set the parent of the serio port to the /sys/devices/pnp0/00:xx device so that we could get the necessary info that way, but Dmitry rightfully pointed out that that would break suspend/resume ordering, see: https://lkml.org/lkml/2014/2/23/63 https://lkml.org/lkml/2014/3/7/428 So while discussing this with Peter Hutterer I made the plan to add a /dev/devices/platform/i8042/serioX/firmware_parent symlink pointing to the relevant /sys/devices/pnp0/00:xx device, and add a little udev-helper + rules file to read this symlink and add an attribute to the udevdb with the pnp-id this way. This however is harder then it sounds, I spend a couple of hours on how to do this in a race free manner and I could not come up with one. The problem is that the sysfs_create_symlink call needs to be done after the device_add call, at which point an add uevent has already been fired. Causing a theoretical race where the udev-helper would not find the symlink, this can be fixed with an extra change event after adding the symlink, but then any higher userspace levels need to re-check on a change event as well. So after spending too much time on this I decided to go for an alternative solution. Which in the end turns out to be much nicer too, since it gets rid of needing a udev-helper too. After this much too long introduction I'll let the patches speak for themselves. With this patch-set one can now do: [hans@shalem linux]$ udevadm info -p /devices/platform/i8042/serio1 P: /devices/platform/i8042/serio1 E: DEVPATH=/devices/platform/i8042/serio1 E: MODALIAS=serio:ty01pr00id00ex00 E: SERIO_EXTRA=00 E: SERIO_FIRMWARE_ID=PNP0f03 PNP0f13 E: SERIO_ID=00 E: SERIO_PROTO=00 E: SERIO_TYPE=01 E: SUBSYSTEM=serio And the info we need is just there in the new SERIO_FIRMWARE_ID attribute, for completeness the patch-set also adds: [hans@shalem linux]$ cat /sys/devices/platform/i8042/serio1/firmware_id PNP0f03 PNP0f13 Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] input/serio: Add a firmware_id sysfs attribute
Hi, On 03/28/2014 08:56 AM, Dmitry Torokhov wrote: On Thu, Mar 20, 2014 at 05:21:59PM +, Matthew Garrett wrote: On Thu, Mar 20, 2014 at 11:12:08AM +0100, Hans de Goede wrote: Which in the end turns out to be much nicer too, since it gets rid of needing a udev-helper too. After this much too long introduction I'll let the patches speak for themselves. Yeah, I was coming to the conclusion that this was probably the best we could do. It's unfortunate that id is already in use - we'd be able to get away without any X server modifications otherwise. Long term we probably still want to tie serio devices to the ACPI devices in case the vendor provides power management calls there, but we can leave that until there's an actual example. I am still unsure if we shoudl be adding these new IDs to serio core... Can't the X driver take a peek at ACPI devices on it's own? The problem is there is no way for userspace to know which /sys/devices/pnp0/00:xx device is the serio bus host. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] input/serio: Add a firmware_id sysfs attribute
Hi, On 03/28/2014 09:17 AM, Dmitry Torokhov wrote: On Fri, Mar 28, 2014 at 09:12:43AM +0100, Hans de Goede wrote: Hi, On 03/28/2014 08:56 AM, Dmitry Torokhov wrote: On Thu, Mar 20, 2014 at 05:21:59PM +, Matthew Garrett wrote: On Thu, Mar 20, 2014 at 11:12:08AM +0100, Hans de Goede wrote: Which in the end turns out to be much nicer too, since it gets rid of needing a udev-helper too. After this much too long introduction I'll let the patches speak for themselves. Yeah, I was coming to the conclusion that this was probably the best we could do. It's unfortunate that id is already in use - we'd be able to get away without any X server modifications otherwise. Long term we probably still want to tie serio devices to the ACPI devices in case the vendor provides power management calls there, but we can leave that until there's an actual example. I am still unsure if we shoudl be adding these new IDs to serio core... Can't the X driver take a peek at ACPI devices on it's own? The problem is there is no way for userspace to know which /sys/devices/pnp0/00:xx device is the serio bus host. Practically speaking you should not care - there is only one touchpad in Lenovos. So are you suggesting we simply go over all /sys/devices/pnp0/00:xx devices looking for a pnp-id we're interested in ? I'm sorry but that is just a non-sense solution, which reminds me of the good old days of random poking io-ports to probe stuff. We're not blindly going to read every /sys/devices/pnp0/00:xx/id attribute on a system, assuming that if it contains a pnp-id we're interested in it happens to belong to the input device we're enumerating at that time. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] input/serio: Add a firmware_id sysfs attribute
Hi, On 03/28/2014 09:52 AM, Dmitry Torokhov wrote: On Fri, Mar 28, 2014 at 09:29:50AM +0100, Hans de Goede wrote: Hi, On 03/28/2014 09:17 AM, Dmitry Torokhov wrote: On Fri, Mar 28, 2014 at 09:12:43AM +0100, Hans de Goede wrote: Hi, On 03/28/2014 08:56 AM, Dmitry Torokhov wrote: On Thu, Mar 20, 2014 at 05:21:59PM +, Matthew Garrett wrote: On Thu, Mar 20, 2014 at 11:12:08AM +0100, Hans de Goede wrote: Which in the end turns out to be much nicer too, since it gets rid of needing a udev-helper too. After this much too long introduction I'll let the patches speak for themselves. Yeah, I was coming to the conclusion that this was probably the best we could do. It's unfortunate that id is already in use - we'd be able to get away without any X server modifications otherwise. Long term we probably still want to tie serio devices to the ACPI devices in case the vendor provides power management calls there, but we can leave that until there's an actual example. I am still unsure if we shoudl be adding these new IDs to serio core... Can't the X driver take a peek at ACPI devices on it's own? The problem is there is no way for userspace to know which /sys/devices/pnp0/00:xx device is the serio bus host. Practically speaking you should not care - there is only one touchpad in Lenovos. So are you suggesting we simply go over all /sys/devices/pnp0/00:xx devices looking for a pnp-id we're interested in ? I'm sorry but that is just a non-sense solution, which reminds me of the good old days of random poking io-ports to probe stuff. We're not blindly going to read every /sys/devices/pnp0/00:xx/id attribute on a system, assuming that if it contains a pnp-id we're interested in it happens to belong to the input device we're enumerating at that time. Are we even certain that they will be consistent in use of these special PNP ID's? Maybe you should really do DMI match... They are more consistent with PNP ids then with their DMI strings, that is if they re-use the exact same touchpad the PNP id stays the same. So PNP ids give us a better chance of things just working without the user needing to wait for a distro update which has the new DMI strings in there. And yes so far the PNP ids use we want to-do is Lenovo only, as we've just discovered that they are actually storing some useful info in there. If we need quirks for other vendor laptops in the future, chances are we may want to do pnp-id matching there too. I've deliberately tried to write this patch-set so that it adds a generic way to export extra info the platform specific code may have. I could have added a pnp-id pointer to the serio struct, but I deliberately went with a free-form string so as to make this as generic as possible. As Matthew has already said we may want to also export extra info from devicetree through this mechanism for example. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on X240 / T440 / T540
The T440s user guide says that when Fn-lock is not active, the *40s' F9 - F12 keys should be mapped to: control-panel, search, show-all-windows and Computer. These keys generate the sofar unused 28 - 31 hotkey scancodes. For the first 2 this nicely matches the icons on the keys, for the latter 2 the icons are somewhat creative, which is why I ended up looking them up in the user manual. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/thinkpad_acpi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index defb6af..8789a26 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -3167,8 +3167,10 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) KEY_MICMUTE,/* 0x1a: Mic mute (since ?400 or so) */ /* (assignments unknown, please report if found) */ - KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, + + /* Extra keys in use since the X240 / T440 / T540 */ + KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_COMPUTER, }, }; -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/1] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on X240 / T440 / T540
Hi, This patch seems to have fallen through the cracks, so here is a resend. While at it I've also updated the comment / commit msg to reflect that these new keys can not just be found on the T440 but also on the X240 and T540, hence the v2. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] input/serio/8042: Add firmware_id support
Fill in the new serio firmware_id sysfs attribute for pnp instantiated
8042 serio ports.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Peter Hutterer peter.hutte...@who-t.net
---
drivers/input/serio/i8042-x86ia64io.h | 16
drivers/input/serio/i8042.c | 6 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 0ec9abb..2416c74 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -702,6 +702,18 @@ static int i8042_pnp_aux_irq;
static char i8042_pnp_kbd_name[32];
static char i8042_pnp_aux_name[32];
+static void i8042_pnp_id_to_string(struct pnp_id *id, char *dst, int dst_size)
+{
+ if (!id)
+ return;
+
+ strlcpy(dst, id-id, dst_size);
+ for (id = id-next; id; id = id-next) {
+ strlcat(dst, , dst_size);
+ strlcat(dst, id-id, dst_size);
+ }
+}
+
static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id
*did)
{
if (pnp_port_valid(dev, 0) pnp_port_len(dev, 0) == 1)
@@ -718,6 +730,8 @@ static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const
struct pnp_device_id *
strlcat(i8042_pnp_kbd_name, :, sizeof(i8042_pnp_kbd_name));
strlcat(i8042_pnp_kbd_name, pnp_dev_name(dev),
sizeof(i8042_pnp_kbd_name));
}
+ i8042_pnp_id_to_string(dev-id, i8042_kbd_firmware_id,
+ sizeof(i8042_kbd_firmware_id));
/* Keyboard ports are always supposed to be wakeup-enabled */
device_set_wakeup_enable(dev-dev, true);
@@ -742,6 +756,8 @@ static int i8042_pnp_aux_probe(struct pnp_dev *dev, const
struct pnp_device_id *
strlcat(i8042_pnp_aux_name, :, sizeof(i8042_pnp_aux_name));
strlcat(i8042_pnp_aux_name, pnp_dev_name(dev),
sizeof(i8042_pnp_aux_name));
}
+ i8042_pnp_id_to_string(dev-id, i8042_aux_firmware_id,
+ sizeof(i8042_aux_firmware_id));
i8042_pnp_aux_devices++;
return 0;
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 020053f..3807c3e 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -87,6 +87,8 @@ MODULE_PARM_DESC(debug, Turn i8042 debugging mode on and
off);
#endif
static bool i8042_bypass_aux_irq_test;
+static char i8042_kbd_firmware_id[128];
+static char i8042_aux_firmware_id[128];
#include i8042.h
@@ -1218,6 +1220,8 @@ static int __init i8042_create_kbd_port(void)
serio-dev.parent = i8042_platform_device-dev;
strlcpy(serio-name, i8042 KBD port, sizeof(serio-name));
strlcpy(serio-phys, I8042_KBD_PHYS_DESC, sizeof(serio-phys));
+ strlcpy(serio-firmware_id, i8042_kbd_firmware_id,
+ sizeof(serio-firmware_id));
port-serio = serio;
port-irq = I8042_KBD_IRQ;
@@ -1244,6 +1248,8 @@ static int __init i8042_create_aux_port(int idx)
if (idx 0) {
strlcpy(serio-name, i8042 AUX port, sizeof(serio-name));
strlcpy(serio-phys, I8042_AUX_PHYS_DESC, sizeof(serio-phys));
+ strlcpy(serio-firmware_id, i8042_aux_firmware_id,
+ sizeof(serio-firmware_id));
serio-close = i8042_port_close;
} else {
snprintf(serio-name, sizeof(serio-name), i8042 AUX%d port,
idx);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] input/serio: Add a firmware_id sysfs attribute
Hi All, Sorry about doing a v2 so shortly after the resend, while reviewing the patches one last time I noticed that the code in the input/serio/8042: Add firmware_id support Suffered a bit from too much copy-paste, so in this v2 that patch has been refactored using a helper function to avoid code duplication. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] input/serio: Add a firmware_id sysfs attribute
serio devices exposed via platform firmware interfaces such as ACPI
may provide additional identifying information of use to userspace.
We don't associate the serio devices with the firmware device (we don't
set it as parent), so there's no way for userspace to make use of this
information.
We cannot change the parent for serio devices instantiated though a firmware
interface as that would break suspend / resume ordering.
Therefor this patch adds a new firmware_id sysfs attribute so that userspace
can get a string from there with any additional identifying information the
firmware interface may provide.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Peter Hutterer peter.hutte...@who-t.net
---
drivers/input/serio/serio.c | 12
include/linux/serio.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 8f4c4ab..1788a4d 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -451,6 +451,13 @@ static ssize_t serio_set_bind_mode(struct device *dev,
struct device_attribute *
return retval;
}
+static ssize_t firmware_id_show(struct device *dev, struct device_attribute
*attr, char *buf)
+{
+ struct serio *serio = to_serio_port(dev);
+
+ return sprintf(buf, %s\n, serio-firmware_id);
+}
+
static DEVICE_ATTR_RO(type);
static DEVICE_ATTR_RO(proto);
static DEVICE_ATTR_RO(id);
@@ -473,12 +480,14 @@ static DEVICE_ATTR_RO(modalias);
static DEVICE_ATTR_WO(drvctl);
static DEVICE_ATTR(description, S_IRUGO, serio_show_description, NULL);
static DEVICE_ATTR(bind_mode, S_IWUSR | S_IRUGO, serio_show_bind_mode,
serio_set_bind_mode);
+static DEVICE_ATTR_RO(firmware_id);
static struct attribute *serio_device_attrs[] = {
dev_attr_modalias.attr,
dev_attr_description.attr,
dev_attr_drvctl.attr,
dev_attr_bind_mode.attr,
+ dev_attr_firmware_id.attr,
NULL
};
@@ -923,6 +932,9 @@ static int serio_uevent(struct device *dev, struct
kobj_uevent_env *env)
SERIO_ADD_UEVENT_VAR(SERIO_EXTRA=%02x, serio-id.extra);
SERIO_ADD_UEVENT_VAR(MODALIAS=serio:ty%02Xpr%02Xid%02Xex%02X,
serio-id.type, serio-id.proto, serio-id.id,
serio-id.extra);
+ if (serio-firmware_id[0])
+ SERIO_ADD_UEVENT_VAR(SERIO_FIRMWARE_ID=%s,
+serio-firmware_id);
return 0;
}
diff --git a/include/linux/serio.h b/include/linux/serio.h
index 36aac73..9f779c7 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -23,6 +23,7 @@ struct serio {
char name[32];
char phys[32];
+ char firmware_id[128];
bool manual_bind;
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/1] thinkpad_acpi: Add mappings for F9 - F12 hotkeys on X240 / T440 / T540
Hi, On 04/10/2014 02:12 AM, Henrique de Moraes Holschuh wrote: On Wed, 09 Apr 2014, Matthew Garrett wrote: On Wed, Apr 09, 2014 at 03:03:01PM -0300, Henrique de Moraes Holschuh wrote: On Wed, 09 Apr 2014, Hans de Goede wrote: This patch seems to have fallen through the cracks, so here is a resend. Sort of. There was a doubt about one of the keycodes. I think I'm ok with the keycode. Ok. Now, provided that it doesn't clash with the other thinkpads (in which case we'd just add selective keymaps), we can merge. It does not clash with the new Carbon X1 2nd generation stuff, see: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=8f5f86abc6593b6d600712435e2f24a7a098b951 Basically the new stuff uses hotkey codes = TPACPI_HOTKEY_MAP_LEN, where as my patch adds mappings for codes TPACPI_HOTKEY_MAP_LEN. (Where TPACPI_HOTKEY_MAP_LEN == 32) Heck, we can fix that later too, it doesn't count as an ABI break, these keymaps are _already_ configurable from userspace _and_ usually reconfigured by userspace, the driver just tries to provide sane defaults. So... Acked-by: Henrique de Moraes Holschuh h...@hmh.eng.br Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] mba6x_bl: Backlight driver for mid 2013 MacBook Air
Hi,
Why is this patch an RFC? If it is ready for upstreaming please drop
the RFC prefix when you post the next version.
On 04/27/2014 10:56 PM, Patrik Jakobsson wrote:
This driver takes control over the LP8550 backlight driver chip found
in the mid 2013 and newer MacBook Air (6,1 and 6,2). The i915 GPU driver
cannot properly restore the backlight after resume, but with this driver
we can hijack the LP8550 and get fully functional backlight support.
Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig| 13 ++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/mba6x_bl.c | 351
4 files changed, 371 insertions(+)
create mode 100644 drivers/platform/x86/mba6x_bl.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..cad3e82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5576,6 +5576,12 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S: Maintained
F: net/mac80211/rc80211_pid*
+MACBOOK AIR 6,X BACKLIGHT DRIVER
+M: Patrik Jakobsson patrik.r.jakobs...@gmail.com
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/mba6x_bl.c
+
MACVLAN DRIVER
M: Patrick McHardy ka...@trash.net
L: net...@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 27df2c5..1308924 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -795,6 +795,19 @@ config APPLE_GMUX
graphics as well as the backlight. Currently only backlight
control is supported by the driver.
+config MBA6X_BL
+ tristate MacBook Air 6,x backlight driver
+ depends on ACPI
+ depends on BACKLIGHT_CLASS_DEVICE
+select ACPI_VIDEO if ACPI
You can drop the if ACPI here, as you already DEPEND on it above
+ help
+ This driver takes control over the LP8550 backlight driver found in
+ some MacBook Air models. Say Y here if you have a MacBook Air from mid
+ 2013 or newer.
+
+ To compile this driver as a module, choose M here: the module will
+ be called mba6x_bl.
+
config INTEL_RST
tristate Intel Rapid Start Technology Driver
depends on ACPI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 1a2eafc..9a182fe 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_INTEL_SMARTCONNECT)+= intel-smartconnect.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_ALIENWARE_WMI) += alienware-wmi.o
+obj-$(CONFIG_MBA6X_BL) += mba6x_bl.o
diff --git a/drivers/platform/x86/mba6x_bl.c b/drivers/platform/x86/mba6x_bl.c
new file mode 100644
index 000..022bc8d
--- /dev/null
+++ b/drivers/platform/x86/mba6x_bl.c
@@ -0,0 +1,351 @@
+/*
+ * MacBook Air 6,1 and 6,2 (mid 2013) backlight driver
+ *
+ * Copyright (C) 2014 Patrik Jakobsson (patrik.r.jakobs...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/backlight.h
+#include linux/acpi.h
+#include acpi/acpi.h
+#include acpi/video.h
+
+#define LP8550_SMBUS_ADDR(0x58 1)
+#define LP8550_REG_BRIGHTNESS0
+#define LP8550_REG_DEV_CTL 1
+#define LP8550_REG_FAULT 2
+#define LP8550_REG_IDENT 3
+#define LP8550_REG_DIRECT_CTL4
+#define LP8550_REG_TEMP_MSB 5 /* Must be read before TEMP_LSB */
+#define LP8550_REG_TEMP_LSB 6
+
+#define INIT_BRIGHTNESS 150
+
+static struct {
+ u8 brightness; /* Brightness control */
+ u8 dev_ctl; /* Device control */
+ u8 fault; /* Fault indication */
+ u8 ident; /* Identification */
+ u8 direct_ctl; /* Direct control */
+ u8 temp_msb;/* Temperature MSB */
+ u8 temp_lsb;/* Temperature LSB */
+} lp8550_regs;
+
+static struct platform_device *platform_device;
+static struct backlight_device *backlight_device;
+
+static int lp8550_reg_read(u8 reg, u8 *val)
+{
+ acpi_status status;
+ acpi_handle handle;
+ struct acpi_object_list arg_list;
+ struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+ union acpi_object
Re: [PATCH v2] mba6x_bl: Backlight driver for mid 2013 MacBook Air
Hi,
On 04/29/2014 04:21 PM, Patrik Jakobsson wrote:
This driver takes control over the LP8550 backlight driver chip found
in the mid 2013 and newer MacBook Air (6,1 and 6,2). The i915 GPU driver
cannot properly restore the backlight after resume, but with this driver
we can hijack the LP8550 and get fully functional backlight support.
v2: - Dropped if ACPI in Kconfig since we already depend on it
- Added comment about brightness mapping
- Removed lp8550_init() from set_brightness()
- Always write to dev_ctl when setting brightness
- Change %Ld to standard C %lld
- Constify the backlight_ops struct
Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
Thanks for working on this, looks good:
Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig| 13 ++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/mba6x_bl.c | 353
4 files changed, 373 insertions(+)
create mode 100644 drivers/platform/x86/mba6x_bl.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..cad3e82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5576,6 +5576,12 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
S: Maintained
F: net/mac80211/rc80211_pid*
+MACBOOK AIR 6,X BACKLIGHT DRIVER
+M: Patrik Jakobsson patrik.r.jakobs...@gmail.com
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/mba6x_bl.c
+
MACVLAN DRIVER
M: Patrick McHardy ka...@trash.net
L: net...@vger.kernel.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 27df2c5..10ac918 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -795,6 +795,19 @@ config APPLE_GMUX
graphics as well as the backlight. Currently only backlight
control is supported by the driver.
+config MBA6X_BL
+ tristate MacBook Air 6,x backlight driver
+ depends on ACPI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select ACPI_VIDEO
+ help
+ This driver takes control over the LP8550 backlight driver found in
+ some MacBook Air models. Say Y here if you have a MacBook Air from mid
+ 2013 or newer.
+
+ To compile this driver as a module, choose M here: the module will
+ be called mba6x_bl.
+
config INTEL_RST
tristate Intel Rapid Start Technology Driver
depends on ACPI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 1a2eafc..9a182fe 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_INTEL_SMARTCONNECT)+= intel-smartconnect.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_ALIENWARE_WMI) += alienware-wmi.o
+obj-$(CONFIG_MBA6X_BL) += mba6x_bl.o
diff --git a/drivers/platform/x86/mba6x_bl.c b/drivers/platform/x86/mba6x_bl.c
new file mode 100644
index 000..c549667
--- /dev/null
+++ b/drivers/platform/x86/mba6x_bl.c
@@ -0,0 +1,353 @@
+/*
+ * MacBook Air 6,1 and 6,2 (mid 2013) backlight driver
+ *
+ * Copyright (C) 2014 Patrik Jakobsson (patrik.r.jakobs...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/backlight.h
+#include linux/acpi.h
+#include acpi/acpi.h
+#include acpi/video.h
+
+#define LP8550_SMBUS_ADDR(0x58 1)
+#define LP8550_REG_BRIGHTNESS0
+#define LP8550_REG_DEV_CTL 1
+#define LP8550_REG_FAULT 2
+#define LP8550_REG_IDENT 3
+#define LP8550_REG_DIRECT_CTL4
+#define LP8550_REG_TEMP_MSB 5 /* Must be read before TEMP_LSB */
+#define LP8550_REG_TEMP_LSB 6
+
+#define INIT_BRIGHTNESS 150
+
+static struct {
+ u8 brightness; /* Brightness control */
+ u8 dev_ctl; /* Device control */
+ u8 fault; /* Fault indication */
+ u8 ident; /* Identification */
+ u8 direct_ctl; /* Direct control */
+ u8 temp_msb;/* Temperature MSB */
+ u8 temp_lsb;/* Temperature LSB */
+} lp8550_regs;
+
+static struct platform_device *platform_device;
+static struct backlight_device *backlight_device;
+
+static int lp8550_reg_read(u8 reg, u8 *val)
+{
+ acpi_status status;
+ acpi_handle handle;
+ struct acpi_object_list arg_list;
+ struct acpi_buffer buffer
[RFC 0/3] Add acpi_video_unregister_backlight and use it in acer-wmi
Hi Aaron and Lee, While working on figuring out howto fix this Acer backlight bug properly: https://bugzilla.redhat.com/show_bug.cgi?id=1012674 TL;DR: needs acpi-video to not register the backlight device, but keep it processing hotkeys, like video.use_native_backlight=1 does, but this machine does not have a win8 ready BIOS. This eventually lead me to https://bugzilla.kernel.org/show_bug.cgi?id=35622 and the whole discussion between you there, as well as to the patches attached there. I believe that Lee's patches there to add a function to acpi-video to only unregister the backlight device are the correct way forward. I've explained why in the commit messages. Note that for the fix for bko35622 I've actually opted for a bigger hammer, by simply always calling acpi_video_unregister_backlight instead of acpi_video_unregister. Again rationale is in the commit message, it boils down to acpi_video_unregister_backlight() leading to consistent behavior, where as acpi_video_unregister() leads to different behavior depending on module load ordering. So even if this causes issues somewhere (which would be 2 keypresses reported for each press, which is not too bad), it still is better, because it at least will give us consistent wrong or wright behavior and we can then fix the double key presses from a stable base. One could go as far as to say that acpi_video_unregister() should simply go away completely. The 3th patch fixes the bug I started with by simply adding a dmi table entry for the model in the rhbz1012674 This series is RFC for now because some of these changes may be somewhat controversial, but if you agree with the proposed changes, then I would like your acks and then get this merged. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table
The Aspire 5741 has broken acpi-video backlight control, so add it to the
quirk table.
https://bugzilla.redhat.com/show_bug.cgi?id=1012674
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 3a74699..bbf78b2 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -570,6 +570,14 @@ static const struct dmi_system_id video_vendor_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5750),
},
},
+ {
+ .callback = video_set_backlight_video_vendor,
+ .ident = Acer Aspire 5741,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Acer),
+ DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5741),
+ },
+ },
{}
};
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/3] acer-wmi: Switch to acpi_video_unregister_backlight
Switch from acpi_video_unregister(), to acpi_video_unregister_backlight(),
so that the hotkeys handler registered by acpi-video stays in place.
Since there are no mappings for the atkbd raw codes for the brightness
keys used by newer Acer models in /lib/udev/hwdb.d/60-keyboard.hwdb, and
since we map the wmi events with a code of KE_IGNORE, we rely on acpi-video
to do the hotkey handling for us.
For laptops such as the Acer Aspire 5750 which uses intel gfx this works
despite us calling acpi_video_unregister() because the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi and i915)
2) acpi-video does NOT call acpi_video_register()
3) acer-wmi loads (assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
But on the Acer Aspire 5750G, which uses nvidia graphics the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acer-wmi loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
And we end up without any handler for the brightness hotkeys. This patch fixes
this by switching over to acpi_video_unregister_backlight() which keeps the
hotkey handler in place.
https://bugzilla.kernel.org/show_bug.cgi?id=35622
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c91f69b3..3a74699 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -2228,7 +2228,7 @@ static int __init acer_wmi_init(void)
pr_info(Brightness must be controlled by acpi video driver\n);
} else {
pr_info(Disabling ACPI video driver\n);
- acpi_video_unregister();
+ acpi_video_unregister_backlight();
}
if (wmi_has_guid(WMID_GUID3)) {
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/3] acpi-video: Add an acpi_video_unregister_backlight function
Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor();
acpi_video_unregister();
The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx:
1) acpi-video module gets loaded (as it is a dependency of acpi_vendor and i915)
2) acpi-video does NOT call acpi_video_register()
3) acpi_vendor loads (lets assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx
1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), which calling acpi_video_unregister_backlight()
instead of acpi_video_unregister() will give them.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c | 31 ++-
include/acpi/video.h | 2 ++
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 6a2099d..80a6759 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1843,7 +1843,7 @@ static void acpi_video_dev_register_backlight(struct
acpi_video_device *device)
}
}
-static int acpi_video_bus_register_backlight(struct acpi_video_bus *video)
+static void acpi_video_bus_register_backlight(struct acpi_video_bus *video)
{
struct acpi_video_device *dev;
@@ -1851,10 +1851,6 @@ static int acpi_video_bus_register_backlight(struct
acpi_video_bus *video)
list_for_each_entry(dev, video-video_device_list, entry)
acpi_video_dev_register_backlight(dev);
mutex_unlock(video-device_list_lock);
-
- video-pm_nb.notifier_call = acpi_video_resume;
- video-pm_nb.priority = 0;
- return register_pm_notifier(video-pm_nb);
}
static void acpi_video_dev_unregister_backlight(struct acpi_video_device
*device)
@@ -1876,17 +1872,14 @@ static void acpi_video_dev_unregister_backlight(struct
acpi_video_device *device
}
}
-static int acpi_video_bus_unregister_backlight(struct acpi_video_bus *video)
+static void acpi_video_bus_unregister_backlight(struct acpi_video_bus *video)
{
struct acpi_video_device *dev;
- int error = unregister_pm_notifier(video-pm_nb);
mutex_lock(video-device_list_lock);
list_for_each_entry(dev, video-video_device_list, entry)
acpi_video_dev_unregister_backlight(dev);
mutex_unlock(video-device_list_lock);
-
- return error;
}
static void acpi_video_dev_add_notify_handler(struct acpi_video_device *device)
@@ -2059,6 +2052,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
mutex_unlock(video_list_lock);
acpi_video_bus_register_backlight(video);
+
+ video-pm_nb.notifier_call = acpi_video_resume;
+ video-pm_nb.priority = 0;
+ register_pm_notifier(video-pm_nb);
+
acpi_video_bus_add_notify_handler(video);
return 0;
@@ -2084,6 +2082,7 @@ static int acpi_video_bus_remove(struct acpi_device
*device)
video = acpi_driver_data(device);
acpi_video_bus_remove_notify_handler(video);
+ unregister_pm_notifier(video-pm_nb);
acpi_video_bus_unregister_backlight(video);
acpi_video_bus_put_devices(video);
@@ -2173,6 +2172,20 @@ void acpi_video_unregister(void)
}
EXPORT_SYMBOL
[PATCH] ideapad-laptop: Blacklist rfkill control on the Lenovo Yoga 2 11
The Lenovo Yoga 2 11 always reports everything as blocked, causing userspace
to not even try to use the wlan / bluetooth even though they work fine.
Note this patch also removes the else priv-rfk[i] = NULL; bit of the
rfkill initialization, it is not necessary as the priv struct is allocated
with kzalloc.
Reported-and-tested-by: Vincent Gerris vger...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/ideapad-laptop.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 6dd060a..219eb28 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -36,6 +36,7 @@
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/i8042.h
+#include linux/dmi.h
#define IDEAPAD_RFKILL_DEV_NUM (3)
@@ -819,6 +820,19 @@ static void ideapad_acpi_notify(acpi_handle handle, u32
event, void *data)
}
}
+/* Blacklist for devices where the ideapad rfkill interface does not work */
+static struct dmi_system_id rfkill_blacklist[] = {
+ /* The Lenovo Yoga 2 11 always reports everything as blocked */
+ {
+ .ident = Lenovo Yoga 2 11,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, LENOVO),
+ DMI_MATCH(DMI_PRODUCT_VERSION, Lenovo Yoga 2 11),
+ },
+ },
+ {}
+};
+
static int ideapad_acpi_add(struct platform_device *pdev)
{
int ret, i;
@@ -854,11 +868,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (ret)
goto input_failed;
- for (i = 0; i IDEAPAD_RFKILL_DEV_NUM; i++) {
- if (test_bit(ideapad_rfk_data[i].cfgbit, priv-cfg))
- ideapad_register_rfkill(priv, i);
- else
- priv-rfk[i] = NULL;
+ if (!dmi_check_system(rfkill_blacklist)) {
+ for (i = 0; i IDEAPAD_RFKILL_DEV_NUM; i++)
+ if (test_bit(ideapad_rfk_data[i].cfgbit, priv-cfg))
+ ideapad_register_rfkill(priv, i);
}
ideapad_sync_rfk_state(priv);
ideapad_sync_touchpad_state(priv);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] acpi-video: Add an acpi_video_unregister_backlight function
Hi,
On 05/13/2014 05:11 PM, Aaron Lu wrote:
On 05/13/2014 02:03 AM, Hans de Goede wrote:
Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently
acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor();
acpi_video_unregister();
The intention here is to make things independent of when
acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx:
1) acpi-video module gets loaded (as it is a dependency of acpi_vendor and
i915)
2) acpi-video does NOT call acpi_video_register()
3) acpi_vendor loads (lets assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx
1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), which calling
acpi_video_unregister_backlight()
instead of acpi_video_unregister() will give them.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c | 31 ++-
include/acpi/video.h | 2 ++
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 6a2099d..80a6759 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1843,7 +1843,7 @@ static void acpi_video_dev_register_backlight(struct
acpi_video_device *device)
}
}
-static int acpi_video_bus_register_backlight(struct acpi_video_bus *video)
+static void acpi_video_bus_register_backlight(struct acpi_video_bus *video)
{
struct acpi_video_device *dev;
@@ -1851,10 +1851,6 @@ static int acpi_video_bus_register_backlight(struct
acpi_video_bus *video)
list_for_each_entry(dev, video-video_device_list, entry)
acpi_video_dev_register_backlight(dev);
mutex_unlock(video-device_list_lock);
-
-video-pm_nb.notifier_call = acpi_video_resume;
-video-pm_nb.priority = 0;
-return register_pm_notifier(video-pm_nb);
Hmm, I don't understand this. The pm notifier is used to restore
backlight level on system resume, so should be there when we have
created the backlight interface and gone when we unregistered the
backlight interface. It doesn't have anything to do with hotkey
processing.
A valid point, I did things this way because I wanted the new
acpi_video_unregister_backlight to result in the same behavior as
having set the acpi_video=vendor / called acpi_video_dmi_promote_vendor()
before acpi_video_register runs.
So this means undoing what-ever acpi_video_register() does, which it
would not have done if acpi_video_dmi_promote_vendor() came first.
If you look at the current code (so without this patch) then
the pm notifier gets installed unconditionally by
acpi_video_bus_register_backlight() which gets called unconditionally
by acpi_video_bus_add(). So even with acpi_video=vendor it still gets
installed.
acpi_video=vendor / acpi_video_dmi_promote_vendor() influences
acpi_video_backlight_support() which only gets called by
acpi_video_verify_backlight_support() which only gets called by
acpi_video_dev_register_backlight(). So acpi_video=vendor only causes
the backlight devices to not register, the pm notifier will still be
installed. My intend was to behave the same independent of module
loading / init order hence I moved the pm notifier install / uninstall
to keep the pm notifier installed when calling the new
RFC: Cleanup firmware backlight control method selection
Hi All, There are various issues with how the linux kernel currently select which firmware backlight control (*) method to use: 1) There are various module loading ordering issues, leading to different behavior depending on module load ordering: * http://www.spinics.net/lists/linux-acpi/msg50443.html * Sometimes we register and immediately unregister the acpi_video# backlight devices, some ACPI implementations don't like this, so we've special quirks to avoid the register + unregister on some machines 2) There are 2 main kernel commandline options involved acpi_backlight and video.use_native_backlight. With the latter only working if certain firmware checks succeed *and* the former has the right value. This is confusing not only for end users but also for people trying to read the code in question. Note some vendor specific firmware backlight drivers, ie thinkpad_acpi.c have their own related options, leading to 3 kernel cmdline options coming into play. 3) We have quirks everywhere. I'm afraid we cannot get rid of these, but at least we should try to clean up where they live and how they interact with each other. acpi_backlight=vendor quirks mostly live in vendor specific firmware backlight drivers. But we also have a couple in acpi/video_detect.c. video.use_native_backlight=1 quirks otoh live in acpi/video.c. In the end all these options and quirks all work together in a complicated manor to achieve one simple goal: decide which firmware interface to use for backlight control (*). Which comes down to choosing between the following 3 options: 1 Native (raw) backlight control (so no firmware backlight control) 2 Control by the standard acpi-video firmware backlight driver 3 Control by a vendor specific firmware backlight driver So I would like to propose to give the acpi_backlight= kernel commandline option which currently accepts values vendor and video a third value native, and to get rid of the video.use_native_backlight option. This would be combined with a major cleanup of the existing code for firmware backlight control method selection: 1) Replace the ACPI_VIDEO_BACKLIGHT_* flags with an enum listing the 3 options 2) Replace the acpi_video_support variable with acpi_backlight_method_cmdline and acpi_backlight_method_dmi variables, both initialzed to -1 3) Add an acpi_backlight_method() function which will: - return acpi_backlight_method_cmdline if not -1; else - return acpi_backlight_method_dmi if not -1; else - return ACPI_BACKLIGHT_NATIVE if acpi_osi_is_win8(); else - return ACPI_BACKLIGHT_VIDEO if supported; else - return ACPI_BACKLIGHT_VENDOR 4) Have all drivers that use acpi_video_dmi_promote_vendor move their quirks for this to acpi/video_detect.c, removing the need for them to call acpi_video_dmi_promote_vendor() and acpi_video_unregister(), removing the load ordering issues and removing them depending on video.ko 5) Switch all drivers from acpi_video_backlight_support() to acpi_backlight_method() The plan would be to do 1-3 in a single patch and ASAP and then do 4 and 5 driver by driver, and once done remove acpi_video_dmi_promote_vendor() and acpi_video_backlight_support(), and mark acpi_video_register / acpi_video_unregister as only for i915 use. Regards, Hans *) Note I'm only talking about controlling the actual brightness of the backlight, not detecting brighness/backlight hotkey presses, there are similar issues there. But I believe that that should be treated as an orthogonal problem which should be fixed independently of this. -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] asus-wmi: Add a no backlight quirk
Some Asus motherboards for desktop PC-s export an acpi-video and
an asus-wmi interface advertising backlight support. Add a quirk to allow
to blacklist these so that desktop environments such as gnome don't start
showing nonsense brightness controls.
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-wmi.c | 8 ++--
drivers/platform/x86/asus-wmi.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index c5e082f..6f73dc5 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1272,6 +1272,9 @@ static int asus_wmi_backlight_init(struct asus_wmi *asus)
int max;
int power;
+ if (asus-driver-quirks-no_backlight)
+ return -ENODEV;
+
max = read_brightness_max(asus);
if (max == -ENODEV)
@@ -1370,7 +1373,7 @@ static void asus_wmi_notify(u32 value, void *context)
code = ASUS_WMI_BRN_DOWN;
if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
- if (!acpi_video_backlight_support()) {
+ if (asus-backlight_device) {
asus_wmi_backlight_notify(asus, orig_code);
goto exit;
}
@@ -1773,7 +1776,8 @@ static int asus_wmi_add(struct platform_device *pdev)
if (err)
goto fail_rfkill;
- if (asus-driver-quirks-wmi_backlight_power)
+ if (asus-driver-quirks-wmi_backlight_power ||
+ asus-driver-quirks-no_backlight)
acpi_video_dmi_promote_vendor();
if (!acpi_video_backlight_support()) {
pr_info(Disabling ACPI video driver\n);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 4da4c8b..cc47efe 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -42,6 +42,7 @@ struct quirk_entry {
bool scalar_panel_brightness;
bool store_backlight_power;
bool wmi_backlight_power;
+ bool no_backlight;
int wapf;
/*
* For machines with AMD graphic chips, it will send out WMI event
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS Motherboard
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/eeepc-wmi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 6112933..a7286bb 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -114,6 +114,10 @@ static struct quirk_entry quirk_asus_x101ch = {
.wmi_backlight_power = true,
};
+static struct quirk_entry quirk_asus_no_backlight = {
+ .no_backlight = true,
+};
+
static struct quirk_entry *quirks;
static void et2012_quirks(void)
@@ -182,6 +186,15 @@ static struct dmi_system_id asus_quirks[] = {
},
.driver_data = quirk_asus_x101ch,
},
+ {
+ .callback = dmi_matched,
+ .ident = ASUSTeK Computer INC. H87I-PLUS,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, ASUSTeK COMPUTER INC.),
+ DMI_MATCH(DMI_BOARD_NAME, H87I-PLUS),
+ },
+ .driver_data = quirk_asus_no_backlight,
+ },
{},
};
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Add acpi_video_unregister_backlight(), use in acer-wmi
Hi All, Here is a non RFC version of my patch series to fix: https://bugzilla.kernel.org/show_bug.cgi?id=35622 https://bugzilla.redhat.com/show_bug.cgi?id=1012674 I think its best if the entire series goes upstream through the acpi tree since the platform/x86 patches depend on the acpi changes. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] acpi-video: Don't register acpi_video_resume notifier without backlight devices
If we're not going to be registering any backlight devices then
acpi_video_resume is always nop, so don't register it in that case.
Signed-off-by: Hans de Goede hdego...@redhat.com
--
Note to reviewers the changes to acpi_video_dev_register_backlight() only
remove the if (!acpi_video_verify_backlight_support()) { which surrounded
the entire body of the function, as that is checked earlier now.
---
drivers/acpi/video.c | 139 +++
1 file changed, 74 insertions(+), 65 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 6a2099d..f767eba 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -150,6 +150,7 @@ struct acpi_video_enumerated_device {
struct acpi_video_bus {
struct acpi_device *device;
+ bool backlight_registered;
u8 dos_setting;
struct acpi_video_enumerated_device *attached_array;
u8 attached_count;
@@ -1770,88 +1771,89 @@ acpi_video_bus_match(acpi_handle handle, u32 level,
void *context,
static void acpi_video_dev_register_backlight(struct acpi_video_device *device)
{
- if (acpi_video_verify_backlight_support()) {
- struct backlight_properties props;
- struct pci_dev *pdev;
- acpi_handle acpi_parent;
- struct device *parent = NULL;
- int result;
- static int count;
- char *name;
-
- result = acpi_video_init_brightness(device);
- if (result)
- return;
- name = kasprintf(GFP_KERNEL, acpi_video%d, count);
- if (!name)
- return;
- count++;
+ struct backlight_properties props;
+ struct pci_dev *pdev;
+ acpi_handle acpi_parent;
+ struct device *parent = NULL;
+ int result;
+ static int count;
+ char *name;
- acpi_get_parent(device-dev-handle, acpi_parent);
+ result = acpi_video_init_brightness(device);
+ if (result)
+ return;
+ name = kasprintf(GFP_KERNEL, acpi_video%d, count);
+ if (!name)
+ return;
+ count++;
- pdev = acpi_get_pci_dev(acpi_parent);
- if (pdev) {
- parent = pdev-dev;
- pci_dev_put(pdev);
- }
+ acpi_get_parent(device-dev-handle, acpi_parent);
- memset(props, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_FIRMWARE;
- props.max_brightness = device-brightness-count - 3;
- device-backlight = backlight_device_register(name,
- parent,
- device,
-
acpi_backlight_ops,
- props);
- kfree(name);
- if (IS_ERR(device-backlight))
- return;
+ pdev = acpi_get_pci_dev(acpi_parent);
+ if (pdev) {
+ parent = pdev-dev;
+ pci_dev_put(pdev);
+ }
- /*
-* Save current brightness level in case we have to restore it
-* before acpi_video_device_lcd_set_level() is called next time.
-*/
- device-backlight-props.brightness =
- acpi_video_get_brightness(device-backlight);
+ memset(props, 0, sizeof(struct backlight_properties));
+ props.type = BACKLIGHT_FIRMWARE;
+ props.max_brightness = device-brightness-count - 3;
+ device-backlight = backlight_device_register(name,
+ parent,
+ device,
+ acpi_backlight_ops,
+ props);
+ kfree(name);
+ if (IS_ERR(device-backlight))
+ return;
- device-cooling_dev = thermal_cooling_device_register(LCD,
- device-dev, video_cooling_ops);
- if (IS_ERR(device-cooling_dev)) {
- /*
-* Set cooling_dev to NULL so we don't crash trying to
-* free it.
-* Also, why the hell we are returning early and
-* not attempt to register video output if cooling
-* device registration failed?
-* -- dtor
-*/
- device-cooling_dev = NULL;
- return;
- }
+ /*
+* Save current brightness level in case we have to restore it
+* before acpi_video_device_lcd_set_level
[PATCH 2/4] acpi-video: Add an acpi_video_unregister_backlight function
Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor();
acpi_video_unregister();
The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx:
1) acpi-video module gets loaded (as it is a dependency of acpi_vendor and i915)
2) acpi-video does NOT call acpi_video_register()
3) acpi_vendor loads (lets assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx
1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c | 14 ++
include/acpi/video.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index f767eba..898b084 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -2182,6 +2182,20 @@ void acpi_video_unregister(void)
}
EXPORT_SYMBOL(acpi_video_unregister);
+void acpi_video_unregister_backlight(void)
+{
+ struct acpi_video_bus *video;
+
+ if (!register_count)
+ return;
+
+ mutex_lock(video_list_lock);
+ list_for_each_entry(video, video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(video_list_lock);
+}
+EXPORT_SYMBOL(acpi_video_unregister_backlight);
+
/*
* This is kind of nasty. Hardware using Intel chipsets may require
* the video opregion code to be run first in order to initialise
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 61109f2..4722c06 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -19,11 +19,13 @@ struct acpi_device;
#if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
extern int acpi_video_register(void);
extern void acpi_video_unregister(void);
+extern void acpi_video_unregister_backlight(void);
extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
#else
static inline int acpi_video_register(void) { return 0; }
static inline void acpi_video_unregister(void) { return; }
+extern inline void acpi_video_unregister_backlight(void); { return; }
static inline int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid)
{
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table
The Aspire 5741 has broken acpi-video backlight control, so add it to the
quirk table.
https://bugzilla.redhat.com/show_bug.cgi?id=1012674
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 3a74699..bbf78b2 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -570,6 +570,14 @@ static const struct dmi_system_id video_vendor_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5750),
},
},
+ {
+ .callback = video_set_backlight_video_vendor,
+ .ident = Acer Aspire 5741,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Acer),
+ DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5741),
+ },
+ },
{}
};
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] acer-wmi: Switch to acpi_video_unregister_backlight
Switch from acpi_video_unregister(), to acpi_video_unregister_backlight(),
so that the hotkeys handler registered by acpi-video stays in place.
Since there are no mappings for the atkbd raw codes for the brightness
keys used by newer Acer models in /lib/udev/hwdb.d/60-keyboard.hwdb, and
since we map the wmi events with a code of KE_IGNORE, we rely on acpi-video
to do the hotkey handling for us.
For laptops such as the Acer Aspire 5750 which uses intel gfx this works
despite us calling acpi_video_unregister() because the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi and i915)
2) acpi-video does NOT call acpi_video_register()
3) acer-wmi loads (assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
But on the Acer Aspire 5750G, which uses nvidia graphics the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acer-wmi loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
And we end up without any handler for the brightness hotkeys. This patch fixes
this by switching over to acpi_video_unregister_backlight() which keeps the
hotkey handler in place.
https://bugzilla.kernel.org/show_bug.cgi?id=35622
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c91f69b3..3a74699 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -2228,7 +2228,7 @@ static int __init acer_wmi_init(void)
pr_info(Brightness must be controlled by acpi video driver\n);
} else {
pr_info(Disabling ACPI video driver\n);
- acpi_video_unregister();
+ acpi_video_unregister_backlight();
}
if (wmi_has_guid(WMID_GUID3)) {
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Cleanup firmware backlight control method selection
Hi, On 05/16/2014 12:29 AM, Mattia Dongili wrote: On Thu, May 15, 2014 at 11:04:50AM +0200, Hans de Goede wrote: Hi All, There are various issues with how the linux kernel currently select which firmware backlight control (*) method to use: 1) There are various module loading ordering issues, leading to different behavior depending on module load ordering: * http://www.spinics.net/lists/linux-acpi/msg50443.html * Sometimes we register and immediately unregister the acpi_video# backlight devices, some ACPI implementations don't like this, so we've special quirks to avoid the register + unregister on some machines 2) There are 2 main kernel commandline options involved acpi_backlight and video.use_native_backlight. With the latter only working if certain firmware checks succeed *and* the former has the right value. This is confusing not only for end users but also for people trying to read the code in question. Note some vendor specific firmware backlight drivers, ie thinkpad_acpi.c have their own related options, leading to 3 kernel cmdline options coming into play. 3) We have quirks everywhere. I'm afraid we cannot get rid of these, but at least we should try to clean up where they live and how they interact with each other. acpi_backlight=vendor quirks mostly live in vendor specific firmware backlight drivers. But we also have a couple in acpi/video_detect.c. video.use_native_backlight=1 quirks otoh live in acpi/video.c. In the end all these options and quirks all work together in a complicated manor to achieve one simple goal: decide which firmware interface to use for backlight control (*). Which comes down to choosing between the following 3 options: 1 Native (raw) backlight control (so no firmware backlight control) 2 Control by the standard acpi-video firmware backlight driver 3 Control by a vendor specific firmware backlight driver So I would like to propose to give the acpi_backlight= kernel commandline option which currently accepts values vendor and video a third value native, and to get rid of the video.use_native_backlight option. the acpi_ prefix here sounds inappropriate at this point. And descending from that, shouldn't a mechanism like you describe being implemented in the backlight subsystem? This is only a problem with crazy PC's which have multiple firmware API's (both standardized and custom ACPI) to control the backlight, which also are sometimes all broken. So this really is an acpi thing, and I believe this should stay in acpi/video_detect.c where it already lives, I just think the video.use_native_backlight option which clearly interacts with this needs to be moved to acpi/video_detect.c too. This would be combined with a major cleanup of the existing code for firmware backlight control method selection: 1) Replace the ACPI_VIDEO_BACKLIGHT_* flags with an enum listing the 3 options 2) Replace the acpi_video_support variable with acpi_backlight_method_cmdline and acpi_backlight_method_dmi variables, both initialzed to -1 3) Add an acpi_backlight_method() function which will: - return acpi_backlight_method_cmdline if not -1; else - return acpi_backlight_method_dmi if not -1; else - return ACPI_BACKLIGHT_NATIVE if acpi_osi_is_win8(); else - return ACPI_BACKLIGHT_VIDEO if supported; else - return ACPI_BACKLIGHT_VENDOR 4) Have all drivers that use acpi_video_dmi_promote_vendor move their quirks for this to acpi/video_detect.c, removing the need for them to call acpi_video_dmi_promote_vendor() and acpi_video_unregister(), removing the load ordering issues and removing them depending on video.ko I think the whole idea of promote/demote_vendor was to avoid adding vendor specific quirks to acpi's video code. If it was the right implementation different story, but it sure sounded like a sensble idea. We do have platform drivers that know if they should control backlight or let it do to ACPI or even the native driver. Quirks in the patform specific code _is_ IMO the right place to have those quirks. The problem with this is that it causes module load ordering issues where we get the acpi_video# device registered first, then a vendor specific custom acpi backlight driver (ie thinkpad_acpi) loads and unregisters it again. This is ugly and on some models makes the firmware unhappy (we currently have quirks for these models to work around this). But I've recently learned that since for determining which firmware method to load / expose we need to know if the video driver will register a raw backlight interface or not, which introduces similar issues. So there is no way to avoid these ordering issues, so I agree that it is best to keep the quirks in the vendor specific acpi extension drivers where possible. 5) Switch all drivers from acpi_video_backlight_support() to acpi_backlight_method() The plan would be to do 1-3 in a single patch and ASAP and then do 4 and 5 driver by driver
[PATCH v2 3/3] acer-wmi: Add Aspire 5741 to video_vendor_dmi_table
The Aspire 5741 has broken acpi-video backlight control, so add it to the
quirk table.
https://bugzilla.redhat.com/show_bug.cgi?id=1012674
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 3a74699..bbf78b2 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -570,6 +570,14 @@ static const struct dmi_system_id video_vendor_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5750),
},
},
+ {
+ .callback = video_set_backlight_video_vendor,
+ .ident = Acer Aspire 5741,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Acer),
+ DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5741),
+ },
+ },
{}
};
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] acpi-video: Add an acpi_video_unregister_backlight function
Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.
Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:
acpi_video_dmi_promote_vendor();
acpi_video_unregister();
The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.
This leads to the following 2 interesting scenarios:
a) intel gfx:
1) acpi-video module gets loaded (as it is a dependency of acpi_vendor and i915)
2) acpi-video does NOT call acpi_video_register()
3) acpi_vendor loads (lets assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
b) non intel gfx
1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.
Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!
So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c | 14 ++
include/acpi/video.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 52176ad..ba6e4d7 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -2166,6 +2166,20 @@ void acpi_video_unregister(void)
}
EXPORT_SYMBOL(acpi_video_unregister);
+void acpi_video_unregister_backlight(void)
+{
+ struct acpi_video_bus *video;
+
+ if (!register_count)
+ return;
+
+ mutex_lock(video_list_lock);
+ list_for_each_entry(video, video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(video_list_lock);
+}
+EXPORT_SYMBOL(acpi_video_unregister_backlight);
+
/*
* This is kind of nasty. Hardware using Intel chipsets may require
* the video opregion code to be run first in order to initialise
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 61109f2..ea4c7bb 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -19,11 +19,13 @@ struct acpi_device;
#if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
extern int acpi_video_register(void);
extern void acpi_video_unregister(void);
+extern void acpi_video_unregister_backlight(void);
extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
#else
static inline int acpi_video_register(void) { return 0; }
static inline void acpi_video_unregister(void) { return; }
+static inline void acpi_video_unregister_backlight(void) { return; }
static inline int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid)
{
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] acer-wmi: Switch to acpi_video_unregister_backlight
Switch from acpi_video_unregister(), to acpi_video_unregister_backlight(),
so that the hotkeys handler registered by acpi-video stays in place.
Since there are no mappings for the atkbd raw codes for the brightness
keys used by newer Acer models in /lib/udev/hwdb.d/60-keyboard.hwdb, and
since we map the wmi events with a code of KE_IGNORE, we rely on acpi-video
to do the hotkey handling for us.
For laptops such as the Acer Aspire 5750 which uses intel gfx this works
despite us calling acpi_video_unregister() because the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi and i915)
2) acpi-video does NOT call acpi_video_register()
3) acer-wmi loads (assume it loads before i915), calls
acpi_video_dmi_promote_vendor(); which sets ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
4) calls acpi_video_unregister - not registered, nop
5) i915 loads, calls acpi_video_register
6) acpi_video_register registers the acpi_notifier for the hotkeys,
does NOT register a backlight device because of
ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
But on the Acer Aspire 5750G, which uses nvidia graphics the following happens:
1) acpi-video module gets loaded (as it is a dependency of acer-wmi)
2) acpi-video calls acpi_video_register()
3) acpi_video_register registers the acpi_notifier for the hotkeys,
and a backlight device
4) acer-wmi loads, calls acpi_video_dmi_promote_vendor()
5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier for
the hotkeys AND the backlight device
And we end up without any handler for the brightness hotkeys. This patch fixes
this by switching over to acpi_video_unregister_backlight() which keeps the
hotkey handler in place.
https://bugzilla.kernel.org/show_bug.cgi?id=35622
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c91f69b3..3a74699 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -2228,7 +2228,7 @@ static int __init acer_wmi_init(void)
pr_info(Brightness must be controlled by acpi video driver\n);
} else {
pr_info(Disabling ACPI video driver\n);
- acpi_video_unregister();
+ acpi_video_unregister_backlight();
}
if (wmi_has_guid(WMID_GUID3)) {
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Add acpi_video_unregister_backlight(), use in acer-wmi
Hi All, Here is a v2 of my patch series to fix: https://bugzilla.kernel.org/show_bug.cgi?id=35622 https://bugzilla.redhat.com/show_bug.cgi?id=1012674 I think its best if the entire series goes upstream through the acpi tree since the platform/x86 patches depend on the acpi changes. Changes since v1: -Fix the syntax error in the #ifndef CONFIG_ACPI_VIDEO acpi_video_unregister_backlight inline definition. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Cleanup firmware backlight control method selection
Hi, On 05/19/2014 01:24 AM, Mattia Dongili wrote: On Fri, May 16, 2014 at 10:06:15AM +0200, Hans de Goede wrote: snip This is only a problem with crazy PC's which have multiple firmware API's (both standardized and custom ACPI) to control the backlight, which also are sometimes all broken. So this really is an acpi thing, and I believe this should stay in acpi/video_detect.c where it already lives, I just think the video.use_native_backlight option which clearly interacts with this needs to be moved to acpi/video_detect.c too. I didn't realize the use_native_backlight option was in acpi/video.c. Nevemind what I said, leave this crazyness to stay in the acpi world only then. Don't you still have ordering issues though? can the raw device be loaded after video_detect runs? Yes it can, so I've already withdrawn my part of the proposal to move all the quirks to acpi/video_detect.c since we will simply have to learn to live with the ordering issues it seems. A solution for dealing with the raw interface showing up later is discussed here: http://www.spinics.net/lists/stable/msg45563.html http://www.spinics.net/lists/stable/msg45977.html 3) Add an acpi_backlight_method() function which will: - return acpi_backlight_method_cmdline if not -1; else - return acpi_backlight_method_dmi if not -1; else - return ACPI_BACKLIGHT_NATIVE if acpi_osi_is_win8(); else this seems to be a way more wide case than today's code that combines it with quirks or the kernel option. Except for allowing to circumvent the acpi_osi_is_win8() check from the cmdline / from dmi based quirks this will have 100% the same functionality as today. - return ACPI_BACKLIGHT_VIDEO if supported; else - return ACPI_BACKLIGHT_VENDOR ... *) Note I'm only talking about controlling the actual brightness of the backlight, not detecting brighness/backlight hotkey presses, there are similar issues there. But I believe that that should be treated as an orthogonal problem which should be fixed independently of this. Maybe I'm missing some recent evolution but except for some special cases, backlight hotkeys generally result in an input event sent to userspace and it then becomese a userspace problem to choose which interface to use. Not sure if you're referring to the above discussion here, or to my remark about hotkey issues, so let me answer both: * As for why we cannot simply register all firmware backlight drivers and let userspace figure things out. There are 2 reasons: 1) Userspace will pick the first firmware driver it sees, to avoid this causing issues we've historically always registered only one. So we're stuck with this approach to avoid causing regressions well, in my limited experience I have seen userspace anyway blacklist the sony/acpi backlight control for the intel one since it is available regardless of acpi and gives (actually used to give) better granularity. We really don't want this kind of blacklisting in user space, instead if the interface is broken (or less functional then the alternative) we should simply not register it at all. Maybe if we were to redesign all this we would leave all this up to userspace (so load no backlight driver at all, and let userspace pick one), but that ship has sailed, so since we're determining what to do in kernel space now, lets keep it in kernel space and not some crazy mix where first kernel space does some quirks / blacklisting and then userspace (depending on which DE also) adds its own magic. Lets not go there please. snip vaio discussion, which as said does not belong in this thread Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS Motherboard
Hi, On 06/10/2014 06:16 PM, Matthew Garrett wrote: On Thu, 2014-05-15 at 11:39 +0200, Hans de Goede wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1097436 I'm not especially keen on this - if this seems like a general problem, adding boards piecemeal to a DMI table will never solve it for most people. What does performing the backlight calls actually do? The user has reported no adverse effects from the backlight control being present, other then gnome3 showing a brightness control in its system menu which is undesirable on a desktop machine. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS Motherboard
Hi, On 06/10/2014 06:17 PM, Matthew Garrett wrote: On Tue, 2014-06-10 at 16:16 +, Matthew Garrett wrote: On Thu, 2014-05-15 at 11:39 +0200, Hans de Goede wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1097436 I'm not especially keen on this - if this seems like a general problem, adding boards piecemeal to a DMI table will never solve it for most people. What does performing the backlight calls actually do? Or, alternatively, check the DMI chassis type and just skip desktop boards? That might work, note that part of the problem is the BIOS exporting an acpi-video interface. So we would either need to do this check in the acpi-video driver, or alternatively do it in the asus-wmi driver and call acpi_video_dmi_promote_vendor() when the check fails. I'm not 100% sold on adding this check in general, because it assumes that the chassis type will be reliable, which seems like a long shot, ie what if an all in one, with a backlight, uses 3 / Desktop as chassis type ? Note that once the acpi-video interface is disabled by using e.g. acpi_backlight=vendor, then the asus-wmi driver will create a backlight control with a max_brightness of 0, which seems like a bug in the asus-wmi driver. I did not do a patch for this because I was afraid that not registering the asus-wmi brightness control when the max_brightness == 0 might cause regressions (e.g. it will also remove the bl_power function, what if in some cases max_brightness == 0, but we want / need bl_power ?) . Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] eeepc-wmi: Add no backlight quirk for Asus H87I-PLUS Motherboard
Hi, On 06/11/2014 06:03 PM, Matthew Garrett wrote: On Wed, 2014-06-11 at 15:57 +0200, Hans de Goede wrote: Hi, On 06/10/2014 06:16 PM, Matthew Garrett wrote: On Thu, 2014-05-15 at 11:39 +0200, Hans de Goede wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1097436 I'm not especially keen on this - if this seems like a general problem, adding boards piecemeal to a DMI table will never solve it for most people. What does performing the backlight calls actually do? The user has reported no adverse effects from the backlight control being present, other then gnome3 showing a brightness control in its system menu which is undesirable on a desktop machine. Sorry, yeah, I wasn't clear. What results do we get from the calls? If they just return 0s then we should alter the driver to skip backlight registration in that case. The acpi_video0 backlight interface reports a max_backlight of 100, so it appears to be functional, unlike the asus-wmi interface which is present but appears non functional. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mapping of F11 and F12 on new lenovo laptops and Lenovo Compact Keyboard
Hi Jamie, I saw your patch-set for the Lenovo Compact Keyboard on the lwn.net kernel page. This spiked my interest as I'm the author of this patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=8b9dd4fab26a0f328420cbda0845a325f45bcd92 Which adds mapping for the F9 - F12 on the Lenovo *40 series laptops, which have the same weird symbols on F11 and F12 as the Lenovo Compact Keyboard, the ones which you describe as: /* Fn-F11: View open applications (3 boxes) */ /* Fn-F12: Open My computer (6 boxes) USB-only */ You map these to: KEY_FN_F11 KEY_FILE Where as my (already merged into Linus tree) patch maps these to: KEY_SCALE KEY_COMPUTER Which are defined in linux/uapi/input.h as: #define KEY_SCALE 120 /* AL Compiz Scale (Expose) */ #define KEY_COMPUTER157 Which I believe maps closes to View open applications (which to me sounds like expose mode) and Open My computer. Note that on the laptops the keys have their special meaning by default and using Fn turns them back into normal F11 keys, so KEY_FN_F11 seems like a particular bad match as that suggests a key combo which it is not on the laptops. Anyways lets discuss and coordinate, so that we end up with the same mappings for the weird symbols on F11 and F12 for the laptops and for the Lenovo Compact Keyboard. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mapping of F11 and F12 on new lenovo laptops and Lenovo Compact Keyboard
Hi, On 06/20/2014 02:00 PM, Jamie Lentin wrote: On Thu, 19 Jun 2014, Hans de Goede wrote: Hi Jamie, I saw your patch-set for the Lenovo Compact Keyboard on the lwn.net kernel page. This spiked my interest as I'm the author of this patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/thinkpad_acpi.c?id=8b9dd4fab26a0f328420cbda0845a325f45bcd92 Which adds mapping for the F9 - F12 on the Lenovo *40 series laptops, which have the same weird symbols on F11 and F12 as the Lenovo Compact Keyboard, the ones which you describe as: /* Fn-F11: View open applications (3 boxes) */ /* Fn-F12: Open My computer (6 boxes) USB-only */ You map these to: KEY_FN_F11 KEY_FILE Where as my (already merged into Linus tree) patch maps these to: KEY_SCALE KEY_COMPUTER Which are defined in linux/uapi/input.h as: #define KEY_SCALE 120 /* AL Compiz Scale (Expose) */ #define KEY_COMPUTER157 Which I believe maps closes to View open applications (which to me sounds like expose mode) and Open My computer. Yes, the Function keys look the same:- http://www.lenovo.com/images/gallery/1060x596/lenovo-laptop-thinkpad-t440-overhead-keyboard-2.jpg https://c2.staticflickr.com/6/5467/9092693533_440cfcf311_z.jpg I went with KEY_FILE on the USB keyboard, since this is what it's mapped to on the Bluetooth keyboard, as part of the CONSUMER usage page:- http://lxr.free-electrons.com/source/drivers/hid/hid-input.c#L694 Ah, well if the bluetooth version of the keyboard actually uses a standard HUT code for that and that maps to KEY_FILE, then I agree that it would be best to map the F-12 key to KEY_FILE. Personally I've no fondness to what the keys map to, since I remap them to how they are labelled on an Thinkpad X230, which is pause/nexttrack. However, it seems somewhat silly customising something that appears to be a standard mapping. Note that on the laptops the keys have their special meaning by default and using Fn turns them back into normal F11 keys, so KEY_FN_F11 seems like a particular bad match as that suggests a key combo which it is not on the laptops. That's true. It works fine with Fn-ESC but yes, on these keyboards they are labelled such that F11 is the Fn-modified version. Right so lets just go with KEY_SCALE then? If you switch F-11 to KEY_SCALE in the next version of your patch set, then I'll send a followup patch for thinkpad-acpi to change F-12 to KEY_FILE, and then the 2 mappings will be in sync. Agreed ? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thinkpad_acpi: Update mapping for F12 hotkey on *40 models to KEY_FILE
The new keyboard found on the *40 models is also being sold as a standalone keyboard (with trackpoint): http://shop.lenovo.com/us/en/itemdetails/0B47189/460/60AC6A0372B14F5BA7B12F1FF88E33C7 This uses a standard HUT code for the F12 key with the 6 square boxes on it, which gets mapped to KEY_FILE by the kernel. Change the mapping done of identical laptop key done by thinkpad_acpi to also send KEY_FILE for consistency. Cc: Jamie Lentin j...@lentin.co.uk Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/thinkpad_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index d82f196..0fefb24 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -3174,7 +3174,7 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) KEY_UNKNOWN, /* Extra keys in use since the X240 / T440 / T540 */ - KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_COMPUTER, + KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_FILE, }, }; -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] asus-wmi: backlight_init: Stop treating -ENODEV as if its not an error
When bl_power support got added to asus-wmi, the error handling for it was written to ignore -ENODEV, to avoid not registering a backlight interface for models which have no bl_power control, but do have brightness control. At the same time the error handling for brightness_max was modified to do the same, this is wrong, when there is no brightness_max asus-wmi should not register a backlight interface. Note the caller of asus_wmi_backlight_init already special cases -ENODEV, and will not cause the wmi driver regristration to fail because of a -ENODEV return from asus_wmi_backlight_init. https://bugzilla.redhat.com/show_bug.cgi?id=1097436 Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/asus-wmi.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 70aec19..8a88416 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -1271,10 +1271,7 @@ static int asus_wmi_backlight_init(struct asus_wmi *asus) int power; max = read_brightness_max(asus); - - if (max == -ENODEV) - max = 0; - else if (max 0) + if (max 0) return max; power = read_backlight_power(asus); -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] asus-wmi: Disable acpi-video backlight on desktop machines
Some Asus motherboards for desktop PC-s export an acpi-video interface
advertising backlight support. Test the dmi chassis-type and tell acpi-video
to not register a backlight interface on desktops.
https://bugzilla.redhat.com/show_bug.cgi?id=1097436
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-wmi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 3c6cced..70aec19 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -46,6 +46,7 @@
#include linux/platform_device.h
#include linux/thermal.h
#include linux/acpi.h
+#include linux/dmi.h
#include acpi/video.h
#include asus-wmi.h
@@ -1734,6 +1735,7 @@ static int asus_wmi_add(struct platform_device *pdev)
struct platform_driver *pdrv = to_platform_driver(pdev-dev.driver);
struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv);
struct asus_wmi *asus;
+ const char *chassis_type;
acpi_status status;
int err;
u32 result;
@@ -1770,6 +1772,11 @@ static int asus_wmi_add(struct platform_device *pdev)
if (err)
goto fail_rfkill;
+ /* Some Asus desktop boards export an acpi-video backlight interface,
+ stop this from showing up */
+ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
+ if (chassis_type !strcmp(chassis_type, 3))
+ acpi_video_dmi_promote_vendor();
if (asus-driver-quirks-wmi_backlight_power)
acpi_video_dmi_promote_vendor();
if (!acpi_video_backlight_support()) {
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] asus-wmi: Disable acpi-video backlight on desktop machi
Hi All, Here is v2 of my patch series to stop certain asus desktop motherboards registering a backlight interface for a non-existent backlight. Changes since v1: -Simply stop acpi-video from registering a backlight interface on all boards with a dmi-chassis-type of desktop rather then using a dmi-product-name based blacklist -Add a patch to make the asus-wmi not register its own backlight interface despite the BIOS having no support for it Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] asus-nb-wmi: Add wapf4 quirk for the X550CL
As reported here: https://bugs.launchpad.net/bugs/1277959
the X550CL needs wapf=4 too.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-nb-wmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index fd8e9d3..6e37531 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -146,6 +146,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = ASUSTeK COMPUTER INC. X550CL,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+ DMI_MATCH(DMI_PRODUCT_NAME, X550CL),
+ },
+ .driver_data = quirk_asus_wapf4,
+ },
+ {
+ .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. X55A,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] asus-nb-wmi.c: Rename x401u quirk to wapf4
The actual x401u does not use the so named x401u quirk but the x55u quirk.
All that the x401u quirk does it setting wapf to 4, so rename it to wapf4 to
stop the confusion.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-nb-wmi.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index ddf0eef..fd8e9d3 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -70,7 +70,7 @@ static struct quirk_entry quirk_asus_x55u = {
.no_display_toggle = true,
};
-static struct quirk_entry quirk_asus_x401u = {
+static struct quirk_entry quirk_asus_wapf4 = {
.wapf = 4,
};
@@ -97,7 +97,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X401A),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -106,7 +106,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X401A1),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -124,7 +124,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X501A),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -133,7 +133,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X501A1),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -142,7 +142,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X550CA),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -151,7 +151,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X55A),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -160,7 +160,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X55C),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -178,7 +178,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X55VD),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -187,7 +187,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, X75A),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -196,7 +196,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, 1015E),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{
.callback = dmi_matched,
@@ -205,7 +205,7 @@ static struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
DMI_MATCH(DMI_PRODUCT_NAME, 1015U),
},
- .driver_data = quirk_asus_x401u,
+ .driver_data = quirk_asus_wapf4,
},
{},
};
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
[PATCH] asus-nb-wmi: Add wapf4 quirk for the X550CC
As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681
the X550CC needs wapf=4 too.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-nb-wmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 6e37531..7196cd0 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -146,6 +146,15 @@ static struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = ASUSTeK COMPUTER INC. X550CC,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+ DMI_MATCH(DMI_PRODUCT_NAME, X550CC),
+ },
+ .driver_data = quirk_asus_wapf4,
+ },
+ {
+ .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. X550CL,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] asus-nb-wmi: Add wapf4 quirk for the U32U
As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681
the U32U needs wapf=4 too.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-nb-wmi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index 7196cd0..7a2c4cc 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -83,6 +83,20 @@ static int dmi_matched(const struct dmi_system_id *dmi)
static struct dmi_system_id asus_quirks[] = {
{
.callback = dmi_matched,
+ .ident = ASUSTeK COMPUTER INC. U32U,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK Computer Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, U32U),
+ },
+ /*
+* Note this machine has a Brazos APU, and most Brazos Asus
+* machines need quirk_asus_x55u / wmi_backlight_power but
+* here acpi-video seems to work fine for backlight control.
+*/
+ .driver_data = quirk_asus_wapf4,
+ },
+ {
+ .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. X401U,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] acer-wmi: Add acpi_backlight=video quirk for the Acer KAV80
https://bugzilla.redhat.com/show_bug.cgi?id=1128309
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 96a0b75..26c4fd1 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -579,6 +579,17 @@ static const struct dmi_system_id video_vendor_dmi_table[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, Aspire 5741),
},
},
+ {
+ /*
+* Note no video_set_backlight_video_vendor, we must use the
+* acer interface, as there is no native backlight interface.
+*/
+ .ident = Acer KAV80,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Acer),
+ DMI_MATCH(DMI_PRODUCT_NAME, KAV80),
+ },
+ },
{}
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] samsung-laptop: Add broken-acpi-video quirk for NC210/NC110
Reported (and tested) here:
https://bugzilla.redhat.com/show_bug.cgi?id=861573
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/samsung-laptop.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/platform/x86/samsung-laptop.c
b/drivers/platform/x86/samsung-laptop.c
index 5a59665..ff765d8 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -1561,6 +1561,16 @@ static struct dmi_system_id __initdata
samsung_dmi_table[] = {
},
{
.callback = samsung_dmi_matched,
+.ident = NC210,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, SAMSUNG ELECTRONICS CO., LTD.),
+ DMI_MATCH(DMI_PRODUCT_NAME, NC210/NC110),
+ DMI_MATCH(DMI_BOARD_NAME, NC210/NC110),
+ },
+.driver_data = samsung_broken_acpi_video,
+ },
+ {
+.callback = samsung_dmi_matched,
.ident = 730U3E/740U3E,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, SAMSUNG ELECTRONICS CO., LTD.),
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] asus-nb-wmi: Add another wapf=4 quirk
Reported through launchpad:
https://bugs.launchpad.net/bugs/1173681
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-nb-wmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index c1a6cd6..abdaed3 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -191,6 +191,15 @@ static const struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = ASUSTeK COMPUTER INC. X551CA,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+ DMI_MATCH(DMI_PRODUCT_NAME, X551CA),
+ },
+ .driver_data = quirk_asus_wapf4,
+ },
+ {
+ .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. X55A,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] asus-nb-wmi: Add another wapf=4 quirk
Wifi on this laptop does not work unless asus-nb-wmi.wapf=4 is specified on
the kerne commandline, add a quirk for this.
Cc: sta...@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1173681
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-nb-wmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-nb-wmi.c
b/drivers/platform/x86/asus-nb-wmi.c
index c1a6cd6..abdaed3 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -191,6 +191,15 @@ static const struct dmi_system_id asus_quirks[] = {
},
{
.callback = dmi_matched,
+ .ident = ASUSTeK COMPUTER INC. X551CA,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
+ DMI_MATCH(DMI_PRODUCT_NAME, X551CA),
+ },
+ .driver_data = quirk_asus_wapf4,
+ },
+ {
+ .callback = dmi_matched,
.ident = ASUSTeK COMPUTER INC. X55A,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, ASUSTeK COMPUTER INC.),
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] samsung-laptop: Add use_native_backlight quirk, and enable it on some models
Hi,
On 13-01-15 05:03, Darren Hart wrote:
On Fri, Jan 09, 2015 at 03:10:01PM +0100, Hans de Goede wrote:
Since kernel 3.14 the backlight control has been broken on various Samsung
Atom based netbooks. This has been bisected and this problem happens since
commit b35684b8fa94 (drm/i915: do full backlight setup at enable time)
This has been reported and discussed in detail here:
http://lists.freedesktop.org/archives/intel-gfx/2014-July/049395.html
Unfortunately no-one has been able to fix this. This only affects Samsung
Atom netbooks, and the Linux kernel and the BIOS of those laptops have never
worked well together. All affected laptops already have a quirk to avoid using
the standard acpi-video interface and instead use the samsung specific SABI
interface which samsung-laptop uses. It seems that recent fixes to the i915
driver have also broken backlight control through the SABI interface.
The intel_backlight driver OTOH works fine, and also allows for finer grained
backlight control. So add a new use_native_backlight quirk, and replace the
broken_acpi_video quirk with this quirk for affected models. This new quirk
disables acpi-video as before and also stops samsung-laptop from registering
I take this to me this quirk is broken_acpi_video use_native_backlight.
In what it does yes, but I've chosen to make it a standalone quirk named after
the acpi/video.c use_native_backlight option, which also disables both
acpi-video
and vendor backlight interfaces, so for consistency I'm using the same setup
here.
We cannot use the acpi/video.c option here because that option, which is on by
default, only triggers on win8 ready BIOS-es and these machines do not have such
a BIOS.
Eventually I would like to see the acpi/video.c code switch away from having
the 2 semi-orthogonal kernel cmdline options it currently has, which are
acpi_backlight=[vendor|video] vs video.use_native_backlight=[0|1], while what
we really have is just three options:
acpi_backlight=[vendor|video|native]
I've explained what I would like to see happen / think needs to happen to clean
up this mess here: https://lkml.org/lkml/2014/12/27/54
So the way I see it the broken_acpi_video quirks means use acpi_backlight=vendor
where as the new use_native_backlight option means acpi_backlight=native, and
eventually these 2 quirks would end up in just one call in samsung-laptop.c,
which
says:
acpi_video_set_backlight_type(acpi_video_backlight_vendor);
resp:
acpi_video_set_backlight_type(acpi_video_backlight_native);
So I really see this as an either or thing, yes native implies disabling
acpi_video# but that does not mean that it is the same thing as vendor.
the SABI based samsung_laptop backlight interface, leaving only the working
intel_backlight interface.
This commit enables this new quirk for 3 models which are known to be affected,
chances are that it needs to be used on other models too.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1094948 # N145P
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1115713 # N250P
Reported-by: Bertrik Sikken bert...@sikken.nl # N150P
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/samsung-laptop.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/samsung-laptop.c
b/drivers/platform/x86/samsung-laptop.c
index ff765d8..ce364a4 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -353,6 +353,7 @@ struct samsung_quirks {
bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
+ bool use_native_backlight;
};
static struct samsung_quirks samsung_unknown = {};
@@ -361,6 +362,10 @@ static struct samsung_quirks samsung_broken_acpi_video = {
.broken_acpi_video = true,
};
+static struct samsung_quirks samsung_use_native_backlight = {
+ .use_native_backlight = true,
Shouldn't this also set:
.broken_acpi_video = true,
?
That's what I understood from the commit log.
If you look at the code triggered by the new flag you will see that it disables
both acpi_video and avoids samsung_laptop from registering its own with just
the use_native_backlight flag set.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] samsung-laptop: Add use_native_backlight quirk, and enable it on some models
Since kernel 3.14 the backlight control has been broken on various Samsung
Atom based netbooks. This has been bisected and this problem happens since
commit b35684b8fa94 (drm/i915: do full backlight setup at enable time)
This has been reported and discussed in detail here:
http://lists.freedesktop.org/archives/intel-gfx/2014-July/049395.html
Unfortunately no-one has been able to fix this. This only affects Samsung
Atom netbooks, and the Linux kernel and the BIOS of those laptops have never
worked well together. All affected laptops already have a quirk to avoid using
the standard acpi-video interface and instead use the samsung specific SABI
interface which samsung-laptop uses. It seems that recent fixes to the i915
driver have also broken backlight control through the SABI interface.
The intel_backlight driver OTOH works fine, and also allows for finer grained
backlight control. So add a new use_native_backlight quirk, and replace the
broken_acpi_video quirk with this quirk for affected models. This new quirk
disables acpi-video as before and also stops samsung-laptop from registering
the SABI based samsung_laptop backlight interface, leaving only the working
intel_backlight interface.
This commit enables this new quirk for 3 models which are known to be affected,
chances are that it needs to be used on other models too.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1094948 # N145P
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1115713 # N250P
Reported-by: Bertrik Sikken bert...@sikken.nl # N150P
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/samsung-laptop.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/samsung-laptop.c
b/drivers/platform/x86/samsung-laptop.c
index ff765d8..ce364a4 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -353,6 +353,7 @@ struct samsung_quirks {
bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
+ bool use_native_backlight;
};
static struct samsung_quirks samsung_unknown = {};
@@ -361,6 +362,10 @@ static struct samsung_quirks samsung_broken_acpi_video = {
.broken_acpi_video = true,
};
+static struct samsung_quirks samsung_use_native_backlight = {
+ .use_native_backlight = true,
+};
+
static struct samsung_quirks samsung_np740u3e = {
.four_kbd_backlight_levels = true,
.enable_kbd_backlight = true,
@@ -1507,7 +1512,7 @@ static struct dmi_system_id __initdata
samsung_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, N150P),
DMI_MATCH(DMI_BOARD_NAME, N150P),
},
-.driver_data = samsung_broken_acpi_video,
+.driver_data = samsung_use_native_backlight,
},
{
.callback = samsung_dmi_matched,
@@ -1517,7 +1522,7 @@ static struct dmi_system_id __initdata
samsung_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, N145P/N250P/N260P),
DMI_MATCH(DMI_BOARD_NAME, N145P/N250P/N260P),
},
-.driver_data = samsung_broken_acpi_video,
+.driver_data = samsung_use_native_backlight,
},
{
.callback = samsung_dmi_matched,
@@ -1557,7 +1562,7 @@ static struct dmi_system_id __initdata
samsung_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, N250P),
DMI_MATCH(DMI_BOARD_NAME, N250P),
},
-.driver_data = samsung_broken_acpi_video,
+.driver_data = samsung_use_native_backlight,
},
{
.callback = samsung_dmi_matched,
@@ -1616,6 +1621,15 @@ static int __init samsung_init(void)
pr_info(Disabling ACPI video driver\n);
acpi_video_unregister();
}
+
+ if (samsung-quirks-use_native_backlight) {
+ pr_info(Using native backlight driver\n);
+ /* Tell acpi-video to not handle the backlight */
+ acpi_video_dmi_promote_vendor();
+ acpi_video_unregister();
+ /* And also do not handle it ourselves */
+ samsung-handle_backlight = false;
+ }
#endif
ret = samsung_platform_init(samsung);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] toshiba_acpi: Do not register vendor backlight when acpi_video bl is available
commit a39f46df33c6 (toshiba_acpi: Fix regression caused by backlight extra
check code) causes the backlight to no longer work on the Toshiba Z30,
reverting that commit fixes this but restores the original issue fixed
by that commit.
Looking at the toshiba_acpi backlight code for a fix for this I noticed that
the toshiba code is the only code under platform/x86 which unconditionally
registers a vendor acpi backlight interface, without checking for acpi_video
backlight support first.
This commit adds the necessary checks bringing toshiba_acpi in line with the
other drivers, and fixing the Z30 regression without needing to revert the
commit causing it.
Chances are that there will be some Toshiba models which have a non working
acpi-video implementation while the toshiba vendor backlight interface does
work, this commit adds an empty dmi_id table where such systems can be added,
this is identical to how other drivers handle such systems.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521
Signed-off-by: Hans de Goede hdego...@redhat.com
Reviewed-and-tested-by: Azael Avalos coproscef...@gmail.com
---
Changes in v2:
-Rebase on top of linux-platform-drivers-x86/for-next
-Add Azael's Reviewed-and-tested-by
---
drivers/platform/x86/Kconfig| 1 +
drivers/platform/x86/toshiba_acpi.c | 24
2 files changed, 25 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9752761..f9f205c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -614,6 +614,7 @@ config ACPI_TOSHIBA
depends on INPUT
depends on RFKILL || RFKILL = n
depends on SERIO_I8042 || SERIO_I8042 = n
+ depends on ACPI_VIDEO || ACPI_VIDEO = n
select INPUT_POLLDEV
select INPUT_SPARSEKMAP
---help---
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index f624dd5..9956b990 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -49,7 +49,9 @@
#include linux/workqueue.h
#include linux/i8042.h
#include linux/acpi.h
+#include linux/dmi.h
#include linux/uaccess.h
+#include acpi/video.h
MODULE_AUTHOR(John Belmonte);
MODULE_DESCRIPTION(Toshiba Laptop ACPI Extras Driver);
@@ -264,6 +266,14 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
};
/*
+ * List of models which have a broken acpi-video backlight interface and thus
+ * need to use the toshiba (vendor) interface instead.
+ */
+static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
+ {}
+};
+
+/*
* Utility
*/
@@ -2624,6 +2634,20 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
ret = get_tr_backlight_status(dev, enabled);
dev-tr_backlight_supported = !ret;
+ /*
+* Tell acpi-video-detect code to prefer vendor backlight on all
+* systems with transflective backlight and on dmi matched systems.
+*/
+ if (dev-tr_backlight_supported ||
+ dmi_check_system(toshiba_vendor_backlight_dmi))
+ acpi_video_dmi_promote_vendor();
+
+ if (acpi_video_backlight_support())
+ return 0;
+
+ /* acpi-video may have loaded before we called dmi_promote_vendor() */
+ acpi_video_unregister_backlight();
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] toshiba_acpi: Do not register vendor backlight when acpi_video bl is available
commit a39f46df33c6 (toshiba_acpi: Fix regression caused by backlight extra
check code) causes the backlight to no longer work on the Toshiba Z30,
reverting that commit fixes this but restores the original issue fixed
by that commit.
Looking at the toshiba_acpi backlight code for a fix for this I noticed that
the toshiba code is the only code under platform/x86 which unconditionally
registers a vendor acpi backlight interface, without checking for acpi_video
backlight support first.
This commit adds the necessary checks bringing toshiba_acpi in line with the
other drivers, and fixing the Z30 regression without needing to revert the
commit causing it.
Chances are that there will be some Toshiba models which have a non working
acpi-video implementation while the toshiba vendor backlight interface does
work, this commit adds an empty dmi_id table where such systems can be added,
this is identical to how other drivers handle such systems.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/Kconfig| 1 +
drivers/platform/x86/toshiba_acpi.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9752761..f9f205c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -614,6 +614,7 @@ config ACPI_TOSHIBA
depends on INPUT
depends on RFKILL || RFKILL = n
depends on SERIO_I8042 || SERIO_I8042 = n
+ depends on ACPI_VIDEO || ACPI_VIDEO = n
select INPUT_POLLDEV
select INPUT_SPARSEKMAP
---help---
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index dbcb7a8..2da716c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -51,6 +51,7 @@
#include linux/acpi.h
#include linux/dmi.h
#include linux/uaccess.h
+#include acpi/video.h
MODULE_AUTHOR(John Belmonte);
MODULE_DESCRIPTION(Toshiba Laptop ACPI Extras Driver);
@@ -281,6 +282,14 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
};
/*
+ * List of models which have a broken acpi-video backlight interface and thus
+ * need to use the toshiba (vendor) interface instead.
+ */
+static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
+ {}
+};
+
+/*
* Utility
*/
@@ -2541,6 +2550,20 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
ret = get_tr_backlight_status(dev, enabled);
dev-tr_backlight_supported = !ret;
+ /*
+* Tell acpi-video-detect code to prefer vendor backlight on all
+* systems with transflective backlight and on dmi matched systems.
+*/
+ if (dev-tr_backlight_supported ||
+ dmi_check_system(toshiba_vendor_backlight_dmi))
+ acpi_video_dmi_promote_vendor();
+
+ if (acpi_video_backlight_support())
+ return 0;
+
+ /* acpi-video may have loaded before we called dmi_promote_vendor() */
+ acpi_video_unregister_backlight();
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] toshiba_acpi: Do not register vendor backlight when acpi_video bl is available
Hi,
On 17-04-15 18:58, Azael Avalos wrote:
Hi there,
Sorry for the late reply, I've been a bit overwhelmed with work related stuff,
and to top it off I was having issues with one of my systems, but anyway,
on to the patch :-)
2015-04-15 8:11 GMT-06:00 Hans de Goede hdego...@redhat.com:
commit a39f46df33c6 (toshiba_acpi: Fix regression caused by backlight extra
check code) causes the backlight to no longer work on the Toshiba Z30,
reverting that commit fixes this but restores the original issue fixed
by that commit.
Looking at the toshiba_acpi backlight code for a fix for this I noticed that
the toshiba code is the only code under platform/x86 which unconditionally
registers a vendor acpi backlight interface, without checking for acpi_video
backlight support first.
This commit adds the necessary checks bringing toshiba_acpi in line with the
other drivers, and fixing the Z30 regression without needing to revert the
commit causing it.
Chances are that there will be some Toshiba models which have a non working
acpi-video implementation while the toshiba vendor backlight interface does
work, this commit adds an empty dmi_id table where such systems can be added,
this is identical to how other drivers handle such systems.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/Kconfig| 1 +
drivers/platform/x86/toshiba_acpi.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 9752761..f9f205c 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -614,6 +614,7 @@ config ACPI_TOSHIBA
depends on INPUT
depends on RFKILL || RFKILL = n
depends on SERIO_I8042 || SERIO_I8042 = n
+ depends on ACPI_VIDEO || ACPI_VIDEO = n
select INPUT_POLLDEV
select INPUT_SPARSEKMAP
---help---
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index dbcb7a8..2da716c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -51,6 +51,7 @@
#include linux/acpi.h
#include linux/dmi.h
#include linux/uaccess.h
+#include acpi/video.h
Is this patch intended for 4.1 (or later)?
Yes, this is intended for 4.1.
If so, you will need to
re-include linux/dmi.h as
commit a2b3471b5b13b81c5975d8f88db65694d7b69f56 dropped it.
Ok, I will rebase add your Reviewed-and-Tested-by and send a v2.
Regards,
Hans
MODULE_AUTHOR(John Belmonte);
MODULE_DESCRIPTION(Toshiba Laptop ACPI Extras Driver);
@@ -281,6 +282,14 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
};
/*
+ * List of models which have a broken acpi-video backlight interface and thus
+ * need to use the toshiba (vendor) interface instead.
+ */
+static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
+ {}
+};
+
+/*
* Utility
*/
@@ -2541,6 +2550,20 @@ static int toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
ret = get_tr_backlight_status(dev, enabled);
dev-tr_backlight_supported = !ret;
+ /*
+* Tell acpi-video-detect code to prefer vendor backlight on all
+* systems with transflective backlight and on dmi matched systems.
+*/
+ if (dev-tr_backlight_supported ||
+ dmi_check_system(toshiba_vendor_backlight_dmi))
+ acpi_video_dmi_promote_vendor();
+
+ if (acpi_video_backlight_support())
+ return 0;
+
+ /* acpi-video may have loaded before we called dmi_promote_vendor() */
+ acpi_video_unregister_backlight();
+
memset(props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
--
2.3.5
I've tested this on my (current) devices (Satellite X205, Qosmio X505 X75),
an taking the above comment into consideration, you can add:
Reviewed-and-Tested-by: Azael Avalos coproscef...@gmail.com
Cheers
Azael
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] acpi-video: Add a parameter to not register the backlight sysfs interface
On some systems acpi-video backlight is broken in the sense that it cannot
control the brightness of the backlight, but it must still be called on
resume to power-up the backlight after resume.
This commit allows these systems to work by going through all the usual
backlight control moves, while not registering a sysfs backlight
interface.
This commit also adds a quirk enabling this parameter on Toshiba Portege
R830 systems which are known to be affected by this.
I wish there was a better way to deal with this, but we've been unable to
find one.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=82634
Reported-and-tested-by: Sylvain Pasche sylvain.pas...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 518f0e1..351f52c 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -92,6 +92,9 @@ static int use_native_backlight_param =
NATIVE_BACKLIGHT_NOT_SET;
module_param_named(use_native_backlight, use_native_backlight_param, int,
0444);
static int use_native_backlight_dmi = NATIVE_BACKLIGHT_NOT_SET;
+static int disable_backlight_sysfs_if = -1;
+module_param(disable_backlight_sysfs_if, int, 0444);
+
static int register_count;
static struct mutex video_list_lock;
static struct list_head video_bus_head;
@@ -431,6 +434,14 @@ static int __init video_enable_native_backlight(const
struct dmi_system_id *d)
return 0;
}
+static int __init video_disable_backlight_sysfs_if(
+ const struct dmi_system_id *d)
+{
+ if (disable_backlight_sysfs_if == -1)
+ disable_backlight_sysfs_if = 1;
+ return 0;
+}
+
static struct dmi_system_id video_dmi_table[] __initdata = {
/*
* Broken _BQC workaround
http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -592,6 +603,23 @@ static struct dmi_system_id video_dmi_table[] __initdata =
{
DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro12,1),
},
},
+
+ /*
+* Some machines have a broken acpi-video interface for brightness
+* control, but still need an acpi_video_device_lcd_set_level() call
+* on resume to turn the backlight power on. We Enable backlight
+* control on these systems, but do not register a backlight sysfs
+* as brightness control does not work.
+*/
+ {
+/* https://bugs.freedesktop.org/show_bug.cgi?id=82634 */
+.callback = video_disable_backlight_sysfs_if,
+.ident = Toshiba Portege R830,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, PORTEGE R830),
+ },
+ },
{}
};
@@ -1391,7 +1419,7 @@ acpi_video_switch_brightness(struct work_struct *work)
int result = -EINVAL;
/* no warning message if acpi_backlight=vendor or a quirk is used */
- if (!acpi_video_verify_backlight_support())
+ if (!acpi_video_verify_backlight_support() || !device-backlight)
return;
if (!device-brightness)
@@ -1666,8 +1694,9 @@ static int acpi_video_resume(struct notifier_block *nb,
for (i = 0; i video-attached_count; i++) {
video_device = video-attached_array[i].bind_info;
- if (video_device video_device-backlight)
- acpi_video_set_brightness(video_device-backlight);
+ if (video_device video_device-brightness)
+ acpi_video_device_lcd_set_level(video_device,
+ video_device-brightness-curr);
}
return NOTIFY_OK;
@@ -1716,6 +1745,10 @@ static void acpi_video_dev_register_backlight(struct
acpi_video_device *device)
result = acpi_video_init_brightness(device);
if (result)
return;
+
+ if (disable_backlight_sysfs_if 0)
+ return;
+
name = kasprintf(GFP_KERNEL, acpi_video%d, count);
if (!name)
return;
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] acpi-video: Add a parameter to not register the backlight sysfs interface
On some systems acpi-video backlight is broken in the sense that it cannot
control the brightness of the backlight, but it must still be called on
resume to power-up the backlight after resume.
This commit allows these systems to work by going through all the usual
backlight control moves, while not registering a sysfs backlight
interface.
This commit also adds a quirk enabling this parameter on Toshiba Portege
R830 systems which are known to be affected by this.
I wish there was a better way to deal with this, but we've been unable to
find one.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=21012
Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=82634
Reported-and-tested-by: Sylvain Pasche sylvain.pas...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Simplify check in acpi_video_switch_brightness()
-If backlight registration fails set device-backlight to NULL, rather
then leaving the PTR_ERR in there and trying to deref this later
(this fixes a pre-existing bug)
---
drivers/acpi/video.c | 43 +++
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 518f0e1..3bc4c68 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -92,6 +92,9 @@ static int use_native_backlight_param =
NATIVE_BACKLIGHT_NOT_SET;
module_param_named(use_native_backlight, use_native_backlight_param, int,
0444);
static int use_native_backlight_dmi = NATIVE_BACKLIGHT_NOT_SET;
+static int disable_backlight_sysfs_if = -1;
+module_param(disable_backlight_sysfs_if, int, 0444);
+
static int register_count;
static struct mutex video_list_lock;
static struct list_head video_bus_head;
@@ -431,6 +434,14 @@ static int __init video_enable_native_backlight(const
struct dmi_system_id *d)
return 0;
}
+static int __init video_disable_backlight_sysfs_if(
+ const struct dmi_system_id *d)
+{
+ if (disable_backlight_sysfs_if == -1)
+ disable_backlight_sysfs_if = 1;
+ return 0;
+}
+
static struct dmi_system_id video_dmi_table[] __initdata = {
/*
* Broken _BQC workaround
http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -592,6 +603,23 @@ static struct dmi_system_id video_dmi_table[] __initdata =
{
DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro12,1),
},
},
+
+ /*
+* Some machines have a broken acpi-video interface for brightness
+* control, but still need an acpi_video_device_lcd_set_level() call
+* on resume to turn the backlight power on. We Enable backlight
+* control on these systems, but do not register a backlight sysfs
+* as brightness control does not work.
+*/
+ {
+/* https://bugs.freedesktop.org/show_bug.cgi?id=82634 */
+.callback = video_disable_backlight_sysfs_if,
+.ident = Toshiba Portege R830,
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, PORTEGE R830),
+ },
+ },
{}
};
@@ -1391,7 +1419,7 @@ acpi_video_switch_brightness(struct work_struct *work)
int result = -EINVAL;
/* no warning message if acpi_backlight=vendor or a quirk is used */
- if (!acpi_video_verify_backlight_support())
+ if (!device-backlight)
return;
if (!device-brightness)
@@ -1666,8 +1694,9 @@ static int acpi_video_resume(struct notifier_block *nb,
for (i = 0; i video-attached_count; i++) {
video_device = video-attached_array[i].bind_info;
- if (video_device video_device-backlight)
- acpi_video_set_brightness(video_device-backlight);
+ if (video_device video_device-brightness)
+ acpi_video_device_lcd_set_level(video_device,
+ video_device-brightness-curr);
}
return NOTIFY_OK;
@@ -1716,6 +1745,10 @@ static void acpi_video_dev_register_backlight(struct
acpi_video_device *device)
result = acpi_video_init_brightness(device);
if (result)
return;
+
+ if (disable_backlight_sysfs_if 0)
+ return;
+
name = kasprintf(GFP_KERNEL, acpi_video%d, count);
if (!name)
return;
@@ -1738,8 +1771,10 @@ static void acpi_video_dev_register_backlight(struct
acpi_video_device *device)
acpi_backlight_ops,
props);
kfree(name);
- if (IS_ERR(device-backlight))
+ if (IS_ERR(device-backlight)) {
+ device-backlight = NULL;
return;
+ }
/*
* Save current brightness level in case we have to restore it
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
[PATCH 23/32] ideapad-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/ideapad-laptop.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index b496db8..bea0228 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -38,6 +38,7 @@
#include linux/i8042.h
#include linux/dmi.h
#include linux/device.h
+#include acpi/video.h
#define IDEAPAD_RFKILL_DEV_NUM (3)
@@ -903,7 +904,7 @@ static int ideapad_acpi_add(struct platform_device *pdev)
ideapad_sync_rfk_state(priv);
ideapad_sync_touchpad_state(priv);
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
ret = ideapad_backlight_init(priv);
if (ret ret != -ENODEV)
goto backlight_failed;
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/32] eeepc-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple ls /sys/class/backlight suffices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/eeepc-laptop.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index 844c209..8cdf315 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -37,6 +37,7 @@
#include linux/pci_hotplug.h
#include linux/leds.h
#include linux/dmi.h
+#include acpi/video.h
#define EEEPC_LAPTOP_VERSION 0.1
#define EEEPC_LAPTOP_NAME Eee PC Hotkey Driver
@@ -1433,12 +1434,10 @@ static int eeepc_acpi_add(struct acpi_device *device)
if (result)
goto fail_platform;
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
result = eeepc_backlight_init(eeepc);
if (result)
goto fail_backlight;
- } else {
- pr_info(Backlight controlled by ACPI video driver\n);
}
result = eeepc_input_init(eeepc);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/32] fujitsu-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/fujitsu-laptop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 2a9afa2..1c62caf 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -72,6 +72,7 @@
#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
#include linux/leds.h
#endif
+#include acpi/video.h
#define FUJITSU_DRIVER_VERSION 0.6.0
@@ -1099,7 +1100,7 @@ static int __init fujitsu_init(void)
/* Register backlight stuff */
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
struct backlight_properties props;
memset(props, 0, sizeof(struct backlight_properties));
@@ -1137,8 +1138,7 @@ static int __init fujitsu_init(void)
}
/* Sync backlight power status (needs FUJ02E3 device, hence deferred) */
-
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
if (call_fext_func(FUNC_BACKLIGHT, 0x2, 0x4, 0x0) == 3)
fujitsu-bl_device-props.power = FB_BLANK_POWERDOWN;
else
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/32] dell-wmi: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface selection API. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/dell-wmi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c index 6512a06..f2d77fe 100644 --- a/drivers/platform/x86/dell-wmi.c +++ b/drivers/platform/x86/dell-wmi.c @@ -35,6 +35,7 @@ #include linux/acpi.h #include linux/string.h #include linux/dmi.h +#include acpi/video.h MODULE_AUTHOR(Matthew Garrett m...@redhat.com); MODULE_DESCRIPTION(Dell laptop WMI hotkeys driver); @@ -397,7 +398,7 @@ static int __init dell_wmi_init(void) } dmi_walk(find_hk_type, NULL); - acpi_video = acpi_video_backlight_support(); + acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor; err = dell_wmi_input_setup(); if (err) -- 2.4.2 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/32] acpi-video: Port to new backlight interface selection API
Most of the patch is moving the dmi quirks for forcing use of the
acpi-video / the native backlight interface to video_detect.c.
What remains is a nice cleanup.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c| 178 +++-
drivers/acpi/video_detect.c | 130
include/acpi/video.h| 2 -
3 files changed, 141 insertions(+), 169 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 6249968..1bbe9b1 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -78,20 +78,6 @@ module_param(brightness_switch_enabled, bool, 0644);
static bool allow_duplicates;
module_param(allow_duplicates, bool, 0644);
-/*
- * For Windows 8 systems: used to decide if video module
- * should skip registering backlight interface of its own.
- */
-enum {
- NATIVE_BACKLIGHT_NOT_SET = -1,
- NATIVE_BACKLIGHT_OFF,
- NATIVE_BACKLIGHT_ON,
-};
-
-static int use_native_backlight_param = NATIVE_BACKLIGHT_NOT_SET;
-module_param_named(use_native_backlight, use_native_backlight_param, int,
0444);
-static int use_native_backlight_dmi = NATIVE_BACKLIGHT_NOT_SET;
-
static int register_count;
static struct mutex video_list_lock;
static struct list_head video_bus_head;
@@ -241,24 +227,6 @@ static int acpi_video_get_next_level(struct
acpi_video_device *device,
u32 level_current, u32 event);
static void acpi_video_switch_brightness(struct work_struct *work);
-static bool acpi_video_use_native_backlight(void)
-{
- if (use_native_backlight_param != NATIVE_BACKLIGHT_NOT_SET)
- return use_native_backlight_param;
- else if (use_native_backlight_dmi != NATIVE_BACKLIGHT_NOT_SET)
- return use_native_backlight_dmi;
- return acpi_osi_is_win8();
-}
-
-bool acpi_video_verify_backlight_support(void)
-{
- if (acpi_video_use_native_backlight()
- backlight_device_registered(BACKLIGHT_RAW))
- return false;
- return acpi_video_backlight_support();
-}
-EXPORT_SYMBOL_GPL(acpi_video_verify_backlight_support);
-
/* backlight device sysfs support */
static int acpi_video_get_brightness(struct backlight_device *bd)
{
@@ -419,18 +387,6 @@ static int __init video_set_bqc_offset(const struct
dmi_system_id *d)
return 0;
}
-static int __init video_disable_native_backlight(const struct dmi_system_id *d)
-{
- use_native_backlight_dmi = NATIVE_BACKLIGHT_OFF;
- return 0;
-}
-
-static int __init video_enable_native_backlight(const struct dmi_system_id *d)
-{
- use_native_backlight_dmi = NATIVE_BACKLIGHT_ON;
- return 0;
-}
-
static struct dmi_system_id video_dmi_table[] __initdata = {
/*
* Broken _BQC workaround
http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -475,123 +431,6 @@ static struct dmi_system_id video_dmi_table[] __initdata
= {
DMI_MATCH(DMI_PRODUCT_NAME, Aspire 7720),
},
},
-
- /*
-* These models have a working acpi_video backlight control, and using
-* native backlight causes a regression where backlight does not work
-* when userspace is not handling brightness key events. Disable
-* native_backlight on these to fix this:
-* https://bugzilla.kernel.org/show_bug.cgi?id=81691
-*/
- {
-.callback = video_disable_native_backlight,
-.ident = ThinkPad T420,
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, LENOVO),
- DMI_MATCH(DMI_PRODUCT_VERSION, ThinkPad T420),
- },
- },
- {
-.callback = video_disable_native_backlight,
-.ident = ThinkPad T520,
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, LENOVO),
- DMI_MATCH(DMI_PRODUCT_VERSION, ThinkPad T520),
- },
- },
- {
-.callback = video_disable_native_backlight,
-.ident = ThinkPad X201s,
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, LENOVO),
- DMI_MATCH(DMI_PRODUCT_VERSION, ThinkPad X201s),
- },
- },
-
- /* The native backlight controls do not work on some older machines */
- {
-/* https://bugs.freedesktop.org/show_bug.cgi?id=81515 */
-.callback = video_disable_native_backlight,
-.ident = HP ENVY 15 Notebook,
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, Hewlett-Packard),
- DMI_MATCH(DMI_PRODUCT_NAME, HP ENVY 15 Notebook PC),
- },
- },
-
- {
-.callback = video_disable_native_backlight,
-.ident = SAMSUNG 870Z5E/880Z5E/680Z5E,
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, SAMSUNG ELECTRONICS CO., LTD.),
- DMI_MATCH(DMI_PRODUCT_NAME, 870Z5E/880Z5E/680Z5E),
- },
- },
- {
-.callback = video_disable_native_backlight
[PATCH 09/32] drm: i915: Port to new backlight interface selection API
This results in a nice cleanup, as we can replace the complicated logic
from should_ignore_backlight_request() with a simple check for the type
being native.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/gpu/drm/i915/intel_opregion.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 71e87ab..4813374 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -396,16 +396,6 @@ int intel_opregion_notify_adapter(struct drm_device *dev,
pci_power_t state)
return -EINVAL;
}
-/*
- * If the vendor backlight interface is not in use and ACPI backlight interface
- * is broken, do not bother processing backlight change requests from firmware.
- */
-static bool should_ignore_backlight_request(void)
-{
- return acpi_video_backlight_support()
- !acpi_video_verify_backlight_support();
-}
-
static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -414,7 +404,7 @@ static u32 asle_set_backlight(struct drm_device *dev, u32
bclp)
DRM_DEBUG_DRIVER(bclp = 0x%08x\n, bclp);
- if (should_ignore_backlight_request()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_native) {
DRM_DEBUG_KMS(opregion backlight request ignored\n);
return 0;
}
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/32] msi-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple ls /sys/class/backlight suffices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/msi-laptop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/msi-laptop.c
b/drivers/platform/x86/msi-laptop.c
index 0859877..4231770 100644
--- a/drivers/platform/x86/msi-laptop.c
+++ b/drivers/platform/x86/msi-laptop.c
@@ -64,6 +64,7 @@
#include linux/i8042.h
#include linux/input.h
#include linux/input/sparse-keymap.h
+#include acpi/video.h
#define MSI_DRIVER_VERSION 0.5
@@ -1069,9 +1070,8 @@ static int __init msi_init(void)
/* Register backlight stuff */
- if (!quirks-old_ec_model || acpi_video_backlight_support()) {
- pr_info(Brightness ignored, must be controlled by ACPI video
driver\n);
- } else {
+ if (quirks-old_ec_model ||
+ acpi_video_get_backlight_type() == acpi_backlight_vendor) {
struct backlight_properties props;
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_PLATFORM;
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/32] acpi-video-detect: Move acpi_is_video_device() to acpi/scan.c
This allows video_detect.c to be build as a module, this is a preparation
patch for the backlight interface selection logic cleanup.
Note this commit also causes acpi_is_video_device() to always be build
indepedent of CONFIG_ACPI_VIDEO, as there is no reason to make its
building depend on CONFIG_ACPI_VIDEO.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/scan.c | 56 ++
drivers/acpi/video_detect.c | 60 -
include/linux/acpi.h| 8 ++
3 files changed, 58 insertions(+), 66 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 03141aa..811b40d 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1947,6 +1947,62 @@ bool acpi_dock_match(acpi_handle handle)
return acpi_has_method(handle, _DCK);
}
+static acpi_status
+acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
+ void **return_value)
+{
+ long *cap = context;
+
+ if (acpi_has_method(handle, _BCM)
+ acpi_has_method(handle, _BCL)) {
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO, Found generic backlight
+ support\n));
+ *cap |= ACPI_VIDEO_BACKLIGHT;
+ if (!acpi_has_method(handle, _BQC))
+ printk(KERN_WARNING FW_BUG PREFIX No _BQC method,
+ cannot determine initial brightness\n);
+ /* We have backlight support, no need to scan further */
+ return AE_CTRL_TERMINATE;
+ }
+ return 0;
+}
+
+/* Returns true if the ACPI object is a video device which can be
+ * handled by video.ko.
+ * The device will get a Linux specific CID added in scan.c to
+ * identify the device as an ACPI graphics device
+ * Be aware that the graphics device may not be physically present
+ * Use acpi_video_get_capabilities() to detect general ACPI video
+ * capabilities of present cards
+ */
+long acpi_is_video_device(acpi_handle handle)
+{
+ long video_caps = 0;
+
+ /* Is this device able to support video switching ? */
+ if (acpi_has_method(handle, _DOD) || acpi_has_method(handle, _DOS))
+ video_caps |= ACPI_VIDEO_OUTPUT_SWITCHING;
+
+ /* Is this device able to retrieve a video ROM ? */
+ if (acpi_has_method(handle, _ROM))
+ video_caps |= ACPI_VIDEO_ROM_AVAILABLE;
+
+ /* Is this device able to configure which video head to be POSTed ? */
+ if (acpi_has_method(handle, _VPO)
+ acpi_has_method(handle, _GPD)
+ acpi_has_method(handle, _SPD))
+ video_caps |= ACPI_VIDEO_DEVICE_POSTING;
+
+ /* Only check for backlight functionality if one of the above hit. */
+ if (video_caps)
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
+ ACPI_UINT32_MAX, acpi_backlight_cap_match,
NULL,
+ video_caps, NULL);
+
+ return video_caps;
+}
+EXPORT_SYMBOL(acpi_is_video_device);
+
const char *acpi_device_hid(struct acpi_device *device)
{
struct acpi_hardware_id *hid;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 68c45c3..aad5cf4 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -5,10 +5,6 @@
* May be copied or modified under the terms of the GNU General Public License
*
* video_detect.c:
- * Provides acpi_is_video_device() for early scanning of ACPI devices in scan.c
- * There a Linux specific (Spec does not provide a HID for video devices) is
- * assigned
- *
* After PCI devices are glued with ACPI devices
* acpi_get_pci_dev() can be called to identify ACPI graphics
* devices for which a real graphics card is plugged in
@@ -47,62 +43,6 @@ static long acpi_video_support;
static bool acpi_video_caps_checked;
static acpi_status
-acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context,
- void **return_value)
-{
- long *cap = context;
-
- if (acpi_has_method(handle, _BCM)
- acpi_has_method(handle, _BCL)) {
- ACPI_DEBUG_PRINT((ACPI_DB_INFO, Found generic backlight
- support\n));
- *cap |= ACPI_VIDEO_BACKLIGHT;
- if (!acpi_has_method(handle, _BQC))
- printk(KERN_WARNING FW_BUG PREFIX No _BQC method,
- cannot determine initial brightness\n);
- /* We have backlight support, no need to scan further */
- return AE_CTRL_TERMINATE;
- }
- return 0;
-}
-
-/* Returns true if the ACPI object is a video device which can be
- * handled by video.ko.
- * The device will get a Linux specific CID added in scan.c to
- * identify the device as an ACPI graphics device
- * Be aware that the graphics device may not be physically present
- * Use
[PATCH 03/32] acpi-video-detect: Make acpi_video_get_capabilities a private function
acpi_video_get_capabilities() is only used inside video_detect.c so make
it static. While at it also remove the prototype for the non existent
acpi_video_display_switch_support function from acpi.h
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video_detect.c | 3 +--
include/linux/acpi.h| 12
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 6ca1f27..68c45c3 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -184,7 +184,7 @@ static struct dmi_system_id video_detect_dmi_table[] = {
* all graphics capabilities of physically present devices are
* summarized and returned. This is cached and done only once.
*/
-long acpi_video_get_capabilities(acpi_handle graphics_handle)
+static long acpi_video_get_capabilities(acpi_handle graphics_handle)
{
long caps = 0;
struct acpi_device *tmp_dev;
@@ -227,7 +227,6 @@ long acpi_video_get_capabilities(acpi_handle
graphics_handle)
graphics_handle ? acpi_device_bid(tmp_dev) : ));
return caps;
}
-EXPORT_SYMBOL(acpi_video_get_capabilities);
static void acpi_video_caps_check(void)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 01bffd3..88c92a03 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -245,19 +245,12 @@ extern bool wmi_has_guid(const char *guid);
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-extern long acpi_video_get_capabilities(acpi_handle graphics_dev_handle);
extern long acpi_is_video_device(acpi_handle handle);
extern void acpi_video_dmi_promote_vendor(void);
extern int acpi_video_backlight_support(void);
-extern int acpi_video_display_switch_support(void);
#else
-static inline long acpi_video_get_capabilities(acpi_handle graphics_dev_handle)
-{
- return 0;
-}
-
static inline long acpi_is_video_device(acpi_handle handle)
{
return 0;
@@ -272,11 +265,6 @@ static inline int acpi_video_backlight_support(void)
return 0;
}
-static inline int acpi_video_display_switch_support(void)
-{
- return 0;
-}
-
#endif /* defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) */
extern int acpi_blacklisted(void);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/32] acpi-video-detect: Remove the unused acpi_video_dmi_demote_vendor() function
Remove the now unused acpi_video_dmi_demote_vendor() function, this was
never a proper counter part of acpi_video_dmi_promote_vendor() since
the calls to acpi_video_dmi_promote_vendor() are not counted.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video_detect.c | 9 -
include/linux/acpi.h| 5 -
2 files changed, 14 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index c42feb2..6ca1f27 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -258,15 +258,6 @@ void acpi_video_dmi_promote_vendor(void)
}
EXPORT_SYMBOL(acpi_video_dmi_promote_vendor);
-/* To be called when a driver who previously promoted the vendor
- * interface */
-void acpi_video_dmi_demote_vendor(void)
-{
- acpi_video_caps_check();
- acpi_video_support = ~ACPI_VIDEO_BACKLIGHT_DMI_VENDOR;
-}
-EXPORT_SYMBOL(acpi_video_dmi_demote_vendor);
-
/* Returns true if video.ko can do backlight switching */
int acpi_video_backlight_support(void)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index e4da5e3..01bffd3 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -248,7 +248,6 @@ extern bool wmi_has_guid(const char *guid);
extern long acpi_video_get_capabilities(acpi_handle graphics_dev_handle);
extern long acpi_is_video_device(acpi_handle handle);
extern void acpi_video_dmi_promote_vendor(void);
-extern void acpi_video_dmi_demote_vendor(void);
extern int acpi_video_backlight_support(void);
extern int acpi_video_display_switch_support(void);
@@ -268,10 +267,6 @@ static inline void acpi_video_dmi_promote_vendor(void)
{
}
-static inline void acpi_video_dmi_demote_vendor(void)
-{
-}
-
static inline int acpi_video_backlight_support(void)
{
return 0;
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/32] acpi-video-detect: Unregister acpi_video backlight when dmi quirks are added
Make acpi_video_set_dmi_backlight_type() call
acpi_video_unregister_backlight() when the new dmi quirk results in
the desired backlight interface being of a type other then
acpi_backlight_video.
This avoid the need for the second if in the following construction
which is currently found in many platform/x86 drivers:
if (prefer_vendor_quirk)
acpi_video_dmi_promote_vendor();
if (!acpi_video_backlight_support())
acpi_video_unregister_backlight()
This second if-block will be removed from the platform drivers as part
of their conversion to the new backlight interface selection API.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video_detect.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 01c8c46..98368cf 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -187,6 +187,9 @@ EXPORT_SYMBOL(acpi_video_get_backlight_type);
void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
{
acpi_backlight_dmi = type;
+ /* Remove acpi-video backlight interface if it is no longer desired */
+ if (acpi_video_get_backlight_type() != acpi_backlight_video)
+ acpi_video_unregister_backlight();
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/32] acpi-video: Rewrite backlight interface selection logic
Hi All, Here is the long promised rewrite / cleanup of the acpi-video (and platform/x86) backlight interface selection logic. Reviewers do not be alarmed by the large number of patches, the gist of the series is in patches 6-13, the earlier ones are a few simple prepararion patches, and the later ones all port over drivers to the new API one at a time. I've had to jump through some hoops to make it possible to still build the acpi_video code as a module. One downside of this is that the kernel commandline parameters have a changed prefix now. If people do not like this, an alternative would to change CONFIG_ACPI_VIDEO from a tristate to a bool, iow either build it in, or do not build it at all. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/32] apple-gmux: Stop using acpi_video_dmi_demote_vendor()
acpi_video_dmi_demote_vendor() is going away as part of the cleanup of the code for determinging which backlight class driver(s) to register. The call to acpi_video_dmi_demote_vendor() was meant to undo the call to acpi_video_dmi_promote_vendor() when the gmux device is removed, this is questionable though since the promote call sets a flag, not a counter, so the demote call may undo a promoto done elsewhere. Moreover in practice this is a nop since the gmux device is never removed, and the flag is only checked when acpi/video.ko gets loaded, so even if the user manually removes apple-gmux the demote call is still a nop as video.ko will already have loaded by this time. Also note that none of the other users of acpi_video_dmi_promote_vendor() use acpi_video_dmi_demote_vendor(). If we ever encounter a system with a gmux where the acpi-video interface should be used, then the proper fix would be to dmi-blacklist the gmux driver on that system. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/apple-gmux.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c index 45032ce..a7f6412 100644 --- a/drivers/platform/x86/apple-gmux.c +++ b/drivers/platform/x86/apple-gmux.c @@ -645,7 +645,6 @@ static void gmux_remove(struct pnp_dev *pnp) apple_gmux_data = NULL; kfree(gmux_data); - acpi_video_dmi_demote_vendor(); acpi_video_register(); apple_bl_register(); } -- 2.4.2 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 30/32] toshiba-acpi: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface selection API. Also fix a compiler warning about bt_present not being initialized. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/toshiba_acpi.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 9956b990..c484d47 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -2640,14 +2640,11 @@ static int toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev) */ if (dev-tr_backlight_supported || dmi_check_system(toshiba_vendor_backlight_dmi)) - acpi_video_dmi_promote_vendor(); + acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); - if (acpi_video_backlight_support()) + if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return 0; - /* acpi-video may have loaded before we called dmi_promote_vendor() */ - acpi_video_unregister_backlight(); - memset(props, 0, sizeof(props)); props.type = BACKLIGHT_PLATFORM; props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1; @@ -2733,7 +2730,7 @@ static int toshiba_acpi_add(struct acpi_device *acpi_dev) const char *hci_method; u32 special_functions; u32 dummy; - bool bt_present; + bool bt_present = false; int ret = 0; if (toshiba_acpi) -- 2.4.2 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/32] thinkpad-acpi: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/thinkpad_acpi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 28f3281..33e488c 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -83,6 +83,7 @@
#include sound/control.h
#include sound/initval.h
#include asm/uaccess.h
+#include acpi/video.h
/* ThinkPad CMOS commands */
#define TP_CMOS_VOLUME_DOWN0
@@ -3487,7 +3488,7 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
/* Do not issue duplicate brightness change events to
* userspace. tpacpi_detect_brightness_capabilities() must have
* been called before this point */
- if (acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() != acpi_backlight_vendor) {
pr_info(This ThinkPad has standard ACPI backlight
brightness control, supported by the ACPI
video driver\n);
@@ -6491,7 +6492,7 @@ static int __init brightness_init(struct ibm_init_struct
*iibm)
return 1;
}
- if (acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() != acpi_backlight_vendor) {
if (brightness_enable 1) {
pr_info(Standard ACPI backlight interface
available, not loading native one\n);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 31/32] acpi-video-detect: Remove old API
Remove the old backlight interface selection API now that all drivers
have been ported to the new API.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video_detect.c | 31 ---
include/linux/acpi.h| 19 ---
2 files changed, 50 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4989ba6..d5e6f1c 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -344,37 +344,6 @@ void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type)
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
-/*
- * Compatiblity function, this is going away as soon as all drivers are
- * converted to acpi_video_set_dmi_backlight_type().
- *
- * Promote the vendor interface instead of the generic video module.
- * After calling this function you will probably want to call
- * acpi_video_unregister() to make sure the video module is not loaded
- */
-void acpi_video_dmi_promote_vendor(void)
-{
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-}
-EXPORT_SYMBOL(acpi_video_dmi_promote_vendor);
-
-/*
- * Compatiblity function, this is going away as soon as all drivers are
- * converted to acpi_video_get_backlight_type().
- *
- * Returns true if video.ko can do backlight switching.
- */
-int acpi_video_backlight_support(void)
-{
- /*
-* This is done this way since vendor drivers call this to see
-* if they should load, and we do not want them to load for both
-* the acpi_backlight_video and acpi_backlight_native cases.
-*/
- return acpi_video_get_backlight_type() != acpi_backlight_vendor;
-}
-EXPORT_SYMBOL(acpi_video_backlight_support);
-
void __exit acpi_video_detect_exit(void)
{
if (backlight_notifier_registered)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 913a1c1..948c8a4 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -244,25 +244,6 @@ extern bool wmi_has_guid(const char *guid);
#define ACPI_VIDEO_OUTPUT_SWITCHING_DMI_VIDEO 0x0800
extern long acpi_is_video_device(acpi_handle handle);
-
-#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-
-extern void acpi_video_dmi_promote_vendor(void);
-extern int acpi_video_backlight_support(void);
-
-#else
-
-static inline void acpi_video_dmi_promote_vendor(void)
-{
-}
-
-static inline int acpi_video_backlight_support(void)
-{
- return 0;
-}
-
-#endif /* defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE) */
-
extern int acpi_blacklisted(void);
extern void acpi_dmi_osi_linux(int enable, const struct dmi_system_id *d);
extern void acpi_osi_setup(char *str);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/32] acer-wmi: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple ls /sys/class/backlight suffices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/acer-wmi.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 3ac29a1..f6b280d 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -2246,14 +2246,10 @@ static int __init acer_wmi_init(void)
set_quirks();
if (dmi_check_system(video_vendor_dmi_table))
- acpi_video_dmi_promote_vendor();
- if (acpi_video_backlight_support()) {
+ acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
+
+ if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
interface-capability = ~ACER_CAP_BRIGHTNESS;
- pr_info(Brightness must be controlled by acpi video driver\n);
- } else {
- pr_info(Disabling ACPI video driver\n);
- acpi_video_unregister_backlight();
- }
if (wmi_has_guid(WMID_GUID3)) {
if (ec_raw_mode) {
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/32] intel-oaktrail: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple ls /sys/class/backlight suffices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/intel_oaktrail.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/intel_oaktrail.c
b/drivers/platform/x86/intel_oaktrail.c
index 8037c8b..6aa33c4 100644
--- a/drivers/platform/x86/intel_oaktrail.c
+++ b/drivers/platform/x86/intel_oaktrail.c
@@ -50,6 +50,7 @@
#include linux/platform_device.h
#include linux/dmi.h
#include linux/rfkill.h
+#include acpi/video.h
#define DRIVER_NAMEintel_oaktrail
#define DRIVER_VERSION 0.4ac1
@@ -343,13 +344,11 @@ static int __init oaktrail_init(void)
goto err_device_add;
}
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
ret = oaktrail_backlight_init();
if (ret)
goto err_backlight;
-
- } else
- pr_info(Backlight controlled by ACPI video driver\n);
+ }
ret = oaktrail_rfkill_init();
if (ret) {
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/32] asus-wmi: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple ls /sys/class/backlight suffices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-wmi.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 945145d..6f8558f 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1364,7 +1364,7 @@ static void asus_wmi_notify(u32 value, void *context)
code = ASUS_WMI_BRN_DOWN;
if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
asus_wmi_backlight_notify(asus, orig_code);
goto exit;
}
@@ -1772,17 +1772,16 @@ static int asus_wmi_add(struct platform_device *pdev)
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type !strcmp(chassis_type, 3))
- acpi_video_dmi_promote_vendor();
+ acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
+
if (asus-driver-quirks-wmi_backlight_power)
- acpi_video_dmi_promote_vendor();
- if (!acpi_video_backlight_support()) {
- pr_info(Disabling ACPI video driver\n);
- acpi_video_unregister_backlight();
+ acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
+
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
err = asus_wmi_backlight_init(asus);
if (err err != -ENODEV)
goto fail_backlight;
- } else
- pr_info(Backlight controlled by ACPI video driver\n);
+ }
status = wmi_install_notify_handler(asus-driver-event_guid,
asus_wmi_notify, asus);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/32] dell-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface selection API. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/platform/x86/dell-laptop.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c index d688d80..db2e031 100644 --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -31,6 +31,7 @@ #include linux/slab.h #include linux/debugfs.h #include linux/seq_file.h +#include acpi/video.h #include ../../firmware/dcdbas.h #define BRIGHTNESS_TOKEN 0x7d @@ -1921,10 +1922,7 @@ static int __init dell_init(void) dell_debugfs_fops); #ifdef CONFIG_ACPI - /* In the event of an ACPI backlight being available, don't -* register the platform controller. -*/ - if (acpi_video_backlight_support()) + if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return 0; #endif -- 2.4.2 -- To unsubscribe from this list: send the line unsubscribe platform-driver-x86 in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/32] asus-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple ls /sys/class/backlight suffices.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/asus-laptop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 46b2746..58d29c4 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -54,6 +54,7 @@
#include linux/slab.h
#include linux/dmi.h
#include linux/acpi.h
+#include acpi/video.h
#define ASUS_LAPTOP_VERSION0.42
@@ -1884,12 +1885,11 @@ static int asus_acpi_add(struct acpi_device *device)
if (result)
goto fail_platform;
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
result = asus_backlight_init(asus);
if (result)
goto fail_backlight;
- } else
- pr_info(Backlight controlled by ACPI video driver\n);
+ }
result = asus_input_init(asus);
if (result)
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/32] acpi-video: Move backlight notifier to video_detect.c
Move the unregistering of the acpi backlight interface on registering of a
native backlight from video.c to video_detect.c where it belongs.
Note this removes support for re-registering the acpi backlight interface
when the native interface goes away. In practice this never happens and
it needlessly complicates the code.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c| 59 ++---
drivers/acpi/video_detect.c | 27 +
2 files changed, 29 insertions(+), 57 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1bbe9b1..f5ffac9 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -84,6 +84,7 @@ static struct list_head video_bus_head;
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+void acpi_video_detect_exit(void);
static const struct acpi_device_id video_device_ids[] = {
{ACPI_VIDEO_HID, 0},
@@ -143,7 +144,6 @@ struct acpi_video_enumerated_device {
struct acpi_video_bus {
struct acpi_device *device;
bool backlight_registered;
- bool backlight_notifier_registered;
u8 dos_setting;
struct acpi_video_enumerated_device *attached_array;
u8 attached_count;
@@ -156,7 +156,6 @@ struct acpi_video_bus {
struct input_dev *input;
char phys[32]; /* for input device */
struct notifier_block pm_nb;
- struct notifier_block backlight_nb;
};
struct acpi_video_device_flags {
@@ -1781,59 +1780,6 @@ static void acpi_video_bus_remove_notify_handler(struct
acpi_video_bus *video)
video-input = NULL;
}
-static int acpi_video_backlight_notify(struct notifier_block *nb,
- unsigned long val, void *bd)
-{
- struct backlight_device *backlight = bd;
- struct acpi_video_bus *video;
- enum acpi_backlight_type type;
-
- /* A raw bl (un)registering may change native - video */
- if (backlight-props.type != BACKLIGHT_RAW)
- return NOTIFY_DONE;
-
- video = container_of(nb, struct acpi_video_bus, backlight_nb);
- type = acpi_video_get_backlight_type();
-
- switch (val) {
- case BACKLIGHT_REGISTERED:
- if (type != acpi_backlight_video)
- acpi_video_bus_unregister_backlight(video);
- break;
- case BACKLIGHT_UNREGISTERED:
- if (type == acpi_backlight_video)
- acpi_video_bus_register_backlight(video);
- break;
- }
-
- return NOTIFY_OK;
-}
-
-static int acpi_video_bus_add_backlight_notify_handler(
- struct acpi_video_bus *video)
-{
- int error;
-
- video-backlight_nb.notifier_call = acpi_video_backlight_notify;
- video-backlight_nb.priority = 0;
- error = backlight_register_notifier(video-backlight_nb);
- if (error == 0)
- video-backlight_notifier_registered = true;
-
- return error;
-}
-
-static int acpi_video_bus_remove_backlight_notify_handler(
- struct acpi_video_bus *video)
-{
- if (!video-backlight_notifier_registered)
- return 0;
-
- video-backlight_notifier_registered = false;
-
- return backlight_unregister_notifier(video-backlight_nb);
-}
-
static int acpi_video_bus_put_devices(struct acpi_video_bus *video)
{
struct acpi_video_device *dev, *next;
@@ -1915,7 +1861,6 @@ static int acpi_video_bus_add(struct acpi_device *device)
acpi_video_bus_register_backlight(video);
acpi_video_bus_add_notify_handler(video);
- acpi_video_bus_add_backlight_notify_handler(video);
return 0;
@@ -1939,7 +1884,6 @@ static int acpi_video_bus_remove(struct acpi_device
*device)
video = acpi_driver_data(device);
- acpi_video_bus_remove_backlight_notify_handler(video);
acpi_video_bus_remove_notify_handler(video);
acpi_video_bus_unregister_backlight(video);
acpi_video_bus_put_devices(video);
@@ -2075,6 +2019,7 @@ static int __init acpi_video_init(void)
static void __exit acpi_video_exit(void)
{
+ acpi_video_detect_exit();
acpi_video_unregister();
return;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index c6b5951..4989ba6 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -36,6 +36,9 @@
ACPI_MODULE_NAME(video);
#define _COMPONENT ACPI_VIDEO_COMPONENT
+static bool backlight_notifier_registered;
+static struct notifier_block backlight_nb;
+
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -261,6 +264,20 @@ static
[PATCH 18/32] compal-laptop: Port to new backlight interface selection API
Port the backlight selection logic to the new backlight interface
selection API.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/platform/x86/compal-laptop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/compal-laptop.c
b/drivers/platform/x86/compal-laptop.c
index b4e9447..f2706d2 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -82,7 +82,7 @@
#include linux/hwmon-sysfs.h
#include linux/power_supply.h
#include linux/fb.h
-
+#include acpi/video.h
/* === */
/* Defines */
@@ -959,7 +959,7 @@ static int __init compal_init(void)
return -ENODEV;
}
- if (!acpi_video_backlight_support()) {
+ if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
struct backlight_properties props;
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_PLATFORM;
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/32] acpi-video: Fix acpi_video _register vs _unregister_backlight race
It is possible for a native backlight driver to load while
acpi_video_register is running, which may lead to
acpi_video_unregister_backlight being called while acpi_video_register
is running and the 2 racing against eachother.
The register_count variable protects against this, but not in a thread
safe manner, this commit adds locking to make this thread safe.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/acpi/video.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index b8053a8..fcc7c2e 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -79,6 +79,7 @@ static bool allow_duplicates;
module_param(allow_duplicates, bool, 0644);
static int register_count;
+static DEFINE_MUTEX(register_count_mutex);
static struct mutex video_list_lock;
static struct list_head video_bus_head;
static int acpi_video_bus_add(struct acpi_device *device);
@@ -1931,14 +1932,15 @@ static int __init intel_opregion_present(void)
int acpi_video_register(void)
{
- int ret;
+ int ret = 0;
+ mutex_lock(register_count_mutex);
if (register_count) {
/*
* if the function of acpi_video_register is already called,
* don't register the acpi_vide_bus again and return no error.
*/
- return 0;
+ goto leave;
}
mutex_init(video_list_lock);
@@ -1948,7 +1950,7 @@ int acpi_video_register(void)
ret = acpi_bus_register_driver(acpi_video_bus);
if (ret)
- return ret;
+ goto leave;
/*
* When the acpi_video_bus is loaded successfully, increase
@@ -1956,24 +1958,20 @@ int acpi_video_register(void)
*/
register_count = 1;
- return 0;
+leave:
+ mutex_unlock(register_count_mutex);
+ return ret;
}
EXPORT_SYMBOL(acpi_video_register);
void acpi_video_unregister(void)
{
- if (!register_count) {
- /*
-* If the acpi video bus is already unloaded, don't
-* unload it again and return directly.
-*/
- return;
+ mutex_lock(register_count_mutex);
+ if (register_count) {
+ acpi_bus_unregister_driver(acpi_video_bus);
+ register_count = 0;
}
- acpi_bus_unregister_driver(acpi_video_bus);
-
- register_count = 0;
-
- return;
+ mutex_unlock(register_count_mutex);
}
EXPORT_SYMBOL(acpi_video_unregister);
@@ -1981,13 +1979,14 @@ void acpi_video_unregister_backlight(void)
{
struct acpi_video_bus *video;
- if (!register_count)
- return;
-
- mutex_lock(video_list_lock);
- list_for_each_entry(video, video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(video_list_lock);
+ mutex_lock(register_count_mutex);
+ if (register_count) {
+ mutex_lock(video_list_lock);
+ list_for_each_entry(video, video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(video_list_lock);
+ }
+ mutex_unlock(register_count_mutex);
}
EXPORT_SYMBOL(acpi_video_unregister_backlight);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe platform-driver-x86
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
