Re: Looking for some pointers on WMI/EC access
On Thu, Apr 22, 2010 at 3:53 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Apr 22, 2010 at 03:50:19PM +0200, Florian Echtler wrote: I also think so in general, but in this case, the entire notification setup looks like an incredible mess to me. In any other case, I wouldn't really bother with the hotkeys, but as this is a tablet PC, the hotkeys on the screen side become really important all of a sudden... Yeah. I'll take a look and see if there's anything obvious. It may be linked VPC0._CFG .. -- Corentin Chary http://xf.iksaif.net -- 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] asus-laptop: return proper error for store_ledd if write_acpi_int fail
On Thu, Jul 8, 2010 at 7:55 AM, Axel Lin axel@gmail.com wrote:
In current implementation, store_ledd() does not return error if
write_acpi_int
fail.
This patch fixes it by return -ENODEV if write_acpi_int fail.
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/platform/x86/asus-laptop.c | 7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 93487eb..975751d 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -796,10 +796,11 @@ static ssize_t store_ledd(struct device *dev, struct
device_attribute *attr,
rv = parse_arg(buf, count, value);
if (rv 0) {
- if (write_acpi_int(asus-handle, METHOD_LEDD, value))
+ if (write_acpi_int(asus-handle, METHOD_LEDD, value)) {
pr_warning(LED display write failed\n);
- else
- asus-ledd_status = (u32) value;
+ return -ENODEV;
+ }
+ asus-ledd_status = (u32) value;
}
return rv;
}
--
1.5.4.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
Thanks !
Acked-by: Corentin Chary corenti...@iksaif.net
--
Corentin Chary
http://xf.iksaif.net
--
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 for toshiba_acpi driver : add illumination support
Of course, if this is not the right procedure or the right place, please correct me. Hi Pierre, Please read Documentation/SubmittingPatches. The quick version is to use git and do: $ git config user.name name $ git config user.mail mail $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git $ hack $ git commit -sa $ git format-patch origin -o /tmp/patchs/ $ ./scripts/get_maintainer.pl /tmp/patchs/* $ ./scripts/checkpatch.pl /tmp/patchs/* $ git send-email --to=main mailing list -cc=maintainter0 -cc=maintainer1 Thanks -- Corentin Chary http://xf.iksaif.net -- 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] Add support for Toshiba Illumination. This is a set of LEDs installed on some Toshiba laptops. It is controlled through ACPI, the commands has been found through reverse engineering. It
)
acpi_remove_notify_handler(toshiba_acpi.handle, ACPI_DEVICE_NOTIFY,
toshiba_acpi_notify);
+ if (toshiba_acpi.illumination_installed)
+ led_classdev_unregister(toshiba_led);
+
platform_device_unregister(toshiba_acpi.p_dev);
return;
@@ -1013,6 +1123,13 @@ static int __init toshiba_acpi_init(void)
}
}
+ toshiba_acpi.illumination_installed = 0;
+ if (toshiba_illumination_available()) {
+ if (!led_classdev_register((toshiba_acpi.p_dev-dev),
+ toshiba_led))
+ toshiba_acpi.illumination_installed = 1;
+ }
+
return 0;
}
--
1.7.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
--
Corentin Chary
http://xf.iksaif.net
--
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] Lenovo IdeaPAD ACPI driver
++) {
+ if (!devs_present[i])
+ continue;
+
+ ideapad_register_rfkill(device, i);
+ }
+ ideapad_sync_rfk_state();
+ return 0;
+}
+
+static int ideapad_acpi_remove(struct acpi_device *device, int type)
+{
+ int i;
+ device_remove_file(device-dev, dev_attr_camera_power);
+ for (i = 0; i 5; i++)
+ ideapad_unregister_rfkill(i);
+ return 0;
+}
+
+static void ideapad_acpi_notify(struct acpi_device *device, u32 event)
+{
+ ideapad_sync_rfk_state();
+}
+
+static struct acpi_driver ideapad_acpi_driver = {
+ .name = ideapad_acpi,
+ .class = IdeaPad,
+ .ids = ideapad_device_ids,
+ .ops.add = ideapad_acpi_add,
+ .ops.remove = ideapad_acpi_remove,
+ .ops.notify = ideapad_acpi_notify,
+ .owner = THIS_MODULE,
+};
+
+
+static int __init ideapad_acpi_module_init(void)
+{
+ acpi_bus_register_driver(ideapad_acpi_driver);
+
+ return 0;
+}
+
+
+static void ideapad_acpi_module_exit(void)
+{
+ acpi_bus_unregister_driver(ideapad_acpi_driver);
+
+}
+/* Support only the S10-3 for now, until we verify other models */
+MODULE_ALIAS(dmi:bvnLENOVO*:pnS10-3:*);
+
+MODULE_AUTHOR(David Woodhouse dw...@infradead.org);
+MODULE_DESCRIPTION(IdeaPad ACPI Extras);
+MODULE_LICENSE(GPL);
+
+module_init(ideapad_acpi_module_init);
+module_exit(ideapad_acpi_module_exit);
--
1.7.2.1
Also, it would be great not to use the there will only be one of
these device anti-pattern.
Of course, it will work, but I think it's better to get a clean,
fully-reentrant driver.
--
Corentin Chary
http://xf.iksaif.net
--
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] Lenovo IdeaPAD ACPI driver
On Wed, Aug 11, 2010 at 3:39 PM, David Woodhouse dw...@infradead.org wrote:
On Wed, 2010-08-11 at 14:59 +0200, Corentin Chary wrote:
I'd suggest to name it ideapad-laptop (IDEAPAD_LAPTOP). We try to use
that name for laptop related drivers.
OK.
But ... new WMI drivers are named with the *-wmi suffix. So I'm not
really sure. Anyway, it's not really important.
It doesn't do any WMI stuff... yet. I was looking at your discussion
from April and hoping you'd help make it work...
I'd suggest you to read http://lwn.net/Articles/391230/ :)
What's DEV_KILLSW ? a global kill switch ?
Yes, that's a physical switch on the side of the laptop which
automatically kills all of wifi, bluetooth and 3g.
+static struct rfkill *ideapad_rfkill[5];
+
+static const char *ideapad_rfk_names[] = {
+ ideapad_camera, ideapad_wlan, ideapad_bluetooth,
ideapad_3g, ideapad_rfkill
+};
Hum, ideapad_camera inside rfkill stuff ?
Element zero of the array doesn't get used. It was that or add a bunch
of '-1' in various places. I am entirely unconvinced which I like least.
It's the same for the types:
+static const int ideapad_rfk_types[] = {
+ 0, RFKILL_TYPE_WLAN, RFKILL_TYPE_BLUETOOTH, RFKILL_TYPE_WWAN,
RFKILL_TYPE_WLAN
+};
...
+static ssize_t store_ideapad_cam(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int ret, state;
+
+ if (!count)
+ return 0;
+ if (sscanf(buf, %i, state) != 1)
+ return -EINVAL;
+ ret = ideapad_dev_set_state(IDEAPAD_DEV_CAMERA, state);
What does it do with values other than 1 and 0 ? maybe you could send
!!state instead
I could do. The ACPI code does so for itself anyway:
If (Arg1)
{
Store (0x01, Local1)
}
Else
{
Store (0x00, Local1)
}
Also, it would be great not to use the there will only be one of
these device anti-pattern.
Of course, it will work, but I think it's better to get a clean,
fully-reentrant driver.
Agreed. Will fix.
Alan did a great work on that for eeepc-laptop, and the new eeepc-wmi
should be clean.
You can take a look a these.
And you should probably make it a platform driver (being the parent of
acpi, wmi, input, backlight, rfkill, etc..).
Is there a lot of thing hidden in ACPI / WMI on these models (like
hotkeys, backlight, light sensors) ?
Thanks,
--
Corentin Chary
http://xf.iksaif.net
--
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/3] asus-laptop: Add key found on Asus N61JQ
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-laptop.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index ffab9b4..27298a4 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -278,6 +278,7 @@ static const struct key_entry asus_keymap[] = {
{KE_KEY, 0x99, { KEY_PHONE } },
{KE_KEY, 0xc4, { KEY_KBDILLUMUP } },
{KE_KEY, 0xc5, { KEY_KBDILLUMDOWN } },
+ {KE_KEY, 0xb5, { KEY_CALC } },
{KE_END, 0},
};
--
1.7.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
Re: [PATCH] asus-laptop: remove no longer used keycode_map field
On Wed, Aug 25, 2010 at 4:45 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
The driver uses sparse keymap library and does not use this field
anymore.
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/platform/x86/asus-laptop.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index b756e07..56e162b 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -236,7 +236,6 @@ struct asus_laptop {
u8 light_level; /* light sensor level */
u8 light_switch; /* light sensor switch value */
u16 event_count[128]; /* count for each event TODO make this better
*/
- u16 *keycode_map;
};
static const struct key_entry asus_keymap[] = {
--
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
Acked-by: Corentin Chary corenti...@iksaif.net
--
Corentin Chary
http://xf.iksaif.net
--
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 1/2] eeepc-wmi: add additional hotkeys
On Mon, Oct 11, 2010 at 3:48 AM, ch...@cnpbagwell.com wrote: From: Chris Bagwell ch...@cnpbagwell.com Added 4 hotkeys using same keymap values as eeepc-latop. These are mousepad toggle, resolution change, screen off, and task manager. These were tested on 1005PE and are the Fn-F3, F4, F7, and F9, respectively. Also, added a new hot key for power toggles (Fn-Space on 1005PE) and is meant to drive cpufv interface from userspace. Finally, added several keys to be ignored that are being emitted but do not mapped to any useful or documented hotkeys. This is purely cosmetic to prevent uknown key reports on console/log files. These keys are reported on 1005PE's. What are exactly these keys ? Since they are probably some obscure Fn+ combo, and they are probably used on another model, I'm not sure we should hide them. I'm still not happy with F13 for disable touchpad but I did the same for other laptops, and we don't have a key for that ATM. Otherwise, looks good. -- 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 cpufv sysfs interface
On Mon, Oct 11, 2010 at 3:48 AM, ch...@cnpbagwell.com wrote:
From: Chris Bagwell ch...@cnpbagwell.com
eeepc-laptop provides a sysfs interface to read and control what it
calls cpufv. When WMI is enabled, the ACPI interface changes slightly
and becames a write-only control with only 3 valid values.
Write-only is OK because same DSDT's will ignore duplicate values
and even invalid values will be treated same as 0 value.
Expose cpufv again to allow for user space utils that can extended battery
life noticably and come a little closer to parity with eeepc-laptop.
This was tested with EEE PC 1005PE by monitoring powertop output while
writing values of 0, 1, and 2 and by reviewing the decompiled DSDT of
an 1201NL and comparing it to 1005PE's DSDT.
Signed-off-by: Chris Bagwell ch...@cnpbagwell.com
---
drivers/platform/x86/eeepc-wmi.c | 51
++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c
b/drivers/platform/x86/eeepc-wmi.c
index 441b000..988b16c 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -57,6 +57,7 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_METHODID_DEVS 0x53564544
#define EEEPC_WMI_METHODID_DSTS 0x53544344
+#define EEEPC_WMI_METHODID_CFVS 0x53564643
#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
@@ -307,6 +308,49 @@ static void eeepc_wmi_notify(u32 value, void *context)
kfree(obj);
}
+static int store_cpufv(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ int value;
+ struct acpi_buffer input = { (acpi_size)sizeof(value), value };
+ acpi_status status;
+
+ if (!count || sscanf(buf, %i, value) != 1)
+ return -EINVAL;
+ if (value 0 || value 2)
+ return -EINVAL;
+
+ status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
+ 1, EEEPC_WMI_METHODID_CFVS, input,
NULL);
+
+ if (ACPI_FAILURE(status))
+ return -EIO;
+ else
+ return count;
+}
+
+static DEVICE_ATTR(cpufv, S_IRUGO | S_IWUSR, NULL, store_cpufv);
+
+static void eeepc_wmi_sysfs_exit(struct platform_device *device)
+{
+ device_remove_file(device-dev, dev_attr_cpufv);
+}
+
+static int eeepc_wmi_sysfs_init(struct platform_device *device)
+{
+ int retval = -ENOMEM;
+
+ retval = device_create_file(device-dev, dev_attr_cpufv);
+ if (retval)
+ goto error_sysfs;
+
+ return 0;
+
+error_sysfs:
+ eeepc_wmi_sysfs_exit(platform_device);
+ return retval;
+}
+
static int __devinit eeepc_wmi_platform_probe(struct platform_device *device)
{
struct eeepc_wmi *eeepc;
@@ -402,8 +446,14 @@ static int __init eeepc_wmi_init(void)
goto del_dev;
}
+ err = eeepc_wmi_sysfs_init(platform_device);
+ if (err)
+ goto del_sysfs;
+
return 0;
+del_sysfs:
+ eeepc_wmi_sysfs_exit(platform_device);
del_dev:
platform_device_del(platform_device);
put_dev:
@@ -418,6 +468,7 @@ static void __exit eeepc_wmi_exit(void)
{
struct eeepc_wmi *eeepc;
+ eeepc_wmi_sysfs_exit(platform_device);
eeepc = platform_get_drvdata(platform_device);
platform_driver_unregister(platform_driver);
platform_device_unregister(platform_device);
--
1.7.3.1
Seems ok, too bad they don't provide a way to guess the current
configuration and the number of available settings. Especially when
all they do is calling the old device.
--
Corentin Chary
http://xf.iksaif.net
--
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 1/2] eeepc-wmi: add additional hotkeys
On Mon, Oct 11, 2010 at 3:25 PM, Chris Bagwell ch...@cnpbagwell.com wrote: On Mon, Oct 11, 2010 at 1:26 AM, Corentin Chary corentin.ch...@gmail.com wrote: On Mon, Oct 11, 2010 at 3:48 AM, ch...@cnpbagwell.com wrote: From: Chris Bagwell ch...@cnpbagwell.com Added 4 hotkeys using same keymap values as eeepc-latop. These are mousepad toggle, resolution change, screen off, and task manager. These were tested on 1005PE and are the Fn-F3, F4, F7, and F9, respectively. Also, added a new hot key for power toggles (Fn-Space on 1005PE) and is meant to drive cpufv interface from userspace. Finally, added several keys to be ignored that are being emitted but do not mapped to any useful or documented hotkeys. This is purely cosmetic to prevent uknown key reports on console/log files. These keys are reported on 1005PE's. What are exactly these keys ? Since they are probably some obscure Fn+ combo, and they are probably used on another model, I'm not sure we should hide them. They are Fn-1, 2, s, d, f, and e. I can't really guess what 1 and 2 are for but I assume sdfe are arrow keys or something similar on larger models? I debated on if to add ignores since surely some model uses them but I settled on someone else can modify current file instead of adding new lines once they are driven to add their laptop specific keys. I'm still not happy with F13 for disable touchpad but I did the same for other laptops, and we don't have a key for that ATM. And user land doesn't seem very supported of this concept at the moment as well. I've tried some xinput stuff on touchpad tied to F13 but no luck so far. It does have a property to disable touchpad but I've not had time to fully debug yet. I'm trying to stay away fo synclient since thats end-of-lifed. Otherwise, looks good. Thanks. BTW, please let me know specifically if you'd like the ignore keys removed and I'll re-send a patch. I don't have enough info to be able to map them though. I'd remove them, and wait for someone to complain that he has garbage in dmesg or unmapped keys. -- Corentin Chary http://xf.iksaif.net -- 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/3] Support enable Acer Launch Manager mode
On Mon, Oct 18, 2010 at 10:14 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Mon, Oct 18, 2010 at 09:55:57AM +0200, Corentin Chary wrote: On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho car...@strangeworlds.co.uk wrote: On Monday 18 October 2010 03:32:22 Joey Lee wrote: So, we choice remove rfkill-input then put the logic in x86/platform driver? A simple question: Userland policy daemon or kernel module, which one we want to put the wifi hotkey behavior implementation? Pass. I really have no opinion on the above, as long as we pick something and stick with it (i.e. not-another-rfkill-rewrite). We don't have Launch Manager for Linux, and quite frankly, I hope we never see it - relying on random, vendor specific applications to drive this kind of functionality is just asking for trouble. Acer BIOS team provide the function to OS for disable the EC hehavior, it's available on window, why we hide it on Linux? As an aside, just because Windows does something is not a good reason to do it or expose on on Linux if it doesn't make any sense. Either userland daemon or kernel module who want to implement the wifi hotkey behavior, it need enable the launch-manager mode to disable the default EC behavior on wifi hotkey. When did Acer laptops start doing this then? The behaviour they always did in the past was that pressing the wireless/ bluetooth/ 3G button sent out a scancode, and is was then the job of something else to catch that (be it rfkill-input or friends) and for that something else to then toggle the state. Do the current batch of laptops then just 'magically' toggle the state without needing rfkill-input? (And do you actually have contact with someone on the Acer BIOS team? Because I've never managed to get through to anyone at Acer, so would be interested to know). If don't want provide the launch-manager mode parameter to userland, can we just direct enable it? Well, my point is more that we should figure out what we want, and then stick with that. I don't want to add a pointless module paramater that all of three people are ever going to use, and then have to support it working both ways. -Carlos asus-laptop laptop also has that kind of parameter, but mainly because the behavior of the toggle key is quite random across models. So we need to set it sometimes. Why sometimes? The parameter we're talking about is wapf, it's directly linked to WAPF in the dsdt. WAPF is a bitmask used to control the behavior of the toggle key. It can: control the device, control the leds, send key codes. Here is some doc about what we found on wapf: https://dev.iksaif.net/projects/acpi4asus/wiki/Asus-laptop_WAPF By default, we currently write 1 into wapf, because this is the value that works correctly most of the time. But on some models, the key won't do anything if you don't set the correct value of wapf. On windows, the hotk acpi driver (from asus) also sets WAPF, but if seems to do some hardware check to guess the value to use ... Then it also handles events, and do actions (toggle wlan devices, etc...). But all the WAPF/BLED/WLED stuff on asus-laptop isn't really working properly, mainly because I lacks documentation, and the behavior seems to be dependent of present hardware (wlan cards mainly). Anyway, I think it's a good thing to have the choice between handled by hardware/BIOS and handled by kernel/userspace, as long as the default choice is coherent and always works correctly. No, I disagree. Why would you want to have this choice and have to maintain it if we already have mechanisms to do it either in kernel or in userspace. Most of users will want the key to just toggle wlan/bluetooth. But some of them will be happy if they can configure the behavior of the key (cycle, only toggle WLAN, etc...) Right. And as of today by default kernel will do simple toggle but there is an option for userspace component. Why do we want to bing BIOS into the picture? Because we should consider the BIOS as a fallback method (that may or may not work). If a newer model comes out, and the kernel/userspace doesn't know how to handle it, users will be able to use the BIOS while the driver is being fixed. -- Corentin Chary http://xf.iksaif.net -- 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/3] Support enable Acer Launch Manager mode
On Tue, Oct 19, 2010 at 11:55 AM, Joey Lee j...@novell.com wrote: Hi Corentin, 於 一，2010-10-18 於 09:55 +0200，Corentin Chary 提到： On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho car...@strangeworlds.co.uk wrote: On Monday 18 October 2010 03:32:22 Joey Lee wrote: So, we choice remove rfkill-input then put the logic in x86/platform driver? A simple question: Userland policy daemon or kernel module, which one we want to put the wifi hotkey behavior implementation? Pass. I really have no opinion on the above, as long as we pick something and stick with it (i.e. not-another-rfkill-rewrite). We don't have Launch Manager for Linux, and quite frankly, I hope we never see it - relying on random, vendor specific applications to drive this kind of functionality is just asking for trouble. Acer BIOS team provide the function to OS for disable the EC hehavior, it's available on window, why we hide it on Linux? As an aside, just because Windows does something is not a good reason to do it or expose on on Linux if it doesn't make any sense. Either userland daemon or kernel module who want to implement the wifi hotkey behavior, it need enable the launch-manager mode to disable the default EC behavior on wifi hotkey. When did Acer laptops start doing this then? The behaviour they always did in the past was that pressing the wireless/ bluetooth/ 3G button sent out a scancode, and is was then the job of something else to catch that (be it rfkill-input or friends) and for that something else to then toggle the state. Do the current batch of laptops then just 'magically' toggle the state without needing rfkill-input? (And do you actually have contact with someone on the Acer BIOS team? Because I've never managed to get through to anyone at Acer, so would be interested to know). If don't want provide the launch-manager mode parameter to userland, can we just direct enable it? Well, my point is more that we should figure out what we want, and then stick with that. I don't want to add a pointless module paramater that all of three people are ever going to use, and then have to support it working both ways. -Carlos asus-laptop laptop also has that kind of parameter, but mainly because the behavior of the toggle key is quite random across models. So we need to set it sometimes. Anyway, I think it's a good thing to have the choice between handled by hardware/BIOS and handled by kernel/userspace, as long as the default choice is coherent and always works correctly. I didn't see a good mechanism that was provided by Acer or MSI BIOS to set the wifi key behavior like you said in Asus BIOS. Their EC just control the RF switch follow a default priority, like: wlan on, bt on, 3G on wlan on, bt off, 3G off ... wlan off, bt off, 3G off The logic is not fully the same with different hardware model. And, As I know, on Windows, they sometimes also disable the default behavior because they have something like hotkey manager or launch manager to handle it. Most of users will want the key to just toggle wlan/bluetooth. But some of them will be happy if they can configure the behavior of the key (cycle, only toggle WLAN, etc...) I thought just direct disable the default EC behavior then leave a userland daemon to control the behavior, it will grab the wifi key event then control rfkill state by follow user's customization rules. What I'm saying is: I don't really care what's the default behavior is, but if the EC provide a somewhat reliable way to make the key work without any userspace daemon involved, I think we should allow the user to use this mode (even if it's with an obscure module parameter or sysfs file). But .. maybe if someone want this default raw behavior, he should just not load this module. -- Corentin Chary http://xf.iksaif.net -- 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/3] Support enable Acer Launch Manager mode
On Tue, Oct 19, 2010 at 1:15 PM, Joey Lee j...@novell.com wrote: Hi Corentin, 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到： Most of users will want the key to just toggle wlan/bluetooth. But some of them will be happy if they can configure the behavior of the key (cycle, only toggle WLAN, etc...) I thought just direct disable the default EC behavior then leave a userland daemon to control the behavior, it will grab the wifi key event then control rfkill state by follow user's customization rules. What I'm saying is: I don't really care what's the default behavior is, but if the EC provide a somewhat reliable way to make the key work without any userspace daemon involved, I think we should allow the user to use this mode (even if it's with an obscure module parameter or sysfs file). But .. maybe if someone want this default raw behavior, he should just not load this module. Fully understood, now. Like you siad, we need define a policy for: - If user want the default raw behavior, what do they need to do? I thought if the wmi driver doesn't load by default, then user will get a raw behavior. - If any distro want provide userland solution, how can they disable the default raw behavior? If anybody want to disable the raw behavior, just load the wmi driver. Does it right? Yeah, seems to be ok... -- Corentin Chary http://xf.iksaif.net -- 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 1/2] eeepc-wmi: add additional hotkeys
On Tue, Oct 12, 2010 at 1:47 AM, ch...@cnpbagwell.com wrote:
From: Chris Bagwell ch...@cnpbagwell.com
Added 4 hotkeys using same keymap values as eeepc-latop.
These are mousepad toggle, resolution change, screen off,
and task manager. These were tested on 1005PE and are the
Fn-F3, F4, F7, and F9, respectively.
Also, added a new hot key for power toggles (Fn-Space on 1005PE)
and is meant to drive cpufv interface from userspace.
Signed-off-by: Chris Bagwell ch...@cnpbagwell.com
---
drivers/platform/x86/eeepc-wmi.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c
b/drivers/platform/x86/eeepc-wmi.c
index 9dc50fb..21df266 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -69,6 +69,11 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_IGNORE, NOTIFY_BRNDOWN_MIN, { KEY_BRIGHTNESSDOWN } },
{ KE_IGNORE, NOTIFY_BRNUP_MIN, { KEY_BRIGHTNESSUP } },
{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
+ { KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
+ { KE_KEY, 0xe1, { KEY_F14 } },
+ { KE_KEY, 0xe9, { KEY_DISPLAY_OFF } },
+ { KE_KEY, 0xe0, { KEY_PROG1 } },
+ { KE_KEY, 0x5c, { KEY_F15 } },
{ KE_END, 0},
};
--
1.7.3.1
Reviewed-by: Corentin Chary corenti...@iksaif.net
Matthew, could you add this patch for 2.6.37 ? Thanks.
--
Corentin Chary
http://xf.iksaif.net
--
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] eeepc-wmi: add cpufv sysfs documentation
On Tue, Oct 26, 2010 at 4:08 AM, ch...@cnpbagwell.com wrote: From: Chris Bagwell ch...@cnpbagwell.com Based on cpufv text from sysfs-platform-eeepc-laptop that has almost same behavior. --- Documentation/ABI/testing/sysfs-platform-eeepc-wmi | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-eeepc-wmi diff --git a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi new file mode 100644 index 000..e4b5fef --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi @@ -0,0 +1,10 @@ +What: /sys/devices/platform/eeepc-wmi/cpufv +Date: Oct 2010 +KernelVersion: 2.6.37 +Contact: Corentin Chary corenti...@iksaif.net +Description: + Change CPU clock configuration (write-only). + There are three available clock configuration: + * 0 - Super Performance Mode + * 1 - High Performance Mode + * 2 - Power Saving Mode -- 1.7.3.1 Acked-by: Corentin Chary corenti...@iksaif.net Matthew, if it's still possible, please queue this for 2.6.37. Thanks, -- Corentin Chary http://xf.iksaif.net -- 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 1/2] eeepc-wmi: add additional hotkeys
On Sat, Nov 6, 2010 at 4:02 AM, Chris Bagwell ch...@cnpbagwell.com wrote: On Mon, Oct 11, 2010 at 12:10 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Sunday, October 10, 2010 11:26:22 pm Corentin Chary wrote: On Mon, Oct 11, 2010 at 3:48 AM, ch...@cnpbagwell.com wrote: From: Chris Bagwell ch...@cnpbagwell.com Added 4 hotkeys using same keymap values as eeepc-latop. These are mousepad toggle, resolution change, screen off, and task manager. These were tested on 1005PE and are the Fn-F3, F4, F7, and F9, respectively. Also, added a new hot key for power toggles (Fn-Space on 1005PE) and is meant to drive cpufv interface from userspace. Finally, added several keys to be ignored that are being emitted but do not mapped to any useful or documented hotkeys. This is purely cosmetic to prevent uknown key reports on console/log files. These keys are reported on 1005PE's. What are exactly these keys ? Since they are probably some obscure Fn+ combo, and they are probably used on another model, I'm not sure we should hide them. I'm still not happy with F13 for disable touchpad but I did the same for other laptops, and we don't have a key for that ATM. The most sensible way would be to add one then. We just need to decide if it should be a key or a switch. Motivated by thread on linux-input Touchpad toggle mess, I changed Fn-F3(toggle touchpad) from KEY_F13 to KEY_F22 With Gnome 2.32 (Fedora 14), now magically my touchpad toggle works automagically. So I'd like to submit a patch to change both eeepc-laptop and eeepc-wmi to use KEY_F22 for toggle touchpad to get some immediate benifit. Any issues with this? Is F13 doing anything useful by default? I know in this thread and in other thread Dmitry mentioned we should make a KEY_TOUCHPAD_TOGGLE (or whatever name). I'm probably just smart enough to do that if preferred but don't think I'd be able to take it to the next level and get it translated to XF86XK_TouchpadToggle. Help appreciate in that area. Chris Hi Chris, Since 2.6.38 merge window should be in a long time, I think we have the time to ad new keys. Dimitry, what do you think of : KEY_TOUCHPAD_TOGGLE 248 KEY_TOUCHPAD_ON249 KEY_TOUCHPAD_OFF 250 Maybe we should keep these lower keycodes for other stuff, and use some higher ones ? Thanks, -- Corentin Chary http://xf.iksaif.net -- 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] eeepc-wmi: fix compiler warning
On Wed, Nov 3, 2010 at 7:43 PM, Chris Bagwell ch...@cnpbagwell.com wrote:
On Wed, Nov 3, 2010 at 1:14 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
This fixes the following:
CC [M] drivers/platform/x86/eeepc-wmi.o
drivers/platform/x86/eeepc-wmi.c:322: warning: initialization from
incompatible pointer type
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/platform/x86/eeepc-wmi.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c
b/drivers/platform/x86/eeepc-wmi.c
index 462ceab..0d50fbb 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -298,8 +298,8 @@ static void eeepc_wmi_notify(u32 value, void *context)
kfree(obj);
}
-static int store_cpufv(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t store_cpufv(struct device *dev, struct device_attribute
*attr,
+ const char *buf, size_t count)
{
int value;
struct acpi_buffer input = { (acpi_size)sizeof(value), value };
--
Opps. Sorry, I missed that warning. ssize_t is obviously correct return
value.
Reviewed-by: Chris Bagwell ch...@cnpbagwell.com
--
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
Just queued the same patch on my repo, I should have read the list first.
Matthew can you queue this one for next batch ?
Thanks,
--
Corentin Chary
http://xf.iksaif.net
--
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] eeepc-wmi: updates for 2.6.38
Hi, I finally got a WMI aware Eeepc on my desk, so I made a quick series to add missing features to eeepc-wmi. Theses patchs were done and tested on an Eeepc 1005PE with an updated BIOS. Thanks, Corentin Chary (10): eeepc-wmi: rework eeepc_wmi_init and eeepc_wmi_exit eeepc-wmi: add touchpad led support eeepc-wmi: add rfkill support for wlan, bluetooth and 3g eeepc-wmi: use attribute group to manage attributes eeepc-wmi: add debugfs entries eeepc-wmi: fix confusion between ctrl_param and retval eeepc-wmi: claim eeepc-wmi maintainership eeepc-wmi: remove unneeded static eeepc-laptop: add a getter for touchpad led eeepc-wmi: never load if legacy device is enabled MAINTAINERS |8 + drivers/platform/x86/Kconfig|3 + drivers/platform/x86/eeepc-laptop.c | 11 + drivers/platform/x86/eeepc-wmi.c| 609 ++ 4 files changed, 559 insertions(+), 72 deletions(-) -- 1.7.3.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/10] eeepc-wmi: add debugfs entries
eeepc-wmi/- debugfs root directory
dev_id - current dev_id
ctrl_param - current ctrl_param
devs- call DEVS(dev_id, ctrl_param) and print result
dsts- call DSTS(dev_id) and print result
DEVS and DSTS are the main functions used in eeepc-wmi, this
will allow to test new features without patching the drivers.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 170 --
1 files changed, 164 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index a70d76a..253070a 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -36,6 +36,8 @@
#include linux/backlight.h
#include linux/leds.h
#include linux/rfkill.h
+#include linux/debugfs.h
+#include linux/seq_file.h
#include linux/platform_device.h
#include acpi/acpi_bus.h
#include acpi/acpi_drivers.h
@@ -89,6 +91,19 @@ struct bios_args {
u32 ctrl_param;
};
+/*
+ * eeepc-wmi/- debugfs root directory
+ * dev_id - current dev_id
+ * ctrl_param - current ctrl_param
+ * devs- call DEVS(dev_id, ctrl_param) and print result
+ * dsts- call DSTS(dev_id) and print result
+ */
+struct eeepc_wmi_debug {
+ struct dentry *root;
+ u32 dev_id;
+ u32 ctrl_param;
+};
+
struct eeepc_wmi {
struct input_dev *inputdev;
struct backlight_device *backlight_device;
@@ -102,6 +117,8 @@ struct eeepc_wmi {
struct rfkill *wlan_rfkill;
struct rfkill *bluetooth_rfkill;
struct rfkill *wwan3g_rfkill;
+
+ struct eeepc_wmi_debug debug;
};
/* Only used in eeepc_wmi_init() and eeepc_wmi_exit() */
@@ -176,7 +193,8 @@ static acpi_status eeepc_wmi_get_devstate(u32 dev_id, u32
*ctrl_param)
}
-static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32 ctrl_param)
+static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32 ctrl_param,
+ u32 *retval)
{
struct bios_args args = {
.dev_id = dev_id,
@@ -185,8 +203,32 @@ static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32
ctrl_param)
struct acpi_buffer input = { (acpi_size)sizeof(args), args };
acpi_status status;
- status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
- 1, EEEPC_WMI_METHODID_DEVS, input, NULL);
+ if (!retval) {
+ status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID, 1,
+EEEPC_WMI_METHODID_DEVS,
+input, NULL);
+ } else {
+ struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ u32 tmp;
+
+ status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID, 1,
+EEEPC_WMI_METHODID_DEVS,
+input, output);
+
+ if (ACPI_FAILURE(status))
+ return status;
+
+ obj = (union acpi_object *)output.pointer;
+ if (obj obj-type == ACPI_TYPE_INTEGER)
+ tmp = (u32)obj-integer.value;
+ else
+ tmp = 0;
+
+ *retval = tmp;
+
+ kfree(obj);
+ }
return status;
}
@@ -208,7 +250,7 @@ static void tpd_led_update(struct work_struct *work)
eeepc = container_of(work, struct eeepc_wmi, tpd_led_work);
ctrl_param = eeepc-tpd_led_wk;
- eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_TPDLED, ctrl_param);
+ eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_TPDLED, ctrl_param, NULL);
}
static void tpd_led_set(struct led_classdev *led_cdev,
@@ -295,7 +337,7 @@ static int eeepc_rfkill_set(void *data, bool blocked)
int dev_id = (unsigned long)data;
u32 ctrl_param = !blocked;
- return eeepc_wmi_set_devstate(dev_id, ctrl_param);
+ return eeepc_wmi_set_devstate(dev_id, ctrl_param, NULL);
}
static void eeepc_rfkill_query(struct rfkill *rfkill, void *data)
@@ -434,7 +476,8 @@ static int update_bl_status(struct backlight_device *bd)
ctrl_param = bd-props.brightness;
- status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BACKLIGHT, ctrl_param);
+ status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BACKLIGHT,
+ ctrl_param, NULL);
if (ACPI_FAILURE(status))
return -1;
@@ -614,6 +657,114 @@ static void eeepc_wmi_platform_exit(struct eeepc_wmi
*eeepc)
}
/*
+ * debugfs
+ */
+struct eeepc_wmi_debugfs_node {
+ struct eeepc_wmi *eeepc;
+ char *name;
+ int (*show)(struct seq_file *m, void *data);
+};
+
+static int show_dsts(struct seq_file *m, void *data)
+{
+ struct eeepc_wmi *eeepc = m-private;
+ acpi_status status;
+ u32 retval = -1;
+
+ status
[PATCH 02/10] eeepc-wmi: add touchpad led support
Most of the code comes from eeepc-laptop.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/Kconfig |2 +
drivers/platform/x86/eeepc-wmi.c | 113 ++
2 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index faec777..1c59fef 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -426,6 +426,8 @@ config EEEPC_WMI
depends on EXPERIMENTAL
depends on BACKLIGHT_CLASS_DEVICE
select INPUT_SPARSEKMAP
+ select LEDS_CLASS
+ select NEW_LEDS
---help---
Say Y here if you want to support WMI-based hotkeys on Eee PC laptops.
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index dfbb295..f12a25d 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -34,6 +34,7 @@
#include linux/input/sparse-keymap.h
#include linux/fb.h
#include linux/backlight.h
+#include linux/leds.h
#include linux/platform_device.h
#include acpi/acpi_bus.h
#include acpi/acpi_drivers.h
@@ -60,6 +61,7 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_METHODID_CFVS0x53564643
#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
+#define EEEPC_WMI_DEVID_TPDLED 0x00100011
static const struct key_entry eeepc_wmi_keymap[] = {
/* Sleep already handled via generic ACPI code */
@@ -87,6 +89,11 @@ struct eeepc_wmi {
struct input_dev *inputdev;
struct backlight_device *backlight_device;
struct platform_device *platform_device;
+
+ struct led_classdev tpd_led;
+ int tpd_led_wk;
+ struct workqueue_struct *led_workqueue;
+ struct work_struct tpd_led_work;
};
/* Only used in eeepc_wmi_init() and eeepc_wmi_exit() */
@@ -176,6 +183,105 @@ static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32
ctrl_param)
return status;
}
+/*
+ * LEDs
+ */
+/*
+ * These functions actually update the LED's, and are called from a
+ * workqueue. By doing this as separate work rather than when the LED
+ * subsystem asks, we avoid messing with the Eeepc ACPI stuff during a
+ * potentially bad time, such as a timer interrupt.
+ */
+static void tpd_led_update(struct work_struct *work)
+{
+ int ctrl_param;
+ struct eeepc_wmi *eeepc;
+
+ eeepc = container_of(work, struct eeepc_wmi, tpd_led_work);
+
+ ctrl_param = eeepc-tpd_led_wk;
+ eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_TPDLED, ctrl_param);
+}
+
+static void tpd_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct eeepc_wmi *eeepc;
+
+ eeepc = container_of(led_cdev, struct eeepc_wmi, tpd_led);
+
+ eeepc-tpd_led_wk = !!value;
+ queue_work(eeepc-led_workqueue, eeepc-tpd_led_work);
+}
+
+static int read_tpd_state(struct eeepc_wmi *eeepc)
+{
+ static u32 ctrl_param;
+ acpi_status status;
+
+ status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_TPDLED, ctrl_param);
+
+ if (ACPI_FAILURE(status))
+ return -1;
+ else if (!ctrl_param || ctrl_param == 0x0006)
+ /*
+* if touchpad led is present, DSTS will set some bits,
+* usually 0x0002.
+* 0x0006 means that the device is not supported
+*/
+ return -ENODEV;
+ else
+ /* Status is stored in the first bit */
+ return ctrl_param 0x1;
+}
+
+static enum led_brightness tpd_led_get(struct led_classdev *led_cdev)
+{
+ struct eeepc_wmi *eeepc;
+
+ eeepc = container_of(led_cdev, struct eeepc_wmi, tpd_led);
+
+ return read_tpd_state(eeepc);
+}
+
+static int eeepc_wmi_led_init(struct eeepc_wmi *eeepc)
+{
+ int rv;
+
+ if (read_tpd_state(eeepc) 0)
+ return 0;
+
+ eeepc-led_workqueue = create_singlethread_workqueue(led_workqueue);
+ if (!eeepc-led_workqueue)
+ return -ENOMEM;
+ INIT_WORK(eeepc-tpd_led_work, tpd_led_update);
+
+ eeepc-tpd_led.name = eeepc::touchpad;
+ eeepc-tpd_led.brightness_set = tpd_led_set;
+ eeepc-tpd_led.brightness_get = tpd_led_get;
+ eeepc-tpd_led.max_brightness = 1;
+
+ rv = led_classdev_register(eeepc-platform_device-dev,
+ eeepc-tpd_led);
+ if (rv) {
+ destroy_workqueue(eeepc-led_workqueue);
+ return rv;
+ }
+
+ return 0;
+}
+
+static void eeepc_wmi_led_exit(struct eeepc_wmi *eeepc)
+{
+ if (eeepc-tpd_led.dev)
+ led_classdev_unregister(eeepc-tpd_led);
+ if (eeepc-led_workqueue)
+ destroy_workqueue(eeepc-led_workqueue);
+}
+
+/*
+ * Backlight
+ */
static int read_brightness(struct backlight_device *bd)
{
static u32 ctrl_param;
@@ -402,6 +508,10 @@ static struct platform_device * __init
[PATCH 08/10] eeepc-wmi: remove unneeded static
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 5f3f42c..52274e2 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -267,7 +267,7 @@ static void tpd_led_set(struct led_classdev *led_cdev,
static int read_tpd_state(struct eeepc_wmi *eeepc)
{
- static u32 retval;
+ u32 retval;
acpi_status status;
status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_TPDLED, retval);
@@ -458,7 +458,7 @@ exit:
*/
static int read_brightness(struct backlight_device *bd)
{
- static u32 retval;
+ u32 retval;
acpi_status status;
status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_BACKLIGHT, retval);
@@ -472,7 +472,7 @@ static int read_brightness(struct backlight_device *bd)
static int update_bl_status(struct backlight_device *bd)
{
- static u32 ctrl_param;
+ u32 ctrl_param;
acpi_status status;
ctrl_param = bd-props.brightness;
--
1.7.3.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/10] eeepc-laptop: add a getter for touchpad led
Allow te get the current led state in a more accurate way.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-laptop.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index b2edfdc..e9fc530 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -529,6 +529,15 @@ static void tpd_led_set(struct led_classdev *led_cdev,
queue_work(eeepc-led_workqueue, eeepc-tpd_led_work);
}
+static enum led_brightness tpd_led_get(struct led_classdev *led_cdev)
+{
+ struct eeepc_laptop *eeepc;
+
+ eeepc = container_of(led_cdev, struct eeepc_laptop, tpd_led);
+
+ return get_acpi(eeepc, CM_ASL_TPD);
+}
+
static int eeepc_led_init(struct eeepc_laptop *eeepc)
{
int rv;
@@ -543,6 +552,8 @@ static int eeepc_led_init(struct eeepc_laptop *eeepc)
eeepc-tpd_led.name = eeepc::touchpad;
eeepc-tpd_led.brightness_set = tpd_led_set;
+ if (get_acpi(eeepc, CM_ASL_TPD) = 0) /* if method is available */
+ eeepc-tpd_led.brightness_get = tpd_led_get;
eeepc-tpd_led.max_brightness = 1;
rv = led_classdev_register(eeepc-platform_device-dev,
--
1.7.3.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/10] eeepc-wmi: claim eeepc-wmi maintainership
Since eeepc-wmi has currently no official maintainer, I claim maintainership of this driver, and add it to the acpi4asus project. Signed-off-by: Corentin Chary corenti...@iksaif.net --- MAINTAINERS |8 drivers/platform/x86/eeepc-wmi.c |1 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b49ba9a..02a34ea 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2242,6 +2242,14 @@ W: http://acpi4asus.sf.net S: Maintained F: drivers/platform/x86/eeepc-laptop.c +EEEPC WMI EXTRAS DRIVER +M: Corentin Chary corenti...@iksaif.net +L: acpi4asus-u...@lists.sourceforge.net +L: platform-driver-x86@vger.kernel.org +W: http://acpi4asus.sf.net +S: Maintained +F: drivers/platform/x86/eeepc-wmi.c + EFIFB FRAMEBUFFER DRIVER L: linux-fb...@vger.kernel.org M: Peter Jones pjo...@redhat.com diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index 78306be..5f3f42c 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -2,6 +2,7 @@ * Eee PC WMI hotkey driver * * Copyright(C) 2010 Intel Corporation. + * Copyright(C) 2010 Corentin Chary corentin.ch...@gmail.com * * Portions based on wistron_btns.c: * Copyright (C) 2005 Miloslav Trmac m...@volny.cz -- 1.7.3.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/10] eeepc-wmi: never load if legacy device is enabled
If legacy device (SB.ATKD - ASUS010) used by eeepc-laptop
is enabled, don't allow eeepc-wmi to load because:
- eeepc-laptop may be loaded, and can conflict with
eeepc-wmi (they both try to register eeepc::touchpad
led for example).
- the WMI interface is inteded to be used when the OS is
not detected as Win 7. And when this is the case, the
ASUS010 device is disabled.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 52274e2..4d38f98 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -49,6 +49,8 @@ MODULE_AUTHOR(Yong Wang yong.y.w...@intel.com);
MODULE_DESCRIPTION(Eee PC WMI Hotkey Driver);
MODULE_LICENSE(GPL);
+#define EEEPC_ACPI_HID ASUS010 /* old _HID used in eeepc-laptop */
+
#define EEEPC_WMI_EVENT_GUID ABBC0F72-8EA1-11D1-00A0-C9062910
#define EEEPC_WMI_MGMT_GUID97845ED0-4E6D-11DE-8A39-0800200C9A66
@@ -861,6 +863,27 @@ static struct platform_driver platform_driver = {
},
};
+static acpi_status __init eeepc_wmi_parse_device(acpi_handle handle, u32 level,
+void *context, void **retval)
+{
+ pr_warning(Found legacy ATKD device (%s), EEEPC_ACPI_HID);
+ *(bool *)context = true;
+ return AE_CTRL_TERMINATE;
+}
+
+static int __init eeepc_wmi_check_atkd(void)
+{
+ acpi_status status;
+ bool found = false;
+
+ status = acpi_get_devices(EEEPC_ACPI_HID, eeepc_wmi_parse_device,
+ found, NULL);
+
+ if (ACPI_FAILURE(status) || !found)
+ return 0;
+ return -1;
+}
+
static int __init eeepc_wmi_init(void)
{
int err;
@@ -871,6 +894,16 @@ static int __init eeepc_wmi_init(void)
return -ENODEV;
}
+ if (eeepc_wmi_check_atkd()) {
+ pr_warning(WMI device present, but legacy ATKD device is also
+ present and enabled.);
+ pr_warning(You probably booted with acpi_osi=\Linux\ or
+ acpi_osi=\!Windows 2009\);
+ pr_warning(Can't load eeepc-wmi, use default acpi_osi
+ (preferred) or eeepc-laptop);
+ return -ENODEV;
+ }
+
platform_device = eeepc_wmi_add();
if (IS_ERR(platform_device)) {
err = PTR_ERR(platform_device);
--
1.7.3.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: [RFC][PATCH] New ACPI-WMI driver for shuttle machines
On Wed, Dec 1, 2010 at 5:14 PM, Herton Ronaldo Krzesinski
her...@mandriva.com.br wrote:
Hi,
I cut the message just to the comments, here we go:
On Wed, 1 Dec 2010 00:22:03 +0100
Corentin Chary corentin.ch...@gmail.com wrote:
On Tue, Nov 30, 2010 at 6:27 PM, Herton Ronaldo Krzesinski
her...@mandriva.com.br wrote:
+What: /sys/devices/platform/shuttle_wmi/brightness_up
+Date: November 2010
+KernelVersion: 2.6.37
+Contact: Herton Ronaldo Krzesinski her...@mandriva.com.br
+Description:
+ This is a write only option (accepts any single value, eg.
+ echo 1 brightness_up) that is equivalent of pressing
+ fn+brightness up function on notebooks. This option
exists
+ because of shuttle machines that are notebooks in desktop
form
+ factor, and which don't have the notebook keyboard, thus no
+ way to use fn+brightness up.
Why such files ? Can't we do the same using the backlight device ?
I use the backlight device, but also added this sysfs attribute. The reason
for it was testing, and also because the acpi video interface on Shuttle
DA18IE has a bug, if you try to set the brightness it writes the value but
brightness isn't updated on the screen. That's why also I had to made the
following workaround on backlight support without acpi video on the driver:
/* change brightness by steps, this is a quirk for shuttle
* machines which don't accept direct write to ec for this */
if (wmi_ec_cmd(CMD_READEC, 0, 0, ECRAM_ER0, val))
return -EIO;
val = 0x7;
steps = bd-props.brightness - val;
while (steps 0) {
wmi_ec_cmd(CMD_SCMD, 0, 0, 0x0c, NULL);
steps--;
}
while (steps 0) {
wmi_ec_cmd(CMD_SCMD, 0, 0, 0x0b, NULL);
steps++;
}
That is, on shuttle DA18IE, the brightness will only be effectively set if
you send the command with same code as fn+brightness, it doesn't work
writing to address 0x79 directly in EC as the firmware and my backlight
code does for the other machines. So, if you load the module with acpi
video support on, you can't change the brightness without this. If there is
an way that for Shuttle DA18IE I could disable acpi video support and always
only use the backlight class, then I can remove the sysfs attribute.
If I understand, acpi_backlight=vendor works, but acpi_backlight=video
doesn't, right ?
If there is no way to make the video module work, then you can
probably blacklist
the shuttles in drivers/acpi/video_detect.c:acpi_video_get_capabilities.
How does it work on windows ?
Shuttle DA18IE is weird because it has an hack on hardware: the LCD of the
machine is connected on the same VGA output of the machine, that is, instead
of using the LVDS port, they connect the VGA port, and because this you can't
have proper display switch on it, it works like a VGA splitter, very ugly.
This hardware may change, so may be we will not have to care any more about
this and remove both sysfs attribute and quirk, and one reason I don't send
the driver yet as final version.
+What: /sys/devices/platform/shuttle_wmi/cut_lvds
+Date: November 2010
+KernelVersion: 2.6.37
+Contact: Herton Ronaldo Krzesinski her...@mandriva.com.br
+Description:
+ This is a write only option. Writing any single non-zero
value
+ to it enables main screen output, 0 to disable.
Same, could be handled by the backlight device.
I'll remove and see to move to backlight.
See asus-laptop, it have some blank/unblank support for the backlight device.
+What: /sys/devices/platform/shuttle_wmi/lbar_brightness_down
+Date: November 2010
+KernelVersion: 2.6.37
+Contact: Herton Ronaldo Krzesinski her...@mandriva.com.br
+Description:
+ This is a write only option (accepts any single value, eg.
+ echo 1 lbar_brightness_down). Decreases one step of
lightbar
+ brightness.
+
+What: /sys/devices/platform/shuttle_wmi/lbar_brightness_up
+Date: November 2010
+KernelVersion: 2.6.37
+Contact: Herton Ronaldo Krzesinski her...@mandriva.com.br
+Description:
+ This is a write only option (accepts any single value, eg.
+ echo 1 lbar_brightness_up). Increases one step of
lightbar
+ brightness.
What is the lightbar exactly ? Some kind of led ? Can't you use the
led class instead ?
None of shuttle machines I have here have this lightbar, but it should be a
cosmetic light in the front of the machine at bottom. I don't know if it's
useful treat is as led, check this pdf:
http://www.shuttle.eu/fileadmin/resources/download/docs/spec/complete_systems/X5020XA_e.pdf
At page 6, there is a picture with the light bar, it's
Re: [PATCH 2/4] Enabled Acer Launch Manager mode
Just noticed - this function (and others similar to this in your subsequent patces) mixes acpi-style return values (acpi_status) with Linux ones (-ERRXXX). You need to pick one standard (I'd advocate Linux style) and stick with it. Thank's for your review and suggestion, I choice use acpi-style because it don't need change too much and old functions in acer-wmi also follow acpi-style. I replaced the -EINVAL with AE_ERROR, the following is new patch. If it's OK, I will modify patch 2/4 and patch 3/4 then re-send patchset again. But if you use acpi-style errors won't be able to go back to the user (errno) and userspace programs won't be able to display appropriate errors (on modprobe, manipulating sysfs files, etc...). I didn't read the code, so it may not be an issue here, but you should check that meaningful error codes are sent back to userspace. -- Corentin Chary http://xf.iksaif.net -- 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] Add WMI driver for some Megaware notebook models.
)
+{
+ struct megaware_device *megaware;
+ platform_driver_unregister(megaware_driver);
+ megaware = dev_get_drvdata(megaware_device-dev);
+ platform_device_unregister(megaware_device);
+ kfree(megaware);
+}
+
+module_init(megaware_init);
+module_exit(megaware_exit);
--
1.7.2.3
Otherwise, this looks like a clean wmi driver :)
Thanks.
--
Corentin Chary
http://xf.iksaif.net
--
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] Add WMI driver for some Megaware notebook models.
On Fri, Dec 10, 2010 at 8:31 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Fri, Dec 10, 2010 at 08:12:53AM +0100, Corentin Chary wrote: On Fri, Dec 10, 2010 at 1:08 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: .remove is still needed but I guess Corentin refers to using platform_driver_probe() instead of platform_driver_register() so the megaware_probe can be marked __init and discarded after driver initialization has been completed. Also, register won't return any error code if the probe function failed, and the driver will be left in a strange state. Calling directly platform_driver_probe() will return an error code. But since it's a singleton device, and since the real probe code is already in the module_init function (wmi_has_guid()) call, using the probe callback to initialize data structures doesn't seems to make sense. What's the other option (provided that we want to keep platform device)? Manual binding device and driver? I think platform_driver_probe() is better tested and is safer, emits all necessary uevents. etc, etc. I'd suggest platform_create_bundle() except I am not quite happy with the API at the moment (needs to also accept drvdata I think). Well, I'd suggest something like http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=blob;f=drivers/platform/x86/eeepc-wmi.c;hb=linux-next#l887 It's like platform_create_bundle, but by hand, because I didn't like the API too. Please note that I'd gladly accept any comment/patch on eeepc-wmi if you think it's not ok :). Maybe the wmi_has_guid() calls should be in the probe callback, and we should all call platform_driver_probe() ? -- Corentin Chary http://xf.iksaif.net -- 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] eeepc-wmi: fix function return type to kill warning
On Wed, Dec 15, 2010 at 1:26 AM, Randy Dunlap randy.dun...@oracle.com wrote:
From: Randy Dunlap randy.dun...@oracle.com
Fix return type warning:
drivers/platform/x86/eeepc-wmi.c:322: warning: initialization from
incompatible pointer type
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
drivers/platform/x86/eeepc-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-2637-rc4.orig/drivers/platform/x86/eeepc-wmi.c
+++ lnx-2637-rc4/drivers/platform/x86/eeepc-wmi.c
@@ -298,7 +298,7 @@ static void eeepc_wmi_notify(u32 value,
kfree(obj);
}
-static int store_cpufv(struct device *dev, struct device_attribute *attr,
+static ssize_t store_cpufv(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
int value;
Sorry, too late, :)
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=da7fddf92985c2525260dfd6f70006e022f4457c
Still, Thanks
--
Corentin Chary
http://xf.iksaif.net
--
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] platform-driver-x86: ACPI EC Extra driver for Oaktrail
);
+ return 0;
+
+err_rfkill:
+ platform_device_del(oaktrail_device);
+err_device_add:
+ platform_device_put(oaktrail_device);
+err_device_alloc:
+ platform_driver_unregister(oaktrail_driver);
+err_driver_reg:
+ return ret;
+}
+
+static void __exit oaktrail_cleanup(void)
+{
+ platform_device_unregister(oaktrail_device);
+ platform_driver_unregister(oaktrail_driver);
+ rfkill_unregister(wifi_rfkill);
+ rfkill_unregister(bt_rfkill);
+ rfkill_unregister(gps_rfkill);
+ rfkill_unregister(wwan_rfkill);
+ rfkill_destroy(wifi_rfkill);
+ rfkill_destroy(bt_rfkill);
+ rfkill_destroy(gps_rfkill);
+ rfkill_destroy(wwan_rfkill);
+
+ pr_info(Driver unloaded\n);
+}
+
+module_init(oaktrail_init);
+module_exit(oaktrail_cleanup);
+
+MODULE_AUTHOR(Yin Kangkai (kangkai@intel.com));
+MODULE_DESCRIPTION(Intel Oaktrail Platform ACPI Extras);
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE(GPL);
Maybe you could add some MODULE_ALIAS(dmi:x) lines
to enable module autoloading ?
Thanks,
--
Corentin Chary
http://xf.iksaif.net
--
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] platform-driver-x86: ACPI EC Extra driver for Oaktrail
On Thu, Jan 6, 2011 at 11:11 AM, Yin Kangkai
kangkai@linux.intel.com wrote:
On 2011-01-06, 08:29 +0100, Corentin Chary wrote:
Hi,
Thanks for the review and comments.
@@ -0,0 +1,349 @@
+/*-*-linux-c-*-*/
I don't know what's our general policy about that, but I don't think
each text editor should be allowed to add its own header on each
files. Most of the time you can configure your editor to set the
right indent style based on the path of the file or something like that.
Yes, I agree with you, will remove that.
+ * gps - GPS subsystem enabled: contains either 0 or 1. (rw)
+ * wifi - WiFi subsystem enabled: contains either 0 or 1. (rw)
+ * wwan - WWAN (3G) subsystem enabled: contains either 0 or 1. (rw)
Is there a reason do add these files in /sys/devices/platform while the
functionality is already provided by rfkill ?
Provide a alternative way to enable/disable these devices, and also
for debugging. Does that make any sense?
Maybe using debugfs then ?
+ * camera - Camera subsystem enabled: contains either 0 or 1. (rw)
+ * bluetooth - Bluetooth subsystem enabled: contains either 0 or 1. (rw)
+ * touchscreen - Touchscreen subsystem enabled: contains either 0 or 1.
(ro)
This should be in Documentation/ABI/testing/
Should I prepare the document now and submit also?
Yep, there is already one or two platform drivers documented here, you can use
them as a template.
+
+static struct platform_device *oaktrail_device;
+static struct rfkill *bt_rfkill;
+static struct rfkill *gps_rfkill;
+static struct rfkill *wifi_rfkill;
+static struct rfkill *wwan_rfkill;
Here you could create two (four ?) helpers that contains the logic,
and craft dummy functions which only call the helpers with the right
parameters in your macros.
These helpers could also be used by later functions.
I will try to define some micros..
+static int setup_rfkill(void)
oaktrail_rfkill_init() ?
Sure.
+ rfkill_destroy(wwan_rfkill);
+err_allocate_wwan:
+ rfkill_unregister(gps_rfkill);
+err_register_gps:
+ rfkill_destroy(gps_rfkill);
+err_allocate_gps:
+ rfkill_unregister(bt_rfkill);
+err_register_bt:
+ rfkill_destroy(bt_rfkill);
+err_allocate_bt:
+ rfkill_unregister(wifi_rfkill);
+err_register_wifi:
+ rfkill_destroy(wifi_rfkill);
+
+ return ret;
+}
Here I'd write an helper function to call rfkill_alloc,
rfkill_register and handle
rfkill_register failure. And then, if any of the helper calls fail, just call
oaktrail_rfkill_exit (which which rfkill if the rfkill pointer is NULL or
not).
oaktrail_rfkill_exit could also be used in the module exit function.
Yes, will try to do that.
+static int __devinit oaktrail_probe(struct platform_device *pdev)
+{
+ int err;
+
+ err = sysfs_create_group(pdev-dev.kobj,
oaktrail_attribute_group);
+ return err;
+}
return sysfs_create_group(pdev-dev.kobj, oaktrail_attribute_group);
we don't really need err right now, do we ?
Will change this.
+MODULE_AUTHOR(Yin Kangkai (kangkai@intel.com));
+MODULE_DESCRIPTION(Intel Oaktrail Platform ACPI Extras);
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE(GPL);
Maybe you could add some MODULE_ALIAS(dmi:x) lines
to enable module autoloading ?
Will try to.
Thanks for the review.
Regards,
Kangkai
--
Corentin Chary
http://xf.iksaif.net
--
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] platform-driver-x86: ACPI EC Extra driver for Oaktrail
On Fri, Jan 7, 2011 at 8:41 AM, Yin Kangkai kangkai@linux.intel.com wrote: Patch V2 Changes from V1: - remove wifi, bt, gps, wwan from /sys/devices/platform. - add some helper function for rfkill alloc and rfkill cleanup. - add MODULE_ALIAS. - add Documentation/ABI/testing/sysfs-platform-intel-oaktrail - various other minor changes. - bump driver version from 0.1 to 0.2 Thanks Corentin Chary and Joey Lee for the review. From ab28d41e89b40e0ab1d73489b7d1a9f6e745c14a Mon Sep 17 00:00:00 2001 From: Yin Kangkai kangkai@intel.com Date: Wed, 22 Dec 2010 10:53:36 +0800 Subject: [PATCH] platform-driver-x86: ACPI EC Extra driver for Oaktrail This driver implements an Extra ACPI EC driver for products based on Intel Oaktrail platform. It is programming the EC space, through existing ACPI EC driver, to provide user space layer the sysfs and rfkill interfaces to enable/disable the Camera, Bluetooth, GPS, WiFi, 3G, and to show the status of Touchscreen. Signed-off-by: Yin Kangkai kangkai@intel.com --- .../ABI/testing/sysfs-platform-intel-oaktrail | 13 + drivers/platform/x86/Kconfig | 9 + drivers/platform/x86/Makefile | 1 + drivers/platform/x86/intel_oaktrail.c | 347 4 files changed, 370 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-intel-oaktrail create mode 100644 drivers/platform/x86/intel_oaktrail.c diff --git a/Documentation/ABI/testing/sysfs-platform-intel-oaktrail b/Documentation/ABI/testing/sysfs-platform-intel-oaktrail new file mode 100644 index 000..0512235 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-intel-oaktrail @@ -0,0 +1,13 @@ +What: /sys/devices/platform/intel_oaktrail/camera +Date: Jan 2011 +KernelVersion: 2.6.37 +Contact: Yin Kangkai kangkai@intel.com +Description: + Control the camera. 1 means on, 0 means off. + +What: /sys/devices/platform/intel_oaktrail/touchscreen +Date: Jan 2011 +KernelVersion: 2.6.37 +Contact: Yin Kangkai kangkai@intel.com +Description: + Show the status of the touch screen. 1 means on, 0 means off. diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 2b4038a..d1f6981 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -655,4 +655,13 @@ config XO1_RFKILL Support for enabling/disabling the WLAN interface on the OLPC XO-1 laptop. +config INTEL_OAKTRAIL + tristate Intel Oaktrail Platform Extras + depends on ACPI + depends on RFKILL + ---help--- + Intel Oaktrail platform need this driver to provide interfaces to + enable/disable the Camera, WiFi, BT etc. devices. If in doubt, say Y + here; it will only load on supported platforms. + endif # X86_PLATFORM_DEVICES diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile index 7ff60e6..add8ab7 100644 --- a/drivers/platform/x86/Makefile +++ b/drivers/platform/x86/Makefile @@ -35,3 +35,4 @@ obj-$(CONFIG_INTEL_IPS) += intel_ips.o obj-$(CONFIG_GPIO_INTEL_PMIC) += intel_pmic_gpio.o obj-$(CONFIG_XO1_RFKILL) += xo1-rfkill.o obj-$(CONFIG_IBM_RTL) += ibm_rtl.o +obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o diff --git a/drivers/platform/x86/intel_oaktrail.c b/drivers/platform/x86/intel_oaktrail.c new file mode 100644 index 000..9ec71c5 --- /dev/null +++ b/drivers/platform/x86/intel_oaktrail.c @@ -0,0 +1,347 @@ +/* + Copyright (C) 2010 Intel Corporation + Author: Yin Kangkai (kangkai@intel.com) + + based on Compal driver + + Copyright (C) 2008 Cezary Jackiewicz cezary.jackiewicz (at) gmail.com + + based on MSI driver + + Copyright (C) 2006 Lennart Poettering mzxreary (at) 0pointer (dot) de + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + 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, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + 02110-1301, USA. + */ + +/* + * intel_oaktrail.c - Intel OakTrail Platform support. + * + * This driver exports a few files in /sys/devices/platform/intel_oaktrail/: + * + * camera - Camera subsystem enabled: contains either 0 or 1. (rw) + * touchscreen - Touchscreen subsystem enabled: contains either
Re: [PATCH 1/2] input: Pegatron Lucid accelerometer
;
+
+ ipdev-poll = pega_accel_poll;
+ ipdev-poll_interval = 100;
+ ipdev-poll_interval_min = 10;
+ ipdev-poll_interval_max = 2000;
+
+ ipdev-input-dev.parent = pd-dev;
+ ipdev-input-dev.release = dev_noop_release;
+ ipdev-input-id.bustype = BUS_HOST;
+
+ ipdev-input-name = DRIVER_DESC;
+ ipdev-input-phys = DRIVER_NAME /input0;
+
+ set_bit(EV_ABS, ipdev-input-evbit);
+ input_set_abs_params(ipdev-input, ABS_X, -CLAMP, CLAMP, 0, 0);
+ input_set_abs_params(ipdev-input, ABS_Y, -CLAMP, CLAMP, 0, 0);
+ input_set_abs_params(ipdev-input, ABS_Z, -CLAMP, CLAMP, 0, 0);
+
+ err = input_register_polled_device(ipdev);
+ if (err)
+ input_free_polled_device(ipdev);
+
+ return err;
+}
+
+static int __devexit platform_remove(struct platform_device *pd)
+{
+ input_unregister_polled_device(ipdev);
+ input_free_polled_device(ipdev);
+ ipdev = NULL;
+ return 0;
+}
+
+static struct platform_driver platform_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRIVER_NAME,
+ },
+ .probe = platform_probe,
+ .remove = __devexit_p(platform_remove),
+};
+
+static int __init mod_init(void)
+{
+ return platform_driver_register(platform_driver);
+}
+
+static void __exit mod_exit(void)
+{
+ platform_driver_unregister(platform_driver);
+}
+
+module_init(mod_init);
+module_exit(mod_exit);
+
+MODULE_AUTHOR(Andy Ross andy.r...@windriver.com);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS(dmi:*:bvrLucid-CE-133:*);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Corentin Chary
http://xf.iksaif.net
--
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
ACPI notify handler and reentrancy of WMI device.
Hi, I currently trying to fix a bug on the Eeepc 1000H with eeepc-wmi. I got an acpi notify handler. The notify is triggered when I call WMBC(). In this notify handler, I must re-call WMBC (with some other arguments, it won't notify again this time). If I do that, I'll get: [ 176.920391] ACPI Error (dswload-0802): [_T_0] Namespace lookup failure, AE_ALREADY_EXISTS [ 176.920416] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20100428/psloop-231) [ 176.920439] ACPI Error (psparse-0537): Method parse/execution failed [\AMW0.WMBC] (Node f7023b88), AE_ALREADY_EXISTS [ 176.920469] ACPI: Marking method WMBC as Serialized because of AE_ALREADY_EXISTS error Then it'll work. What's the best way to avoid that ? - Is there some way to tell acpica that this method should be serialized ? - Is there some way to finish the execution of the first WMBC call in the notify handler ? - Should I use a work queue, and do what I have to do later (when the previous call is finished) ? - anything else ? Thanks, -- Corentin Chary http://xf.iksaif.net -- 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: ACPI notify handler and reentrancy of WMI device.
On Thu, Jan 20, 2011 at 10:55 AM, Lin Ming ming.m@intel.com wrote: On Mon, 2011-01-17 at 14:51 +0800, Corentin Chary wrote: I got an acpi notify handler. The notify is triggered when I call WMBC(). In this notify handler, I must re-call WMBC (with some other arguments, it won't notify again this time). If I do that, I'll get: [ 176.920391] ACPI Error (dswload-0802): [_T_0] Namespace lookup failure, AE_ALREADY_EXISTS [ 176.920416] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20100428/psloop-231) [ 176.920439] ACPI Error (psparse-0537): Method parse/execution failed [\AMW0.WMBC] (Node f7023b88), AE_ALREADY_EXISTS [ 176.920469] ACPI: Marking method WMBC as Serialized because of AE_ALREADY_EXISTS error Could you attach the acpidump output? Here it is, and here is the patch I did (I used the workqueue solution in this one): http://git.iksaif.net/?p=acpi4asus.git;a=blobdiff;f=drivers/platform/x86/eeepc-wmi.c;h=725239860bad8d97dabf8b3db4086d6df4b7820b;hp=0d8217d1478028071859ba1a503ba226b3cb33a0;hb=1eac4d6a6fb632314a464e7d52e1dcb1e4780931;hpb=5c5d1a036bb7d38153c6d2102767ef51e5d94ce3 (check eeepc_rfkill_notify, it's triggered when the wlan rfkill is blocked: WMBC is called to disable the wlan card, it send a notification, the handler is called, the handler want to check the wlan card status, it calls WMBC again). Thanks; Sorry for late reply. WMBC is not an ACPI spec defined method (which always start with _, _ADR, _DSW etc), the driver should only call ACPI spec defined method. What does this method do? And, I don't see any call to WMBC in eeepc-wmi.c or above patch. It's a wmi driver, so it calls wmi_evaluate_method, wich internally will call \AMW0.WMBC for this GUID. Sorry for the confusion. I finally found a solut^W^W workaround: http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=aa8ff8f23b2f99da9371da9154d3e523b964f054;hp=d13f17d9657d7161884e289cc2ac6efb414a6ff9 But it would probably be cleaner to tell ACPI that we want to serialize access to this method, and let acpica mechanism do the job for us. Thanks, -- Corentin Chary http://xf.iksaif.net -- 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: ACPI notify handler and reentrancy of WMI device.
What does this method do? It does ... *everything*, it's our only entry point in this driver. -- Corentin Chary http://xf.iksaif.net -- 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/14] eeepc-wmi: add hotplug code for Eeepc 1000H
Implement wireless like hotplug handling (code stolen from eeepc-laptop).
Reminder: on some models rfkill is implemented by logically unplugging the
wireless card from the PCI bus. Despite sending ACPI notifications, this does
not appear to be implemented using standard ACPI hotplug - nor does the
firmware provide the _OSC method required to support native PCIe hotplug.
The only sensible choice appears to be to handle the hotplugging directly in
the platform driver.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 274 +-
1 files changed, 273 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 0d8217d..01bc2b3 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -37,9 +37,12 @@
#include linux/backlight.h
#include linux/leds.h
#include linux/rfkill.h
+#include linux/pci.h
+#include linux/pci_hotplug.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/platform_device.h
+#include linux/dmi.h
#include acpi/acpi_bus.h
#include acpi/acpi_drivers.h
@@ -72,6 +75,14 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
+static bool hotplug_wireless;
+
+module_param(hotplug_wireless, bool, 0444);
+MODULE_PARM_DESC(hotplug_wireless,
+Enable hotplug for wireless device.
+If your laptop needs that, please report to
+acpi4asus-u...@lists.sourceforge.net.);
+
static const struct key_entry eeepc_wmi_keymap[] = {
/* Sleep already handled via generic ACPI code */
{ KE_IGNORE, NOTIFY_BRNDOWN_MIN, { KEY_BRIGHTNESSDOWN } },
@@ -109,6 +120,8 @@ struct eeepc_wmi_debug {
};
struct eeepc_wmi {
+ bool hotplug_wireless;
+
struct input_dev *inputdev;
struct backlight_device *backlight_device;
struct platform_device *platform_device;
@@ -122,6 +135,9 @@ struct eeepc_wmi {
struct rfkill *bluetooth_rfkill;
struct rfkill *wwan3g_rfkill;
+ struct hotplug_slot *hotplug_slot;
+ struct mutex hotplug_lock;
+
struct eeepc_wmi_debug debug;
};
@@ -177,7 +193,8 @@ static acpi_status eeepc_wmi_get_devstate(u32 dev_id, u32
*retval)
u32 tmp;
status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
- 1, EEEPC_WMI_METHODID_DSTS, input, output);
+1, EEEPC_WMI_METHODID_DSTS,
+input, output);
if (ACPI_FAILURE(status))
return status;
@@ -334,6 +351,206 @@ static void eeepc_wmi_led_exit(struct eeepc_wmi *eeepc)
}
/*
+ * PCI hotplug (for wlan rfkill)
+ */
+static bool eeepc_wlan_rfkill_blocked(struct eeepc_wmi *eeepc)
+{
+ u32 retval;
+ acpi_status status;
+
+ status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_WLAN, retval);
+
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return !(retval 0x1);
+}
+
+static void eeepc_rfkill_hotplug(struct eeepc_wmi *eeepc)
+{
+ struct pci_dev *dev;
+ struct pci_bus *bus;
+ bool blocked = eeepc_wlan_rfkill_blocked(eeepc);
+ bool absent;
+ u32 l;
+
+ if (eeepc-wlan_rfkill)
+ rfkill_set_sw_state(eeepc-wlan_rfkill, blocked);
+
+ mutex_lock(eeepc-hotplug_lock);
+
+ if (eeepc-hotplug_slot) {
+ bus = pci_find_bus(0, 1);
+ if (!bus) {
+ pr_warning(Unable to find PCI bus 1?\n);
+ goto out_unlock;
+ }
+
+ if (pci_bus_read_config_dword(bus, 0, PCI_VENDOR_ID, l)) {
+ pr_err(Unable to read PCI config space?\n);
+ goto out_unlock;
+ }
+ absent = (l == 0x);
+
+ if (blocked != absent) {
+ pr_warning(BIOS says wireless lan is %s,
+ but the pci device is %s\n,
+ blocked ? blocked : unblocked,
+ absent ? absent : present);
+ pr_warning(skipped wireless hotplug as probably
+ inappropriate for this model\n);
+ goto out_unlock;
+ }
+
+ if (!blocked) {
+ dev = pci_get_slot(bus, 0);
+ if (dev) {
+ /* Device already present */
+ pci_dev_put(dev);
+ goto out_unlock;
+ }
+ dev = pci_scan_single_device(bus, 0);
+ if (dev) {
+ pci_bus_assign_resources(bus);
+ if (pci_bus_add_device(dev
[PATCH 04/14] eeepc-wmi: serialize access to wmi method
\AMW0.WMBC, which is the main method that we use,
is not reentrant. When wireless hotpluging is enabled,
toggling the status of the wireless device using WMBC will
trigger a notification and the notification handler need to
call WMBC again to get the new status of the device, this
will trigger the following error:
ACPI Error (dswload-0802): [_T_0] Namespace lookup failure, AE_ALREADY_EXISTS
ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog
(20100428/psloop-231)
ACPI Error (psparse-0537): Method parse/execution failed [\AMW0.WMBC] (Node
f7023b88), AE_ALREADY_EXISTS
ACPI: Marking method WMBC as Serialized because of AE_ALREADY_EXISTS error
Since there is currently no way to tell the acpi subsystem to mark
a method as serialized, we do it in eeepc-wmi.
Of course, we could let the first call fail, and then it would work,
but it doesn't seems really clean, and it will make the first
WMBC call return a random value.
This patch was tested on EeePc 1000H with a RaLink RT2860
wireless card using the rt2800pci driver. rt2860sta driver
seems to deadlock when we remove the pci device...
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 78 +++---
1 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 01bc2b3..eb4c0ce 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -137,6 +137,9 @@ struct eeepc_wmi {
struct hotplug_slot *hotplug_slot;
struct mutex hotplug_lock;
+ struct mutex wmi_lock;
+ struct workqueue_struct *hotplug_workqueue;
+ struct work_struct hotplug_work;
struct eeepc_wmi_debug debug;
};
@@ -370,15 +373,19 @@ static void eeepc_rfkill_hotplug(struct eeepc_wmi *eeepc)
{
struct pci_dev *dev;
struct pci_bus *bus;
- bool blocked = eeepc_wlan_rfkill_blocked(eeepc);
+ bool blocked;
bool absent;
u32 l;
- if (eeepc-wlan_rfkill)
- rfkill_set_sw_state(eeepc-wlan_rfkill, blocked);
+ mutex_lock(eeepc-wmi_lock);
+ blocked = eeepc_wlan_rfkill_blocked(eeepc);
+ mutex_unlock(eeepc-wmi_lock);
mutex_lock(eeepc-hotplug_lock);
+ if (eeepc-wlan_rfkill)
+ rfkill_set_sw_state(eeepc-wlan_rfkill, blocked);
+
if (eeepc-hotplug_slot) {
bus = pci_find_bus(0, 1);
if (!bus) {
@@ -435,7 +442,14 @@ static void eeepc_rfkill_notify(acpi_handle handle, u32
event, void *data)
if (event != ACPI_NOTIFY_BUS_CHECK)
return;
- eeepc_rfkill_hotplug(eeepc);
+ /*
+* We can't call directly eeepc_rfkill_hotplug because most
+* of the time WMBC is still being executed and not reetrant.
+* There is currently no way to tell ACPICA that we want this
+* method to be serialized, we schedule a eeepc_rfkill_hotplug
+* call later, in a safer context.
+*/
+ queue_work(eeepc-hotplug_workqueue, eeepc-hotplug_work);
}
static int eeepc_register_rfkill_notifier(struct eeepc_wmi *eeepc,
@@ -508,6 +522,14 @@ static struct hotplug_slot_ops eeepc_hotplug_slot_ops = {
.get_power_status = eeepc_get_adapter_status,
};
+static void eeepc_hotplug_work(struct work_struct *work)
+{
+ struct eeepc_wmi *eeepc;
+
+ eeepc = container_of(work, struct eeepc_wmi, hotplug_work);
+ eeepc_rfkill_hotplug(eeepc);
+}
+
static int eeepc_setup_pci_hotplug(struct eeepc_wmi *eeepc)
{
int ret = -ENOMEM;
@@ -518,6 +540,13 @@ static int eeepc_setup_pci_hotplug(struct eeepc_wmi *eeepc)
return -ENODEV;
}
+ eeepc-hotplug_workqueue =
+ create_singlethread_workqueue(hotplug_workqueue);
+ if (!eeepc-hotplug_workqueue)
+ goto error_workqueue;
+
+ INIT_WORK(eeepc-hotplug_work, eeepc_hotplug_work);
+
eeepc-hotplug_slot = kzalloc(sizeof(struct hotplug_slot), GFP_KERNEL);
if (!eeepc-hotplug_slot)
goto error_slot;
@@ -547,6 +576,8 @@ error_info:
kfree(eeepc-hotplug_slot);
eeepc-hotplug_slot = NULL;
error_slot:
+ destroy_workqueue(eeepc-hotplug_workqueue);
+error_workqueue:
return ret;
}
@@ -575,6 +606,34 @@ static void eeepc_rfkill_query(struct rfkill *rfkill, void
*data)
rfkill_set_sw_state(rfkill, !(retval 0x1));
}
+static int eeepc_rfkill_wlan_set(void *data, bool blocked)
+{
+ struct eeepc_wmi *eeepc = data;
+ int ret;
+
+ /*
+* This handler is enabled only if hotplug is enabled.
+* In this case, the eeepc_wmi_set_devstate() will
+* trigger a wmi notification and we need to wait
+* this call to finish before being able to call
+* any wmi method
+*/
+ mutex_lock(eeepc-wmi_lock);
+ ret = eeepc_rfkill_set((void *)(long
[PATCH 06/14] eeepc-wmi: add an helper using simple return codes
eeepc_wmi_get_devstate returns an acpi_status, so each
call need extra logic to handle the return code. This
patch add a simple getter, returning a boolean (or a
negative error code).
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 96 +++--
1 files changed, 39 insertions(+), 57 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index d823458..de501fb 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -257,6 +257,29 @@ static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32
ctrl_param,
return status;
}
+/* Helper for special devices with magic return codes */
+static int eeepc_wmi_get_devstate_simple(u32 dev_id)
+{
+ u32 retval = 0;
+ acpi_status status;
+
+ status = eeepc_wmi_get_devstate(dev_id, retval);
+
+ if (ACPI_FAILURE(status))
+ return -EINVAL;
+
+ /* If the device is present, DSTS will always set some bits
+* 0x0007 - 111 - device supported
+* 0x0006 - 110 - not supported
+* 0x0002 - 010 - device supported
+* 0x0001 - 001 - not supported / special mode ?
+*/
+ if (!retval || retval == 0x0006)
+ return -ENODEV;
+
+ return retval 0x1;
+}
+
/*
* LEDs
*/
@@ -290,23 +313,7 @@ static void tpd_led_set(struct led_classdev *led_cdev,
static int read_tpd_state(struct eeepc_wmi *eeepc)
{
- u32 retval;
- acpi_status status;
-
- status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_TPDLED, retval);
-
- if (ACPI_FAILURE(status))
- return -1;
- else if (!retval || retval == 0x0006)
- /*
-* if touchpad led is present, DSTS will set some bits,
-* usually 0x0002.
-* 0x0006 means that the device is not supported
-*/
- return -ENODEV;
- else
- /* Status is stored in the first bit */
- return retval 0x1;
+ return eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_TPDLED);
}
static enum led_brightness tpd_led_get(struct led_classdev *led_cdev)
@@ -358,15 +365,11 @@ static void eeepc_wmi_led_exit(struct eeepc_wmi *eeepc)
*/
static bool eeepc_wlan_rfkill_blocked(struct eeepc_wmi *eeepc)
{
- u32 retval;
- acpi_status status;
-
- status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_WLAN, retval);
+ int result = eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WLAN);
- if (ACPI_FAILURE(status))
+ if (result 0)
return false;
-
- return !(retval 0x1);
+ return !result;
}
static void eeepc_rfkill_hotplug(struct eeepc_wmi *eeepc)
@@ -494,19 +497,12 @@ static void eeepc_unregister_rfkill_notifier(struct
eeepc_wmi *eeepc,
static int eeepc_get_adapter_status(struct hotplug_slot *hotplug_slot,
u8 *value)
{
- u32 retval;
- acpi_status status;
-
- status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_WLAN, retval);
-
- if (ACPI_FAILURE(status))
- return -EIO;
+ int result = eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WLAN);
- if (!retval || retval == 0x0006)
- return -ENODEV;
- else
- *value = (retval 0x1);
+ if (result 0)
+ return result;
+ *value = !!result;
return 0;
}
@@ -601,15 +597,14 @@ static int eeepc_rfkill_set(void *data, bool blocked)
static void eeepc_rfkill_query(struct rfkill *rfkill, void *data)
{
int dev_id = (unsigned long)data;
- u32 retval;
- acpi_status status;
+ int result;
- status = eeepc_wmi_get_devstate(dev_id, retval);
+ result = eeepc_wmi_get_devstate_simple(dev_id);
- if (ACPI_FAILURE(status))
+ if (result 0)
return ;
- rfkill_set_sw_state(rfkill, !(retval 0x1));
+ rfkill_set_sw_state(rfkill, !result);
}
static int eeepc_rfkill_wlan_set(void *data, bool blocked)
@@ -650,23 +645,10 @@ static int eeepc_new_rfkill(struct eeepc_wmi *eeepc,
const char *name,
enum rfkill_type type, int dev_id)
{
- int result;
- u32 retval;
- acpi_status status;
-
- status = eeepc_wmi_get_devstate(dev_id, retval);
+ int result = eeepc_wmi_get_devstate_simple(dev_id);
- if (ACPI_FAILURE(status))
- return -1;
-
- /* If the device is present, DSTS will always set some bits
-* 0x0007 - 111 - device supported
-* 0x0006 - 110 - not supported
-* 0x0002 - 010 - device supported
-* 0x0001 - 001 - not supported / special mode
[PATCH 07/14] eeepc-wmi: add hibernate/resume callbacks
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 49 ++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index de501fb..583ba78 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -1183,10 +1183,59 @@ static int eeepc_wmi_remove(struct platform_device
*device)
return 0;
}
+/*
+ * Platform driver - hibernate/resume callbacks
+ */
+static int eeepc_hotk_thaw(struct device *device)
+{
+ struct eeepc_wmi *eeepc = dev_get_drvdata(device);
+
+ if (eeepc-wlan_rfkill) {
+ bool wlan;
+
+ /*
+* Work around bios bug - acpi _PTS turns off the wireless led
+* during suspend. Normally it restores it on resume, but
+* we should kick it ourselves in case hibernation is aborted.
+*/
+ wlan = eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WLAN);
+ eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_WLAN, wlan, NULL);
+ }
+
+ return 0;
+}
+
+static int eeepc_hotk_restore(struct device *device)
+{
+ struct eeepc_wmi *eeepc = dev_get_drvdata(device);
+ int bl;
+
+ /* Refresh both wlan rfkill state and pci hotplug */
+ if (eeepc-wlan_rfkill)
+ eeepc_rfkill_hotplug(eeepc);
+
+ if (eeepc-bluetooth_rfkill) {
+ bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_BLUETOOTH);
+ rfkill_set_sw_state(eeepc-bluetooth_rfkill, bl);
+}
+ if (eeepc-wwan3g_rfkill) {
+ bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WWAN3G);
+ rfkill_set_sw_state(eeepc-wwan3g_rfkill, bl);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops eeepc_pm_ops = {
+ .thaw = eeepc_hotk_thaw,
+ .restore = eeepc_hotk_restore,
+};
+
static struct platform_driver platform_driver = {
.driver = {
.name = EEEPC_WMI_FILE,
.owner = THIS_MODULE,
+ .pm = eeepc_pm_ops,
},
};
--
1.7.3.4
--
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/14] eeepc-wmi: reorder defines
Signed-off-by: Corentin Chary corenti...@iksaif.net --- drivers/platform/x86/eeepc-wmi.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index 1fc191b..aa9e1d1 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -60,20 +60,20 @@ MODULE_LICENSE(GPL); MODULE_ALIAS(wmi:EEEPC_WMI_EVENT_GUID); MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID); -#define NOTIFY_BRNUP_MIN 0x11 -#define NOTIFY_BRNUP_MAX 0x1f -#define NOTIFY_BRNDOWN_MIN 0x20 -#define NOTIFY_BRNDOWN_MAX 0x2e +#define NOTIFY_BRNUP_MIN 0x11 +#define NOTIFY_BRNUP_MAX 0x1f +#define NOTIFY_BRNDOWN_MIN 0x20 +#define NOTIFY_BRNDOWN_MAX 0x2e -#define EEEPC_WMI_METHODID_DEVS0x53564544 -#define EEEPC_WMI_METHODID_DSTS0x53544344 -#define EEEPC_WMI_METHODID_CFVS0x53564643 +#define EEEPC_WMI_METHODID_DSTS0x53544344 +#define EEEPC_WMI_METHODID_DEVS0x53564544 +#define EEEPC_WMI_METHODID_CFVS0x53564643 -#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012 -#define EEEPC_WMI_DEVID_TPDLED 0x00100011 #define EEEPC_WMI_DEVID_WLAN 0x00010011 #define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013 #define EEEPC_WMI_DEVID_WWAN3G 0x00010019 +#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012 +#define EEEPC_WMI_DEVID_TPDLED 0x00100011 static bool hotplug_wireless; -- 1.7.3.4 -- 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/14] eeepc-wmi: use the presence bit correctly
I checked some more DSDT, and it seems that I wasn't totally right about the meaning of DSTS return value. Bit 0 is clearly the status of the device, and I discovered that bit 16 is set when the device is present. Signed-off-by: Corentin Chary corenti...@iksaif.net --- drivers/platform/x86/eeepc-wmi.c | 13 + 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index aa9e1d1..391c32b 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -75,6 +75,9 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID); #define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012 #define EEEPC_WMI_DEVID_TPDLED 0x00100011 +#define EEEPC_WMI_DSTS_STATUS_BIT 0x0001 +#define EEEPC_WMI_DSTS_PRESENCE_BIT0x0001 + static bool hotplug_wireless; module_param(hotplug_wireless, bool, 0444); @@ -265,16 +268,10 @@ static int eeepc_wmi_get_devstate_simple(u32 dev_id) if (ACPI_FAILURE(status)) return -EINVAL; - /* If the device is present, DSTS will always set some bits -* 0x0007 - 111 - device supported -* 0x0006 - 110 - not supported -* 0x0002 - 010 - device supported -* 0x0001 - 001 - not supported / special mode ? -*/ - if (!retval || retval == 0x0006) + if (!(retval EEEPC_WMI_DSTS_PRESENCE_BIT)) return -ENODEV; - return retval 0x1; + return retval EEEPC_WMI_DSTS_STATUS_BIT; } /* -- 1.7.3.4 -- 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/14] eeepc-wmi: add wimax support
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 83415dd..0db7009 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -71,6 +71,7 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_WLAN 0x00010011
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
+#define EEEPC_WMI_DEVID_WIMAX 0x00010017
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
#define EEEPC_WMI_DEVID_CAMERA 0x00060013
@@ -138,6 +139,7 @@ struct eeepc_wmi {
struct rfkill *wlan_rfkill;
struct rfkill *bluetooth_rfkill;
+ struct rfkill *wimax_rfkill;
struct rfkill *wwan3g_rfkill;
struct hotplug_slot *hotplug_slot;
@@ -691,6 +693,11 @@ static void eeepc_wmi_rfkill_exit(struct eeepc_wmi *eeepc)
rfkill_destroy(eeepc-bluetooth_rfkill);
eeepc-bluetooth_rfkill = NULL;
}
+ if (eeepc-wimax_rfkill) {
+ rfkill_unregister(eeepc-wimax_rfkill);
+ rfkill_destroy(eeepc-wimax_rfkill);
+ eeepc-wimax_rfkill = NULL;
+ }
if (eeepc-wwan3g_rfkill) {
rfkill_unregister(eeepc-wwan3g_rfkill);
rfkill_destroy(eeepc-wwan3g_rfkill);
@@ -719,6 +726,13 @@ static int eeepc_wmi_rfkill_init(struct eeepc_wmi *eeepc)
if (result result != -ENODEV)
goto exit;
+ result = eeepc_new_rfkill(eeepc, eeepc-wimax_rfkill,
+ eeepc-wimax, RFKILL_TYPE_WIMAX,
+ EEEPC_WMI_DEVID_WIMAX);
+
+ if (result result != -ENODEV)
+ goto exit;
+
result = eeepc_new_rfkill(eeepc, eeepc-wwan3g_rfkill,
eeepc-wwan3g, RFKILL_TYPE_WWAN,
EEEPC_WMI_DEVID_WWAN3G);
@@ -1276,7 +1290,11 @@ static int eeepc_hotk_restore(struct device *device)
if (eeepc-bluetooth_rfkill) {
bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_BLUETOOTH);
rfkill_set_sw_state(eeepc-bluetooth_rfkill, bl);
-}
+ }
+ if (eeepc-wimax_rfkill) {
+ bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WIMAX);
+ rfkill_set_sw_state(eeepc-wimax_rfkill, bl);
+ }
if (eeepc-wwan3g_rfkill) {
bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WWAN3G);
rfkill_set_sw_state(eeepc-wwan3g_rfkill, bl);
--
1.7.3.4
--
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/14] eeepc-wmi: set the right key code for 0xe9
This key should power off the backlight, not the display,
it is also used in acpi/video.c to do the same thing.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 0db7009..75dd692 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -103,7 +103,7 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
{ KE_KEY, 0xe0, { KEY_PROG1 } },
{ KE_KEY, 0xe1, { KEY_F14 } },
- { KE_KEY, 0xe9, { KEY_DISPLAY_OFF } },
+ { KE_KEY, 0xe9, { KEY_BRIGHTNESS_ZERO } },
{ KE_END, 0},
};
--
1.7.3.4
--
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/14] eeepc-wmi: support backlight power (bl_power) attribute
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 75 +++---
1 files changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 75dd692..fcb6dfe 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -73,13 +73,16 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
#define EEEPC_WMI_DEVID_WIMAX 0x00010017
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
-#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
+#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050011
+#define EEEPC_WMI_DEVID_BRIGHTNESS 0x00050012
#define EEEPC_WMI_DEVID_CAMERA 0x00060013
#define EEEPC_WMI_DEVID_CARDREADER 0x00080013
#define EEEPC_WMI_DEVID_TPDLED 0x00100011
#define EEEPC_WMI_DSTS_STATUS_BIT 0x0001
#define EEEPC_WMI_DSTS_PRESENCE_BIT0x0001
+#define EEEPC_WMI_DSTS_BRIGHTNESS_MASK 0x00FF
+#define EEEPC_WMI_DSTS_MAX_BRIGTH_MASK 0xFF00
static bool hotplug_wireless;
@@ -262,7 +265,7 @@ static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32
ctrl_param,
}
/* Helper for special devices with magic return codes */
-static int eeepc_wmi_get_devstate_simple(u32 dev_id)
+static int eeepc_wmi_get_devstate_bits(u32 dev_id, u32 mask)
{
u32 retval = 0;
acpi_status status;
@@ -275,7 +278,12 @@ static int eeepc_wmi_get_devstate_simple(u32 dev_id)
if (!(retval EEEPC_WMI_DSTS_PRESENCE_BIT))
return -ENODEV;
- return retval EEEPC_WMI_DSTS_STATUS_BIT;
+ return retval mask;
+}
+
+static int eeepc_wmi_get_devstate_simple(u32 dev_id)
+{
+ return !!eeepc_wmi_get_devstate_bits(dev_id, EEEPC_WMI_DSTS_STATUS_BIT);
}
/*
@@ -770,34 +778,53 @@ exit:
/*
* Backlight
*/
+static int read_backlight_power(void)
+{
+ int ret = eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_BACKLIGHT);
+
+ if (ret 0)
+ return ret;
+
+ return ret ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+}
+
static int read_brightness(struct backlight_device *bd)
{
u32 retval;
acpi_status status;
- status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_BACKLIGHT, retval);
+ status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_BRIGHTNESS, retval);
if (ACPI_FAILURE(status))
- return -1;
+ return -EIO;
else
- return retval 0xFF;
+ return retval EEEPC_WMI_DSTS_BRIGHTNESS_MASK;
}
static int update_bl_status(struct backlight_device *bd)
{
-
u32 ctrl_param;
acpi_status status;
+ int power;
ctrl_param = bd-props.brightness;
- status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BACKLIGHT,
+ status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BRIGHTNESS,
ctrl_param, NULL);
if (ACPI_FAILURE(status))
- return -1;
- else
- return 0;
+ return -EIO;
+
+ power = read_backlight_power();
+ if (power != -ENODEV bd-props.power != power) {
+ ctrl_param = !!(bd-props.power == FB_BLANK_UNBLANK);
+ status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BACKLIGHT,
+ ctrl_param, NULL);
+
+ if (ACPI_FAILURE(status))
+ return -EIO;
+ }
+ return 0;
}
static const struct backlight_ops eeepc_wmi_bl_ops = {
@@ -827,9 +854,29 @@ static int eeepc_wmi_backlight_init(struct eeepc_wmi
*eeepc)
{
struct backlight_device *bd;
struct backlight_properties props;
+ int max;
+ int power;
+
+ max = eeepc_wmi_get_devstate_bits(EEEPC_WMI_DEVID_BRIGHTNESS,
+ EEEPC_WMI_DSTS_MAX_BRIGTH_MASK);
+ power = read_backlight_power();
+
+ if (max 0 power 0) {
+ /* Try to keep the original error */
+ if (max == -ENODEV power == -ENODEV)
+ return -ENODEV;
+ if (max != -ENODEV)
+ return max;
+ else
+ return power;
+ }
+ if (max == -ENODEV)
+ max = 0;
+ if (power == -ENODEV)
+ power = FB_BLANK_UNBLANK;
memset(props, 0, sizeof(struct backlight_properties));
- props.max_brightness = 15;
+ props.max_brightness = max;
bd = backlight_device_register(EEEPC_WMI_FILE,
eeepc-platform_device-dev, eeepc,
eeepc_wmi_bl_ops, props);
@@ -841,7 +888,7 @@ static int eeepc_wmi_backlight_init(struct eeepc_wmi *eeepc)
eeepc-backlight_device = bd;
bd-props.brightness = read_brightness(bd);
- bd-props.power = FB_BLANK_UNBLANK;
+ bd-props.power
Re: [PATCH 0/4] Pegatron Lucid tablet acceleromter/ALS
On Tue, Jan 25, 2011 at 12:05 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Mon, Jan 24, 2011 at 02:48:04PM -0800, Andy Ross wrote: Resubmission and update of the Pegatron Lucid tablet accelerometer and ambient light sensor drivers. Patches 1-3 are against asus-laptop, and apply in order. Patch 4 is against input, and can be commited separately (obviously relies on the detection code in asus-laptop at runtime, but will build and load independently). I am happy with the input part but I wonder if it really needs to be separate? If you roll it up into asus-laptop you would not need a new platform device and then it would be what - 20 lines of code? Corentin, what do you think? I think that it should be consistent, if there is already some code for pegatron tablet in asus-laptop, then why a new platform device only for the accelerometer ? On the other side, having to load asus-laptop on a pegatron tablet (or on a lenovo laptop) isn't very intuitive. The real name of this module should be atk010x_acpi, but it's not really better, and it's probably too late for that. Andy, what is shared with asus-laptop exactly ? What sysfs files are working and enabled ? Are backlight and led classes working ? Thanks, -- Corentin Chary http://xf.iksaif.net -- 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/4] Pegatron Lucid tablet acceleromter/ALS
On Tue, Jan 25, 2011 at 4:43 PM, Andy Ross andy.r...@windriver.com wrote: On 01/24/2011 11:30 PM, Corentin Chary wrote: Dmitry Torokhov wrote: I am happy with the input part but I wonder if it really needs to be separate? If you roll it up into asus-laptop you would not need a new platform device and then it would be what - 20 lines of code? Corentin, what do you think? I think that it should be consistent, if there is already some code for pegatron tablet in asus-laptop, then why a new platform device only for the accelerometer ? No strong feelings here. I made it a separate file because asus-laptop.c is already very large and this was something that could be fairly easily split out, but obviously it's a really trivial device. Andy, what is shared with asus-laptop exactly ? What sysfs files are working and enabled ? Are backlight and led classes working ? Just the key device, which exports the single touch area in the corner of the tablet as KEY_MEDIA. Some of the other sysfs devices (bluetooth, display, leds) appear because the methods exist, but they're stubbed out in the ASL and thus noops. Andy If everybody is ok with that, I think you should move the code back into asus-laptop.c. But if you do so, don't forget to modify the help text of ASUS_LAPTOP section in KConfig. Should we also change the description to Asus/Medion/JVC/Lenovo/Pegatron Extra ? That seems really ugly but -- Corentin Chary http://xf.iksaif.net -- 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 14/14] eeepc-wmi: support backlight power (bl_power) attribute
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
The previous patch broke eeepc_wmi_get_devstate_simple(),
here is a fixed patch.
drivers/platform/x86/eeepc-wmi.c | 75 +++---
1 files changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 75dd692..910eb00 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -73,13 +73,16 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
#define EEEPC_WMI_DEVID_WIMAX 0x00010017
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
-#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
+#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050011
+#define EEEPC_WMI_DEVID_BRIGHTNESS 0x00050012
#define EEEPC_WMI_DEVID_CAMERA 0x00060013
#define EEEPC_WMI_DEVID_CARDREADER 0x00080013
#define EEEPC_WMI_DEVID_TPDLED 0x00100011
#define EEEPC_WMI_DSTS_STATUS_BIT 0x0001
#define EEEPC_WMI_DSTS_PRESENCE_BIT0x0001
+#define EEEPC_WMI_DSTS_BRIGHTNESS_MASK 0x00FF
+#define EEEPC_WMI_DSTS_MAX_BRIGTH_MASK 0xFF00
static bool hotplug_wireless;
@@ -262,7 +265,7 @@ static acpi_status eeepc_wmi_set_devstate(u32 dev_id, u32
ctrl_param,
}
/* Helper for special devices with magic return codes */
-static int eeepc_wmi_get_devstate_simple(u32 dev_id)
+static int eeepc_wmi_get_devstate_bits(u32 dev_id, u32 mask)
{
u32 retval = 0;
acpi_status status;
@@ -275,7 +278,12 @@ static int eeepc_wmi_get_devstate_simple(u32 dev_id)
if (!(retval EEEPC_WMI_DSTS_PRESENCE_BIT))
return -ENODEV;
- return retval EEEPC_WMI_DSTS_STATUS_BIT;
+ return retval mask;
+}
+
+static int eeepc_wmi_get_devstate_simple(u32 dev_id)
+{
+ return eeepc_wmi_get_devstate_bits(dev_id, EEEPC_WMI_DSTS_STATUS_BIT);
}
/*
@@ -770,34 +778,53 @@ exit:
/*
* Backlight
*/
+static int read_backlight_power(void)
+{
+ int ret = eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_BACKLIGHT);
+
+ if (ret 0)
+ return ret;
+
+ return ret ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+}
+
static int read_brightness(struct backlight_device *bd)
{
u32 retval;
acpi_status status;
- status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_BACKLIGHT, retval);
+ status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_BRIGHTNESS, retval);
if (ACPI_FAILURE(status))
- return -1;
+ return -EIO;
else
- return retval 0xFF;
+ return retval EEEPC_WMI_DSTS_BRIGHTNESS_MASK;
}
static int update_bl_status(struct backlight_device *bd)
{
-
u32 ctrl_param;
acpi_status status;
+ int power;
ctrl_param = bd-props.brightness;
- status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BACKLIGHT,
+ status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BRIGHTNESS,
ctrl_param, NULL);
if (ACPI_FAILURE(status))
- return -1;
- else
- return 0;
+ return -EIO;
+
+ power = read_backlight_power();
+ if (power != -ENODEV bd-props.power != power) {
+ ctrl_param = !!(bd-props.power == FB_BLANK_UNBLANK);
+ status = eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_BACKLIGHT,
+ ctrl_param, NULL);
+
+ if (ACPI_FAILURE(status))
+ return -EIO;
+ }
+ return 0;
}
static const struct backlight_ops eeepc_wmi_bl_ops = {
@@ -827,9 +854,29 @@ static int eeepc_wmi_backlight_init(struct eeepc_wmi
*eeepc)
{
struct backlight_device *bd;
struct backlight_properties props;
+ int max;
+ int power;
+
+ max = eeepc_wmi_get_devstate_bits(EEEPC_WMI_DEVID_BRIGHTNESS,
+ EEEPC_WMI_DSTS_MAX_BRIGTH_MASK);
+ power = read_backlight_power();
+
+ if (max 0 power 0) {
+ /* Try to keep the original error */
+ if (max == -ENODEV power == -ENODEV)
+ return -ENODEV;
+ if (max != -ENODEV)
+ return max;
+ else
+ return power;
+ }
+ if (max == -ENODEV)
+ max = 0;
+ if (power == -ENODEV)
+ power = FB_BLANK_UNBLANK;
memset(props, 0, sizeof(struct backlight_properties));
- props.max_brightness = 15;
+ props.max_brightness = max;
bd = backlight_device_register(EEEPC_WMI_FILE,
eeepc-platform_device-dev, eeepc,
eeepc_wmi_bl_ops, props);
@@ -841,7 +888,7 @@ static int eeepc_wmi_backlight_init(struct eeepc_wmi *eeepc)
eeepc-backlight_device = bd;
bd-props.brightness
Re: [PATCH 15/20] platform: x86: asus_acpi: world-writable procfs files
Acked-By: Corentin Chary corenti...@iksaif.net Anyway, the driver is deprecated and will be removed someday. -- 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-laptop: let WLED alone on L1400B
From: Corentin Chary corentin.ch...@gmail.com
Asus took the DSDT from another model (L84F), made some change
to make it work, but forgot to remove WLED method (the laptop
doesn't have a wireless card). They even didn't change the model
name.
ref: https://bugzilla.kernel.org/show_bug.cgi?id=25712
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
drivers/platform/x86/asus-laptop.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index d235f44..1909685 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -50,6 +50,7 @@
#include linux/input/sparse-keymap.h
#include linux/rfkill.h
#include linux/slab.h
+#include linux/dmi.h
#include acpi/acpi_drivers.h
#include acpi/acpi_bus.h
@@ -1556,6 +1557,20 @@ static int __devinit asus_acpi_init(struct asus_laptop
*asus)
return result;
}
+static void __devinit asus_dmi_check(void)
+{
+ const char *model;
+
+ model = dmi_get_system_info(DMI_PRODUCT_NAME);
+ if (!model)
+ return;
+
+ /* On L1400B WLED control the sound card, don't mess with it ... */
+ if (strncmp(model, L1400B, 6) == 0) {
+ wlan_status = -1;
+ }
+}
+
static bool asus_device_present;
static int __devinit asus_acpi_add(struct acpi_device *device)
@@ -1574,6 +1589,8 @@ static int __devinit asus_acpi_add(struct acpi_device
*device)
device-driver_data = asus;
asus-device = device;
+ asus_dmi_check();
+
result = asus_acpi_init(asus);
if (result)
goto fail_platform;
--
1.7.4.rc3
--
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 07/18] eeepc-wmi: add hibernate/resume callbacks
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 49 ++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index de501fb..583ba78 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -1183,10 +1183,59 @@ static int eeepc_wmi_remove(struct platform_device
*device)
return 0;
}
+/*
+ * Platform driver - hibernate/resume callbacks
+ */
+static int eeepc_hotk_thaw(struct device *device)
+{
+ struct eeepc_wmi *eeepc = dev_get_drvdata(device);
+
+ if (eeepc-wlan_rfkill) {
+ bool wlan;
+
+ /*
+* Work around bios bug - acpi _PTS turns off the wireless led
+* during suspend. Normally it restores it on resume, but
+* we should kick it ourselves in case hibernation is aborted.
+*/
+ wlan = eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WLAN);
+ eeepc_wmi_set_devstate(EEEPC_WMI_DEVID_WLAN, wlan, NULL);
+ }
+
+ return 0;
+}
+
+static int eeepc_hotk_restore(struct device *device)
+{
+ struct eeepc_wmi *eeepc = dev_get_drvdata(device);
+ int bl;
+
+ /* Refresh both wlan rfkill state and pci hotplug */
+ if (eeepc-wlan_rfkill)
+ eeepc_rfkill_hotplug(eeepc);
+
+ if (eeepc-bluetooth_rfkill) {
+ bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_BLUETOOTH);
+ rfkill_set_sw_state(eeepc-bluetooth_rfkill, bl);
+}
+ if (eeepc-wwan3g_rfkill) {
+ bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WWAN3G);
+ rfkill_set_sw_state(eeepc-wwan3g_rfkill, bl);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops eeepc_pm_ops = {
+ .thaw = eeepc_hotk_thaw,
+ .restore = eeepc_hotk_restore,
+};
+
static struct platform_driver platform_driver = {
.driver = {
.name = EEEPC_WMI_FILE,
.owner = THIS_MODULE,
+ .pm = eeepc_pm_ops,
},
};
--
1.7.4.rc3
--
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 17/18] eeepc-wmi: add touchpad sysfs file
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
Documentation/ABI/testing/sysfs-platform-eeepc-wmi |7 +++
drivers/platform/x86/eeepc-wmi.c |5 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
index 9fc8d33..26acb68 100644
--- a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
+++ b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
@@ -22,3 +22,10 @@ KernelVersion: 2.6.39
Contact: Corentin Chary corenti...@iksaif.net
Description:
Control the card reader. 1 means on, 0 means off.
+
+What: /sys/devices/platform/eeepc-wmi/touchpad
+Date: Jan 2010
+KernelVersion: 2.6.39
+Contact: Corentin Chary corenti...@iksaif.net
+Description:
+ Control the card touchpad. 1 means on, 0 means off.
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index ffc5889..26ed706 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -77,6 +77,7 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_BRIGHTNESS 0x00050012
#define EEEPC_WMI_DEVID_CAMERA 0x00060013
#define EEEPC_WMI_DEVID_CARDREADER 0x00080013
+#define EEEPC_WMI_DEVID_TOUCHPAD 0x00100011
#define EEEPC_WMI_DEVID_TOUCHPAD_LED 0x00100012
#define EEEPC_WMI_DSTS_STATUS_BIT 0x0001
@@ -1006,6 +1007,7 @@ static ssize_t show_sys_wmi(int devid, char *buf)
.store = store_##_name,\
}
+EEEPC_WMI_CREATE_DEVICE_ATTR(touchpad, 0644, EEEPC_WMI_DEVID_TOUCHPAD);
EEEPC_WMI_CREATE_DEVICE_ATTR(camera, 0644, EEEPC_WMI_DEVID_CAMERA);
EEEPC_WMI_CREATE_DEVICE_ATTR(cardr, 0644, EEEPC_WMI_DEVID_CARDREADER);
@@ -1036,6 +1038,7 @@ static struct attribute *platform_attributes[] = {
dev_attr_cpufv.attr,
dev_attr_camera.attr,
dev_attr_cardr.attr,
+ dev_attr_touchpad.attr,
NULL
};
@@ -1050,6 +1053,8 @@ static mode_t eeepc_sysfs_is_visible(struct kobject *kobj,
devid = EEEPC_WMI_DEVID_CAMERA;
else if (attr == dev_attr_cardr.attr)
devid = EEEPC_WMI_DEVID_CARDREADER;
+ else if (attr == dev_attr_touchpad.attr)
+ devid = EEEPC_WMI_DEVID_TOUCHPAD;
if (devid != -1)
supported = eeepc_wmi_get_devstate_simple(devid) != -ENODEV;
--
1.7.4.rc3
--
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 02/18] eeepc-wmi: add wlan key found on 1015P
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 350b7bc..0d8217d 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -82,6 +82,7 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_KEY, 0x5c, { KEY_F15 } },
{ KE_KEY, 0x5d, { KEY_WLAN } },
{ KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
+ { KE_KEY, 0x88, { KEY_WLAN } },
{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
{ KE_KEY, 0xe0, { KEY_PROG1 } },
{ KE_KEY, 0xe1, { KEY_F14 } },
--
1.7.4.rc3
--
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 03/18] eeepc-wmi: add hotplug code for Eeepc 1000H
Implement wireless like hotplug handling (code stolen from eeepc-laptop).
Reminder: on some models rfkill is implemented by logically unplugging the
wireless card from the PCI bus. Despite sending ACPI notifications, this does
not appear to be implemented using standard ACPI hotplug - nor does the
firmware provide the _OSC method required to support native PCIe hotplug.
The only sensible choice appears to be to handle the hotplugging directly in
the platform driver.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 274 +-
1 files changed, 273 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 0d8217d..01bc2b3 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -37,9 +37,12 @@
#include linux/backlight.h
#include linux/leds.h
#include linux/rfkill.h
+#include linux/pci.h
+#include linux/pci_hotplug.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/platform_device.h
+#include linux/dmi.h
#include acpi/acpi_bus.h
#include acpi/acpi_drivers.h
@@ -72,6 +75,14 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
+static bool hotplug_wireless;
+
+module_param(hotplug_wireless, bool, 0444);
+MODULE_PARM_DESC(hotplug_wireless,
+Enable hotplug for wireless device.
+If your laptop needs that, please report to
+acpi4asus-u...@lists.sourceforge.net.);
+
static const struct key_entry eeepc_wmi_keymap[] = {
/* Sleep already handled via generic ACPI code */
{ KE_IGNORE, NOTIFY_BRNDOWN_MIN, { KEY_BRIGHTNESSDOWN } },
@@ -109,6 +120,8 @@ struct eeepc_wmi_debug {
};
struct eeepc_wmi {
+ bool hotplug_wireless;
+
struct input_dev *inputdev;
struct backlight_device *backlight_device;
struct platform_device *platform_device;
@@ -122,6 +135,9 @@ struct eeepc_wmi {
struct rfkill *bluetooth_rfkill;
struct rfkill *wwan3g_rfkill;
+ struct hotplug_slot *hotplug_slot;
+ struct mutex hotplug_lock;
+
struct eeepc_wmi_debug debug;
};
@@ -177,7 +193,8 @@ static acpi_status eeepc_wmi_get_devstate(u32 dev_id, u32
*retval)
u32 tmp;
status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
- 1, EEEPC_WMI_METHODID_DSTS, input, output);
+1, EEEPC_WMI_METHODID_DSTS,
+input, output);
if (ACPI_FAILURE(status))
return status;
@@ -334,6 +351,206 @@ static void eeepc_wmi_led_exit(struct eeepc_wmi *eeepc)
}
/*
+ * PCI hotplug (for wlan rfkill)
+ */
+static bool eeepc_wlan_rfkill_blocked(struct eeepc_wmi *eeepc)
+{
+ u32 retval;
+ acpi_status status;
+
+ status = eeepc_wmi_get_devstate(EEEPC_WMI_DEVID_WLAN, retval);
+
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return !(retval 0x1);
+}
+
+static void eeepc_rfkill_hotplug(struct eeepc_wmi *eeepc)
+{
+ struct pci_dev *dev;
+ struct pci_bus *bus;
+ bool blocked = eeepc_wlan_rfkill_blocked(eeepc);
+ bool absent;
+ u32 l;
+
+ if (eeepc-wlan_rfkill)
+ rfkill_set_sw_state(eeepc-wlan_rfkill, blocked);
+
+ mutex_lock(eeepc-hotplug_lock);
+
+ if (eeepc-hotplug_slot) {
+ bus = pci_find_bus(0, 1);
+ if (!bus) {
+ pr_warning(Unable to find PCI bus 1?\n);
+ goto out_unlock;
+ }
+
+ if (pci_bus_read_config_dword(bus, 0, PCI_VENDOR_ID, l)) {
+ pr_err(Unable to read PCI config space?\n);
+ goto out_unlock;
+ }
+ absent = (l == 0x);
+
+ if (blocked != absent) {
+ pr_warning(BIOS says wireless lan is %s,
+ but the pci device is %s\n,
+ blocked ? blocked : unblocked,
+ absent ? absent : present);
+ pr_warning(skipped wireless hotplug as probably
+ inappropriate for this model\n);
+ goto out_unlock;
+ }
+
+ if (!blocked) {
+ dev = pci_get_slot(bus, 0);
+ if (dev) {
+ /* Device already present */
+ pci_dev_put(dev);
+ goto out_unlock;
+ }
+ dev = pci_scan_single_device(bus, 0);
+ if (dev) {
+ pci_bus_assign_resources(bus);
+ if (pci_bus_add_device(dev
[PATCH v2 05/18] eeepc-wmi: return proper error code in eeepc_rfkill_set()
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index eb4c0ce..d823458 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -588,8 +588,14 @@ static int eeepc_rfkill_set(void *data, bool blocked)
{
int dev_id = (unsigned long)data;
u32 ctrl_param = !blocked;
+ acpi_status status;
+
+ status = eeepc_wmi_set_devstate(dev_id, ctrl_param, NULL);
+
+ if (ACPI_FAILURE(status))
+ return -EIO;
- return eeepc_wmi_set_devstate(dev_id, ctrl_param, NULL);
+ return 0;
}
static void eeepc_rfkill_query(struct rfkill *rfkill, void *data)
--
1.7.4.rc3
--
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 08/18] eeepc-wmi: switch to platform_create_bundle()
This allow to remove ~30 lines of code.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 75 +++---
1 files changed, 22 insertions(+), 53 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 583ba78..1fc191b 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -144,9 +144,6 @@ struct eeepc_wmi {
struct eeepc_wmi_debug debug;
};
-/* Only used in eeepc_wmi_init() and eeepc_wmi_exit() */
-static struct platform_device *platform_device;
-
static int eeepc_wmi_input_init(struct eeepc_wmi *eeepc)
{
int err;
@@ -932,33 +929,12 @@ static int eeepc_wmi_sysfs_init(struct platform_device
*device)
*/
static int __init eeepc_wmi_platform_init(struct eeepc_wmi *eeepc)
{
- int err;
-
- eeepc-platform_device = platform_device_alloc(EEEPC_WMI_FILE, -1);
- if (!eeepc-platform_device)
- return -ENOMEM;
- platform_set_drvdata(eeepc-platform_device, eeepc);
-
- err = platform_device_add(eeepc-platform_device);
- if (err)
- goto fail_platform_device;
-
- err = eeepc_wmi_sysfs_init(eeepc-platform_device);
- if (err)
- goto fail_sysfs;
- return 0;
-
-fail_sysfs:
- platform_device_del(eeepc-platform_device);
-fail_platform_device:
- platform_device_put(eeepc-platform_device);
- return err;
+ return eeepc_wmi_sysfs_init(eeepc-platform_device);
}
static void eeepc_wmi_platform_exit(struct eeepc_wmi *eeepc)
{
eeepc_wmi_sysfs_exit(eeepc-platform_device);
- platform_device_unregister(eeepc-platform_device);
}
/*
@@ -1094,7 +1070,7 @@ static void eeepc_dmi_check(struct eeepc_wmi *eeepc)
}
}
-static struct platform_device * __init eeepc_wmi_add(void)
+static int __init eeepc_wmi_add(struct platform_device *pdev)
{
struct eeepc_wmi *eeepc;
acpi_status status;
@@ -1102,15 +1078,14 @@ static struct platform_device * __init
eeepc_wmi_add(void)
eeepc = kzalloc(sizeof(struct eeepc_wmi), GFP_KERNEL);
if (!eeepc)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
+
+ eeepc-platform_device = pdev;
+ platform_set_drvdata(eeepc-platform_device, eeepc);
eeepc-hotplug_wireless = hotplug_wireless;
eeepc_dmi_check(eeepc);
- /*
-* Register the platform device first. It is used as a parent for the
-* sub-devices below.
-*/
err = eeepc_wmi_platform_init(eeepc);
if (err)
goto fail_platform;
@@ -1147,7 +1122,7 @@ static struct platform_device * __init eeepc_wmi_add(void)
if (err)
goto fail_debugfs;
- return eeepc-platform_device;
+ return 0;
fail_debugfs:
wmi_remove_notify_handler(EEEPC_WMI_EVENT_GUID);
@@ -1163,10 +1138,10 @@ fail_input:
eeepc_wmi_platform_exit(eeepc);
fail_platform:
kfree(eeepc);
- return ERR_PTR(err);
+ return err;
}
-static int eeepc_wmi_remove(struct platform_device *device)
+static int __exit eeepc_wmi_remove(struct platform_device *device)
{
struct eeepc_wmi *eeepc;
@@ -1232,6 +1207,7 @@ static const struct dev_pm_ops eeepc_pm_ops = {
};
static struct platform_driver platform_driver = {
+ .remove = __exit_p(eeepc_wmi_remove),
.driver = {
.name = EEEPC_WMI_FILE,
.owner = THIS_MODULE,
@@ -1260,10 +1236,8 @@ static int __init eeepc_wmi_check_atkd(void)
return -1;
}
-static int __init eeepc_wmi_init(void)
+static int __init eeepc_wmi_probe(struct platform_device *pdev)
{
- int err;
-
if (!wmi_has_guid(EEEPC_WMI_EVENT_GUID) ||
!wmi_has_guid(EEEPC_WMI_MGMT_GUID)) {
pr_warning(No known WMI GUID found\n);
@@ -1280,29 +1254,24 @@ static int __init eeepc_wmi_init(void)
return -ENODEV;
}
- platform_device = eeepc_wmi_add();
- if (IS_ERR(platform_device)) {
- err = PTR_ERR(platform_device);
- goto fail_eeepc_wmi;
- }
+ return eeepc_wmi_add(pdev);
+}
- err = platform_driver_register(platform_driver);
- if (err) {
- pr_warning(Unable to register platform driver\n);
- goto fail_platform_driver;
- }
+static struct platform_device *platform_device;
+static int __init eeepc_wmi_init(void)
+{
+ platform_device = platform_create_bundle(platform_driver,
+eeepc_wmi_probe,
+NULL, 0, NULL, 0);
+ if (IS_ERR(platform_device))
+ return PTR_ERR(platform_device);
return 0;
-
-fail_platform_driver:
- eeepc_wmi_remove(platform_device);
-fail_eeepc_wmi:
- return err;
}
static void __exit eeepc_wmi_exit(void
[PATCH v2 09/18] eeepc-wmi: reorder defines
Signed-off-by: Corentin Chary corenti...@iksaif.net --- drivers/platform/x86/eeepc-wmi.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index 1fc191b..aa9e1d1 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -60,20 +60,20 @@ MODULE_LICENSE(GPL); MODULE_ALIAS(wmi:EEEPC_WMI_EVENT_GUID); MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID); -#define NOTIFY_BRNUP_MIN 0x11 -#define NOTIFY_BRNUP_MAX 0x1f -#define NOTIFY_BRNDOWN_MIN 0x20 -#define NOTIFY_BRNDOWN_MAX 0x2e +#define NOTIFY_BRNUP_MIN 0x11 +#define NOTIFY_BRNUP_MAX 0x1f +#define NOTIFY_BRNDOWN_MIN 0x20 +#define NOTIFY_BRNDOWN_MAX 0x2e -#define EEEPC_WMI_METHODID_DEVS0x53564544 -#define EEEPC_WMI_METHODID_DSTS0x53544344 -#define EEEPC_WMI_METHODID_CFVS0x53564643 +#define EEEPC_WMI_METHODID_DSTS0x53544344 +#define EEEPC_WMI_METHODID_DEVS0x53564544 +#define EEEPC_WMI_METHODID_CFVS0x53564643 -#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012 -#define EEEPC_WMI_DEVID_TPDLED 0x00100011 #define EEEPC_WMI_DEVID_WLAN 0x00010011 #define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013 #define EEEPC_WMI_DEVID_WWAN3G 0x00010019 +#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012 +#define EEEPC_WMI_DEVID_TPDLED 0x00100011 static bool hotplug_wireless; -- 1.7.4.rc3 -- 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 10/18] eeepc-wmi: use the presence bit correctly
I checked some more DSDT, and it seems that I wasn't totally right about the meaning of DSTS return value. Bit 0 is clearly the status of the device, and I discovered that bit 16 is set when the device is present. Signed-off-by: Corentin Chary corenti...@iksaif.net --- drivers/platform/x86/eeepc-wmi.c | 13 + 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index aa9e1d1..391c32b 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -75,6 +75,9 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID); #define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012 #define EEEPC_WMI_DEVID_TPDLED 0x00100011 +#define EEEPC_WMI_DSTS_STATUS_BIT 0x0001 +#define EEEPC_WMI_DSTS_PRESENCE_BIT0x0001 + static bool hotplug_wireless; module_param(hotplug_wireless, bool, 0444); @@ -265,16 +268,10 @@ static int eeepc_wmi_get_devstate_simple(u32 dev_id) if (ACPI_FAILURE(status)) return -EINVAL; - /* If the device is present, DSTS will always set some bits -* 0x0007 - 111 - device supported -* 0x0006 - 110 - not supported -* 0x0002 - 010 - device supported -* 0x0001 - 001 - not supported / special mode ? -*/ - if (!retval || retval == 0x0006) + if (!(retval EEEPC_WMI_DSTS_PRESENCE_BIT)) return -ENODEV; - return retval 0x1; + return retval EEEPC_WMI_DSTS_STATUS_BIT; } /* -- 1.7.4.rc3 -- 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 11/18] eeepc-wmi: add camera and card reader support
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
Documentation/ABI/testing/sysfs-platform-eeepc-wmi | 14 +++
drivers/platform/x86/eeepc-wmi.c | 89 +++-
2 files changed, 102 insertions(+), 1 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
index e4b5fef..9fc8d33 100644
--- a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
+++ b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi
@@ -8,3 +8,17 @@ Description:
* 0 - Super Performance Mode
* 1 - High Performance Mode
* 2 - Power Saving Mode
+
+What: /sys/devices/platform/eeepc-wmi/camera
+Date: Jan 2010
+KernelVersion: 2.6.39
+Contact: Corentin Chary corenti...@iksaif.net
+Description:
+ Control the camera. 1 means on, 0 means off.
+
+What: /sys/devices/platform/eeepc-wmi/cardr
+Date: Jan 2010
+KernelVersion: 2.6.39
+Contact: Corentin Chary corenti...@iksaif.net
+Description:
+ Control the card reader. 1 means on, 0 means off.
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 391c32b..83415dd 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -73,6 +73,8 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
+#define EEEPC_WMI_DEVID_CAMERA 0x00060013
+#define EEEPC_WMI_DEVID_CARDREADER 0x00080013
#define EEEPC_WMI_DEVID_TPDLED 0x00100011
#define EEEPC_WMI_DSTS_STATUS_BIT 0x0001
@@ -879,6 +881,70 @@ static void eeepc_wmi_notify(u32 value, void *context)
kfree(obj);
}
+/*
+ * Sys helpers
+ */
+static int parse_arg(const char *buf, unsigned long count, int *val)
+{
+ if (!count)
+ return 0;
+ if (sscanf(buf, %i, val) != 1)
+ return -EINVAL;
+ return count;
+}
+
+static ssize_t store_sys_wmi(int devid, const char *buf, size_t count)
+{
+ acpi_status status;
+ u32 retval;
+ int rv, value;
+
+ value = eeepc_wmi_get_devstate_simple(devid);
+ if (value == -ENODEV) /* Check device presence */
+ return value;
+
+ rv = parse_arg(buf, count, value);
+ status = eeepc_wmi_set_devstate(devid, value, retval);
+
+ if (ACPI_FAILURE(status))
+ return -EIO;
+ return rv;
+}
+
+static ssize_t show_sys_wmi(int devid, char *buf)
+{
+ int value = eeepc_wmi_get_devstate_simple(devid);
+
+ if (value 0)
+ return value;
+
+ return sprintf(buf, %d\n, value);
+}
+
+#define EEEPC_WMI_CREATE_DEVICE_ATTR(_name, _mode, _cm)
\
+ static ssize_t show_##_name(struct device *dev, \
+ struct device_attribute *attr, \
+ char *buf) \
+ { \
+ return show_sys_wmi(_cm, buf); \
+ } \
+ static ssize_t store_##_name(struct device *dev,\
+struct device_attribute *attr, \
+const char *buf, size_t count) \
+ { \
+ return store_sys_wmi(_cm, buf, count); \
+ } \
+ static struct device_attribute dev_attr_##_name = { \
+ .attr = { \
+ .name = __stringify(_name), \
+ .mode = _mode },\
+ .show = show_##_name, \
+ .store = store_##_name,\
+ }
+
+EEEPC_WMI_CREATE_DEVICE_ATTR(camera, 0644, EEEPC_WMI_DEVID_CAMERA);
+EEEPC_WMI_CREATE_DEVICE_ATTR(cardr, 0644, EEEPC_WMI_DEVID_CARDREADER);
+
static ssize_t store_cpufv(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -904,11 +970,32 @@ static DEVICE_ATTR(cpufv, S_IRUGO | S_IWUSR, NULL,
store_cpufv);
static struct attribute *platform_attributes[] = {
dev_attr_cpufv.attr,
+ dev_attr_camera.attr,
+ dev_attr_cardr.attr,
NULL
};
+static mode_t eeepc_sysfs_is_visible(struct kobject *kobj,
+struct attribute *attr,
+int idx)
+{
+ bool supported = true;
+ int devid = -1
[PATCH v2 12/18] eeepc-wmi: add wimax support
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 83415dd..0db7009 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -71,6 +71,7 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
#define EEEPC_WMI_DEVID_WLAN 0x00010011
#define EEEPC_WMI_DEVID_BLUETOOTH 0x00010013
+#define EEEPC_WMI_DEVID_WIMAX 0x00010017
#define EEEPC_WMI_DEVID_WWAN3G 0x00010019
#define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
#define EEEPC_WMI_DEVID_CAMERA 0x00060013
@@ -138,6 +139,7 @@ struct eeepc_wmi {
struct rfkill *wlan_rfkill;
struct rfkill *bluetooth_rfkill;
+ struct rfkill *wimax_rfkill;
struct rfkill *wwan3g_rfkill;
struct hotplug_slot *hotplug_slot;
@@ -691,6 +693,11 @@ static void eeepc_wmi_rfkill_exit(struct eeepc_wmi *eeepc)
rfkill_destroy(eeepc-bluetooth_rfkill);
eeepc-bluetooth_rfkill = NULL;
}
+ if (eeepc-wimax_rfkill) {
+ rfkill_unregister(eeepc-wimax_rfkill);
+ rfkill_destroy(eeepc-wimax_rfkill);
+ eeepc-wimax_rfkill = NULL;
+ }
if (eeepc-wwan3g_rfkill) {
rfkill_unregister(eeepc-wwan3g_rfkill);
rfkill_destroy(eeepc-wwan3g_rfkill);
@@ -719,6 +726,13 @@ static int eeepc_wmi_rfkill_init(struct eeepc_wmi *eeepc)
if (result result != -ENODEV)
goto exit;
+ result = eeepc_new_rfkill(eeepc, eeepc-wimax_rfkill,
+ eeepc-wimax, RFKILL_TYPE_WIMAX,
+ EEEPC_WMI_DEVID_WIMAX);
+
+ if (result result != -ENODEV)
+ goto exit;
+
result = eeepc_new_rfkill(eeepc, eeepc-wwan3g_rfkill,
eeepc-wwan3g, RFKILL_TYPE_WWAN,
EEEPC_WMI_DEVID_WWAN3G);
@@ -1276,7 +1290,11 @@ static int eeepc_hotk_restore(struct device *device)
if (eeepc-bluetooth_rfkill) {
bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_BLUETOOTH);
rfkill_set_sw_state(eeepc-bluetooth_rfkill, bl);
-}
+ }
+ if (eeepc-wimax_rfkill) {
+ bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WIMAX);
+ rfkill_set_sw_state(eeepc-wimax_rfkill, bl);
+ }
if (eeepc-wwan3g_rfkill) {
bl = !eeepc_wmi_get_devstate_simple(EEEPC_WMI_DEVID_WWAN3G);
rfkill_set_sw_state(eeepc-wwan3g_rfkill, bl);
--
1.7.4.rc3
--
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 15/18] eeepc-wmi: respect wireless_hotplug setting
Signed-off-by: Corentin Chary corenti...@iksaif.net --- drivers/platform/x86/eeepc-wmi.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c index 910eb00..bc71333 100644 --- a/drivers/platform/x86/eeepc-wmi.c +++ b/drivers/platform/x86/eeepc-wmi.c @@ -748,6 +748,9 @@ static int eeepc_wmi_rfkill_init(struct eeepc_wmi *eeepc) if (result result != -ENODEV) goto exit; + if (!eeepc-hotplug_wireless) + goto exit; + result = eeepc_setup_pci_hotplug(eeepc); /* * If we get -EBUSY then something else is handling the PCI hotplug - -- 1.7.4.rc3 -- 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] eeepc-wmi input patchs
Hi, These two patchs are separated from the other batch because they may be delayed or re-worked. The first patch add some camera specific keys, we can probably use arrows and +/- to do the same thing, but then we loose some keyboard information (eg: no distinction between Fn+E and Arrow Up). The other patch only add some comments to some ambiguously mapped keys. We may want to define to new key codes for these... Corentin Chary (2): eeepc-wmi: add camera keys eeepc-wmi: comments keymap to clarify the meaning of some keys drivers/platform/x86/eeepc-wmi.c | 13 ++--- include/linux/input.h|7 +++ 2 files changed, 17 insertions(+), 3 deletions(-) -- 1.7.4.rc3 -- 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 01/18] eeepc-wmi: reorder keymap
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 4d38f98..350b7bc 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -74,18 +74,18 @@ MODULE_ALIAS(wmi:EEEPC_WMI_MGMT_GUID);
static const struct key_entry eeepc_wmi_keymap[] = {
/* Sleep already handled via generic ACPI code */
- { KE_KEY, 0x5d, { KEY_WLAN } },
- { KE_KEY, 0x32, { KEY_MUTE } },
- { KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
- { KE_KEY, 0x30, { KEY_VOLUMEUP } },
{ KE_IGNORE, NOTIFY_BRNDOWN_MIN, { KEY_BRIGHTNESSDOWN } },
{ KE_IGNORE, NOTIFY_BRNUP_MIN, { KEY_BRIGHTNESSUP } },
- { KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
+ { KE_KEY, 0x30, { KEY_VOLUMEUP } },
+ { KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
+ { KE_KEY, 0x32, { KEY_MUTE } },
+ { KE_KEY, 0x5c, { KEY_F15 } },
+ { KE_KEY, 0x5d, { KEY_WLAN } },
{ KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
+ { KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
+ { KE_KEY, 0xe0, { KEY_PROG1 } },
{ KE_KEY, 0xe1, { KEY_F14 } },
{ KE_KEY, 0xe9, { KEY_DISPLAY_OFF } },
- { KE_KEY, 0xe0, { KEY_PROG1 } },
- { KE_KEY, 0x5c, { KEY_F15 } },
{ KE_END, 0},
};
--
1.7.4.rc3
--
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-laptop: remove deprecated interfaces (lcd_switch and display_get)
From: Corentin Chary corentin.ch...@gmail.com
I should have done that one year ago, so it's more than
time to do it.
These two features use non-standard interfaces. There are the
only features that really need multiple path to guess what's
the right method name on a specific laptop.
Removing them allow to remove a lot of code an significantly
clean the driver.
This will affect the backlight code which won't be able to know
if the backlight is on or off.
The platform display file will also be write only (like the one
in eeepc-laptop).
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
Documentation/feature-removal-schedule.txt | 20
drivers/platform/x86/asus-laptop.c | 163 +---
2 files changed, 3 insertions(+), 180 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index f2742e1..810106d 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -403,26 +403,6 @@ Who: Tejun Heo t...@kernel.org
-What: Support for lcd_switch and display_get in asus-laptop driver
-When: March 2010
-Why: These two features use non-standard interfaces. There are the
- only features that really need multiple path to guess what's
- the right method name on a specific laptop.
-
- Removing them will allow to remove a lot of code an significantly
- clean the drivers.
-
- This will affect the backlight code which won't be able to know
- if the backlight is on or off. The platform display file will also be
- write only (like the one in eeepc-laptop).
-
- This should'nt affect a lot of user because they usually know
- when their display is on or off.
-
-Who: Corentin Chary corentin.ch...@gmail.com
-
-
-
What: sysfs-class-rfkill state file
When: Feb 2014
Files: net/rfkill/core.c
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index 1909685..6bfca85 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -158,46 +158,9 @@ MODULE_PARM_DESC(wwan_status, Set the wireless status on
boot
#define METHOD_BRIGHTNESS_SET SPLV
#define METHOD_BRIGHTNESS_GET GPLV
-/* Backlight */
-static acpi_handle lcd_switch_handle;
-static char *lcd_switch_paths[] = {
- \\_SB.PCI0.SBRG.EC0._Q10, /* All new models */
- \\_SB.PCI0.ISA.EC0._Q10, /* A1x */
- \\_SB.PCI0.PX40.ECD0._Q10, /* L3C */
- \\_SB.PCI0.PX40.EC0.Q10, /* M1A */
- \\_SB.PCI0.LPCB.EC0._Q10, /* P30 */
- \\_SB.PCI0.LPCB.EC0._Q0E, /* P30/P35 */
- \\_SB.PCI0.PX40.Q10, /* S1x */
- \\Q10};/* A2x, L2D, L3D, M2E */
-
/* Display */
#define METHOD_SWITCH_DISPLAY SDSP
-static acpi_handle display_get_handle;
-static char *display_get_paths[] = {
- /* A6B, A6K A6R A7D F3JM L4R M6R A3G M6A M6V VX-1 V6J V6V W3Z */
- \\_SB.PCI0.P0P1.VGA.GETD,
- /* A3E A4K, A4D A4L A6J A7J A8J Z71V M9V S5A M5A z33A W1Jc W2V G1 */
- \\_SB.PCI0.P0P2.VGA.GETD,
- /* A6V A6Q */
- \\_SB.PCI0.P0P3.VGA.GETD,
- /* A6T, A6M */
- \\_SB.PCI0.P0PA.VGA.GETD,
- /* L3C */
- \\_SB.PCI0.PCI1.VGAC.NMAP,
- /* Z96F */
- \\_SB.PCI0.VGA.GETD,
- /* A2D */
- \\ACTD,
- /* A4G Z71A W1N W5A W5F M2N M3N M5N M6N S1N S5N */
- \\ADVG,
- /* P30 */
- \\DNXT,
- /* A2H D1 L2D L3D L3H L2E L5D L5C M1A M2E L4L W3V */
- \\INFB,
- /* A3F A6F A3N A3L M6N W3N W6A */
- \\SSTE};
-
#define METHOD_ALS_CONTROL ALSC /* Z71A Z71V */
#define METHOD_ALS_LEVEL ALSL /* Z71A Z71V */
@@ -247,7 +210,6 @@ struct asus_laptop {
int wireless_status;
bool have_rsts;
- int lcd_state;
struct rfkill *gps_rfkill;
@@ -560,48 +522,6 @@ error:
/*
* Backlight device
*/
-static int asus_lcd_status(struct asus_laptop *asus)
-{
- return asus-lcd_state;
-}
-
-static int asus_lcd_set(struct asus_laptop *asus, int value)
-{
- int lcd = 0;
- acpi_status status = 0;
-
- lcd = !!value;
-
- if (lcd == asus_lcd_status(asus))
- return 0;
-
- if (!lcd_switch_handle)
- return -ENODEV;
-
- status = acpi_evaluate_object(lcd_switch_handle,
- NULL, NULL, NULL);
-
- if (ACPI_FAILURE(status)) {
- pr_warning(Error switching LCD\n);
- return -ENODEV;
- }
-
- asus-lcd_state = lcd;
- return 0;
-}
-
-static void lcd_blank(struct asus_laptop *asus, int blank)
-{
- struct backlight_device *bd = asus-backlight_device;
-
- asus-lcd_state = (blank == FB_BLANK_UNBLANK);
-
- if (bd) {
- bd-props.power = blank;
- backlight_update_status(bd);
- }
-}
-
static int asus_read_brightness(struct backlight_device *bd)
{
struct asus_laptop *asus = bl_get_data(bd);
@@ -629,16 +549,9 @@ static int asus_set_brightness(struct
Should asus-wmi provide a way to switch displays, and why video_output class is unused
Hi, In the ongoing effort to split eeepc-wmi, and add support for Asus WMI capable notebooks, I found that some of them are able to control dispay output. Currently, asus-laptop, asus_acpi and eeepc-laptop are also all able to do that, and they use a simple sysfs file with a bitmask to do that. Now, I was searching the right, generic way to do that, and I found video_output class. The issue is that nobody, even acpi/video.ko, use it. So, what's the right way to do that ? Note, that in my case, I can't know what output are available, so anyway, using video_output would be a little tricky. But still, I'm not really comfortable adding another cryptic sysfs file, even with proper documentation in Docuementation/ABI/. Thanks, -- Corentin Chary http://xf.iksaif.net -- 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 -next] eeepc-wmi: kconfig changes to fix build errors
On Tue, Feb 22, 2011 at 10:47 PM, Randy Dunlap randy.dun...@oracle.com wrote: From: Randy Dunlap randy.dun...@oracle.com Fix eeepc-wmi build when CONFIG_HOTPLUG_PCI is not enabled: eeepc-wmi.c:(.text+0x3bc5e9): undefined reference to `pci_hp_deregister' eeepc-wmi.c:(.text+0x3bcca4): undefined reference to `__pci_hp_register' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/platform/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) --- linux-next-20110222.orig/drivers/platform/x86/Kconfig +++ linux-next-20110222/drivers/platform/x86/Kconfig @@ -447,6 +447,7 @@ config EEEPC_WMI depends on EXPERIMENTAL depends on BACKLIGHT_CLASS_DEVICE depends on RFKILL || RFKILL = n + depends on HOTPLUG_PCI select INPUT_SPARSEKMAP select LEDS_CLASS select NEW_LEDS Sorry for that... Acked-by: Corentin Chary corentin.ch...@gmail.com -- Corentin Chary http://xf.iksaif.net -- 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] eeepc-wmi: set the touchpad toggle key code to F21
On Fri, Feb 25, 2011 at 6:19 AM, Keng-Yu Lin keng-yu@canonical.com wrote:
Signed-off-by: Keng-Yu Lin keng-yu@canonical.com
---
drivers/platform/x86/eeepc-wmi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
https://bugs.freedesktop.org/show_bug.cgi?id=31333
diff --git a/drivers/platform/x86/eeepc-wmi.c
b/drivers/platform/x86/eeepc-wmi.c
index d399775..da00cbc 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -113,7 +113,7 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_KEY, 0x32, { KEY_MUTE } },
{ KE_KEY, 0x5c, { KEY_F15 } }, /* Power Gear key */
{ KE_KEY, 0x5d, { KEY_WLAN } },
- { KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
+ { KE_KEY, 0x6b, { KEY_F21 } }, /* Disable Touchpad */
{ KE_KEY, 0x82, { KEY_CAMERA } },
{ KE_KEY, 0x83, { KEY_CAMERA_ZOOMIN } },
{ KE_KEY, 0x88, { KEY_WLAN } },
Hum, I'm not very comfortable with this patch now that we got
KEY_TOUCHPAD_TOGGLE.
I know, it doesn't work with current Xorg, but if we continue to
workaround that, it'll never be fixed.
Dmitry, Matthew, any advice ?
--
Corentin Chary
http://xf.iksaif.net
--
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/14] Support Asus WMI capable Notebooks (asus-wmi, asus-nb-wmi and eeepc-wmi)
Hi Matthew, I hope this series won't break anything, because there are a lot of change. Two new modules, asus-wmi.ko and asus-nb-wmi.ko, and almost all the code of eeepc-wmi.c is now in asus-wmi.c. I was able to test asus-nb-wmi.ko on a very new G73 laptop over ssh, and it seems to work well. More features are comming (keyboard backlight, more sensors, etc...), but I think it's important to merge the first step as soon as possible. Thanks, Corentin Chary (14): asus-wmi: move generic code to asus-wmi eeepc-wmi: asus generic asus-wmi.ko module asus-wmi: minor cleanups asus-wmi: introduce struct asus_rfkill asus-wmi: handle unknown status bit asus-wmi: factorise wmi_evaluate_method call asus-wmi: try to guess the right DSTS methods asus-wmi: fix and clean backlight code asus-wmi: add calls to INIT, SPEC and SFUN on init asus-wmi: allow debugfs interface to call arbitrary method asus-nb-wmi: Asus Notebooks WMI Driver asus-wmi: add some common device ids and method ids asus-wmi: add hwmon interface and pwm1 eeepc-wmi: restore KEY_CAMERA_* keys lost in 190ca27 Documentation/ABI/testing/sysfs-platform-asus-wmi | 31 + Documentation/ABI/testing/sysfs-platform-eeepc-wmi | 31 - MAINTAINERS| 30 +- drivers/platform/x86/Kconfig | 39 +- drivers/platform/x86/Makefile |2 + drivers/platform/x86/asus-nb-wmi.c | 98 ++ drivers/platform/x86/asus-wmi.c| 1655 drivers/platform/x86/asus-wmi.h| 58 + drivers/platform/x86/eeepc-wmi.c | 1372 + 9 files changed, 1924 insertions(+), 1392 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-asus-wmi delete mode 100644 Documentation/ABI/testing/sysfs-platform-eeepc-wmi create mode 100644 drivers/platform/x86/asus-nb-wmi.c create mode 100644 drivers/platform/x86/asus-wmi.c create mode 100644 drivers/platform/x86/asus-wmi.h -- 1.7.4 -- 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/14] asus-wmi: handle unknown status bit
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index d0f0931..39ce3c1 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -92,6 +92,7 @@ MODULE_LICENSE(GPL);
/* DSTS masks */
#define ASUS_WMI_DSTS_STATUS_BIT 0x0001
+#define ASUS_WMI_DSTS_UNKNOWN_BIT 0x0002
#define ASUS_WMI_DSTS_PRESENCE_BIT 0x0001
#define ASUS_WMI_DSTS_BRIGHTNESS_MASK 0x00FF
#define ASUS_WMI_DSTS_MAX_BRIGTH_MASK 0xFF00
@@ -270,6 +271,11 @@ static int asus_wmi_get_devstate_bits(u32 dev_id, u32 mask)
if (!(retval ASUS_WMI_DSTS_PRESENCE_BIT))
return -ENODEV;
+ if (mask == ASUS_WMI_DSTS_STATUS_BIT) {
+ if (retval ASUS_WMI_DSTS_UNKNOWN_BIT)
+ return -ENODEV;
+ }
+
return retval mask;
}
--
1.7.4
--
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/14] asus-wmi: add some common device ids and method ids
I also found some leds ids (0x00020011-0x00020016 and 0x00040015), but since they are not really present on the notebook, I can't guess their name . Signed-off-by: Corentin Chary corenti...@iksaif.net --- drivers/platform/x86/asus-wmi.c | 44 -- 1 files changed, 37 insertions(+), 7 deletions(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index 9095c28..05db6b2 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -66,25 +66,46 @@ MODULE_LICENSE(GPL); #define NOTIFY_BRNDOWN_MAX 0x2e /* WMI Methods */ -#define ASUS_WMI_METHODID_SPEC 0x43455053 -#define ASUS_WMI_METHODID_SFUN 0x4E554653 -#define ASUS_WMI_METHODID_DSTS 0x53544344 -#define ASUS_WMI_METHODID_DSTS20x53545344 -#define ASUS_WMI_METHODID_DEVS 0x53564544 -#define ASUS_WMI_METHODID_CFVS 0x53564643 -#define ASUS_WMI_METHODID_INIT 0x54494E49 +#define ASUS_WMI_METHODID_SPEC 0x43455053 /* BIOS SPECification */ +#define ASUS_WMI_METHODID_SFBD 0x44424653 /* Set First Boot Device */ +#define ASUS_WMI_METHODID_GLCD 0x44434C47 /* Get LCD status */ +#define ASUS_WMI_METHODID_GPID 0x44495047 /* Get Panel ID?? (Resol) */ +#define ASUS_WMI_METHODID_QMOD 0x444F4D51 /* Quiet MODe */ +#define ASUS_WMI_METHODID_SPLV 0x4C425053 /* Set Panel Light Value */ +#define ASUS_WMI_METHODID_SFUN 0x4E554653 /* FUNCtionalities */ +#define ASUS_WMI_METHODID_SDSP 0x50534453 /* Set DiSPlay output */ +#define ASUS_WMI_METHODID_GDSP 0x50534447 /* Get DiSPlay output */ +#define ASUS_WMI_METHODID_DEVP 0x50564544 /* DEVice Policy */ +#define ASUS_WMI_METHODID_OSVR 0x5256534F /* OS VeRsion */ +#define ASUS_WMI_METHODID_DSTS 0x53544344 /* Device STatuS */ +#define ASUS_WMI_METHODID_DSTS20x53545344 /* Device STatuS #2*/ +#define ASUS_WMI_METHODID_BSTS 0x53545342 /* Bios STatuS ? */ +#define ASUS_WMI_METHODID_DEVS 0x53564544 /* DEVice Set */ +#define ASUS_WMI_METHODID_CFVS 0x53564643 /* CPU Frequency Volt Set */ +#define ASUS_WMI_METHODID_KBFT 0x5446424B /* KeyBoard FilTer */ +#define ASUS_WMI_METHODID_INIT 0x54494E49 /* INITialize */ +#define ASUS_WMI_METHODID_HKEY 0x59454B48 /* Hot KEY ?? */ #define ASUS_WMI_UNSUPPORTED_METHOD0xFFFE /* Wireless */ +#define ASUS_WMI_DEVID_HW_SWITCH 0x00010001 +#define ASUS_WMI_DEVID_WIRELESS_LED0x00010002 #define ASUS_WMI_DEVID_WLAN0x00010011 #define ASUS_WMI_DEVID_BLUETOOTH 0x00010013 +#define ASUS_WMI_DEVID_GPS 0x00010015 #define ASUS_WMI_DEVID_WIMAX 0x00010017 #define ASUS_WMI_DEVID_WWAN3G 0x00010019 +#define ASUS_WMI_DEVID_UWB 0x00010021 + +/* Leds */ +/* 0x000200XX and 0x000400XX */ /* Backlight and Brightness */ #define ASUS_WMI_DEVID_BACKLIGHT 0x00050011 #define ASUS_WMI_DEVID_BRIGHTNESS 0x00050012 +#define ASUS_WMI_DEVID_KBD_BACKLIGHT 0x00050021 +#define ASUS_WMI_DEVID_LIGHT_SENSOR0x00050022 /* ?? */ /* Misc */ #define ASUS_WMI_DEVID_CAMERA 0x00060013 @@ -96,10 +117,19 @@ MODULE_LICENSE(GPL); #define ASUS_WMI_DEVID_TOUCHPAD0x00100011 #define ASUS_WMI_DEVID_TOUCHPAD_LED0x00100012 +/* Fan, Thermal */ +#define ASUS_WMI_DEVID_THERMAL_CTRL0x00110011 +#define ASUS_WMI_DEVID_FAN_CTRL0x00110012 + +/* Power */ +#define ASUS_WMI_DEVID_PROCESSOR_STATE 0x00120012 + /* DSTS masks */ #define ASUS_WMI_DSTS_STATUS_BIT 0x0001 #define ASUS_WMI_DSTS_UNKNOWN_BIT 0x0002 #define ASUS_WMI_DSTS_PRESENCE_BIT 0x0001 +#define ASUS_WMI_DSTS_USER_BIT 0x0002 +#define ASUS_WMI_DSTS_BIOS_BIT 0x0004 #define ASUS_WMI_DSTS_BRIGHTNESS_MASK 0x00FF #define ASUS_WMI_DSTS_MAX_BRIGTH_MASK 0xFF00 -- 1.7.4 -- 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/14] eeepc-wmi: restore KEY_CAMERA_* keys lost in 190ca27
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-wmi.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index e69701f..64e36de 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -65,11 +65,17 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_KEY, 0x5d, { KEY_WLAN } },
{ KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
{ KE_KEY, 0x82, { KEY_CAMERA } },
+ { KE_KEY, 0x83, { KEY_CAMERA_ZOOMIN } },
{ KE_KEY, 0x88, { KEY_WLAN } },
{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
{ KE_KEY, 0xe0, { KEY_PROG1 } }, /* Task Manager */
{ KE_KEY, 0xe1, { KEY_F14 } }, /* Change Resolution */
{ KE_KEY, 0xe9, { KEY_BRIGHTNESS_ZERO } },
+ { KE_KEY, 0xeb, { KEY_CAMERA_ZOOMOUT } },
+ { KE_KEY, 0xec, { KEY_CAMERA_UP } },
+ { KE_KEY, 0xed, { KEY_CAMERA_DOWN } },
+ { KE_KEY, 0xee, { KEY_CAMERA_LEFT } },
+ { KE_KEY, 0xef, { KEY_CAMERA_RIGHT } },
{ KE_END, 0},
};
--
1.7.4
--
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/14] asus-wmi: fix and clean backlight code
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c | 44 +-
1 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index fd5b08ee..adf7b05 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -765,9 +765,8 @@ static int read_backlight_power(struct asus_wmi *asus)
return ret ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
}
-static int read_brightness(struct backlight_device *bd)
+static int read_brightness_max(struct asus_wmi *asus)
{
- struct asus_wmi *asus = bl_get_data(bd);
u32 retval;
int err;
@@ -776,6 +775,25 @@ static int read_brightness(struct backlight_device *bd)
if (err 0)
return err;
+ retval = retval ASUS_WMI_DSTS_MAX_BRIGTH_MASK;
+ retval = 8;
+
+ if (!retval)
+ return -ENODEV;
+
+ return retval;
+}
+
+static int read_brightness(struct backlight_device *bd)
+{
+ struct asus_wmi *asus = bl_get_data(bd);
+ u32 retval, err;
+
+ err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_BRIGHTNESS, retval);
+
+ if (err 0)
+ return err;
+
return retval ASUS_WMI_DSTS_BRIGHTNESS_MASK;
}
@@ -799,7 +817,7 @@ static int update_bl_status(struct backlight_device *bd)
err = asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT,
ctrl_param, NULL);
}
- return 0;
+ return err;
}
static const struct backlight_ops asus_wmi_bl_ops = {
@@ -832,23 +850,19 @@ static int asus_wmi_backlight_init(struct asus_wmi *asus)
int max;
int power;
- max = asus_wmi_get_devstate_bits(asus, ASUS_WMI_DEVID_BRIGHTNESS,
-ASUS_WMI_DSTS_MAX_BRIGTH_MASK);
- power = read_backlight_power(asus);
+ max = read_brightness_max(asus);
- if (max 0 power 0) {
- /* Try to keep the original error */
- if (max == -ENODEV power == -ENODEV)
- return -ENODEV;
- if (max != -ENODEV)
- return max;
- else
- return power;
- }
if (max == -ENODEV)
max = 0;
+ else if (max 0)
+ return max;
+
+ power = read_backlight_power(asus);
+
if (power == -ENODEV)
power = FB_BLANK_UNBLANK;
+ else if (power 0)
+ return power;
memset(props, 0, sizeof(struct backlight_properties));
props.max_brightness = max;
--
1.7.4
--
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/14] asus-wmi: add calls to INIT, SPEC and SFUN on init
INIT() call is needed to enable hotkeys on G73
SPEC() and SFUN() allow us to know more about
available features.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index adf7b05..88596ea 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -66,10 +66,13 @@ MODULE_LICENSE(GPL);
#define NOTIFY_BRNDOWN_MAX 0x2e
/* WMI Methods */
+#define ASUS_WMI_METHODID_SPEC 0x43455053
+#define ASUS_WMI_METHODID_SFUN 0x4E554653
#define ASUS_WMI_METHODID_DSTS 0x53544344
#define ASUS_WMI_METHODID_DSTS20x53545344
#define ASUS_WMI_METHODID_DEVS 0x53564544
#define ASUS_WMI_METHODID_CFVS 0x53564643
+#define ASUS_WMI_METHODID_INIT 0x54494E49
#define ASUS_WMI_UNSUPPORTED_METHOD0xFFFE
@@ -126,6 +129,8 @@ struct asus_rfkill {
struct asus_wmi {
int dsts_id;
+ int spec;
+ int sfun;
struct input_dev *inputdev;
struct backlight_device *backlight_device;
@@ -1065,6 +1070,29 @@ static int asus_wmi_sysfs_init(struct platform_device
*device)
*/
static int __init asus_wmi_platform_init(struct asus_wmi *asus)
{
+ int rv;
+
+ /* INIT enable hotkeys on some models */
+ if (!asus_wmi_evaluate_method(ASUS_WMI_METHODID_INIT, 0, 0, rv))
+ pr_info(Initialization: %#x, rv);
+
+ /* We don't know yet what to do with this version... */
+ if (!asus_wmi_evaluate_method(ASUS_WMI_METHODID_SPEC, 0, 0x9, rv)) {
+ pr_info(BIOS WMI version: %d.%d, rv 8, rv 0xFF);
+ asus-spec = rv;
+ }
+
+ /*
+* The SFUN method probably allows the original driver to get the list
+* of features supported by a given model. For now, 0x0100 or 0x0800
+* bit signifies that the laptop is equipped with a Wi-Fi MiniPCI card.
+* The significance of others is yet to be found.
+*/
+ if (!asus_wmi_evaluate_method(ASUS_WMI_METHODID_SFUN, 0, 0, rv)) {
+ pr_info(SFUN value: %#x, rv);
+ asus-sfun = rv;
+ }
+
/*
* Eee PC and Notebooks seems to have different method_id for DSTS,
* but it may also be related to the BIOS's SPEC.
--
1.7.4
--
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/14] asus-wmi: allow debugfs interface to call arbitrary method
Also add some # format flags to debugfs output.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c | 47 +-
1 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 88596ea..9095c28 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -112,11 +112,14 @@ struct bios_args {
* platform/- debugfs root directory
* dev_id - current dev_id
* ctrl_param - current ctrl_param
+ * method_id - current method_id
* devs- call DEVS(dev_id, ctrl_param) and print result
* dsts- call DSTS(dev_id) and print result
+ * call- call method_id(dev_id, ctrl_param) and print result
*/
struct asus_wmi_debug {
struct dentry *root;
+ u32 method_id;
u32 dev_id;
u32 ctrl_param;
};
@@ -1138,7 +1141,7 @@ static int show_dsts(struct seq_file *m, void *data)
if (err 0)
return err;
- seq_printf(m, DSTS(%x) = %x\n, asus-debug.dev_id, retval);
+ seq_printf(m, DSTS(%#x) = %#x\n, asus-debug.dev_id, retval);
return 0;
}
@@ -1155,15 +1158,50 @@ static int show_devs(struct seq_file *m, void *data)
if (err 0)
return err;
- seq_printf(m, DEVS(%x, %x) = %x\n, asus-debug.dev_id,
+ seq_printf(m, DEVS(%#x, %#x) = %#x\n, asus-debug.dev_id,
asus-debug.ctrl_param, retval);
return 0;
}
+static int show_call(struct seq_file *m, void *data)
+{
+ struct asus_wmi *asus = m-private;
+ struct bios_args args = {
+ .arg0 = asus-debug.dev_id,
+ .arg1 = asus-debug.ctrl_param,
+ };
+ struct acpi_buffer input = { (acpi_size) sizeof(args), args };
+ struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ acpi_status status;
+
+ status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
+1, asus-debug.method_id,
+input, output);
+
+ if (ACPI_FAILURE(status))
+ return -EIO;
+
+ obj = (union acpi_object *)output.pointer;
+ if (obj obj-type == ACPI_TYPE_INTEGER)
+ seq_printf(m, %#x(%#x, %#x) = %#x\n, asus-debug.method_id,
+ asus-debug.dev_id, asus-debug.ctrl_param,
+ (u32) obj-integer.value);
+ else
+ seq_printf(m, %#x(%#x, %#x) = t:%d\n, asus-debug.method_id,
+ asus-debug.dev_id, asus-debug.ctrl_param,
+ obj-type);
+
+ kfree(obj);
+
+ return 0;
+}
+
static struct asus_wmi_debugfs_node asus_wmi_debug_files[] = {
{NULL, devs, show_devs},
{NULL, dsts, show_dsts},
+ {NULL, call, show_call},
};
static int asus_wmi_debugfs_open(struct inode *inode, struct file *file)
@@ -1197,6 +1235,11 @@ static int asus_wmi_debugfs_init(struct asus_wmi *asus)
goto error_debugfs;
}
+ dent = debugfs_create_x32(method_id, S_IRUGO | S_IWUSR,
+ asus-debug.root, asus-debug.method_id);
+ if (!dent)
+ goto error_debugfs;
+
dent = debugfs_create_x32(dev_id, S_IRUGO | S_IWUSR,
asus-debug.root, asus-debug.dev_id);
if (!dent)
--
1.7.4
--
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/14] asus-wmi: add hwmon interface and pwm1
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/Kconfig|1 +
drivers/platform/x86/asus-wmi.c | 128 +++
2 files changed, 129 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index cd65dac..486f016 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -440,6 +440,7 @@ config ASUS_WMI
tristate ASUS WMI Driver (EXPERIMENTAL)
depends on ACPI_WMI
depends on INPUT
+ depends on HWMON
depends on EXPERIMENTAL
depends on BACKLIGHT_CLASS_DEVICE
depends on RFKILL || RFKILL = n
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 05db6b2..5b779a9 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -39,6 +39,8 @@
#include linux/rfkill.h
#include linux/pci.h
#include linux/pci_hotplug.h
+#include linux/hwmon.h
+#include linux/hwmon-sysfs.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/platform_device.h
@@ -167,6 +169,7 @@ struct asus_wmi {
struct input_dev *inputdev;
struct backlight_device *backlight_device;
+ struct device *hwmon_device;
struct platform_device *platform_device;
struct led_classdev tpd_led;
@@ -791,6 +794,124 @@ exit:
}
/*
+ * Hwmon device
+ */
+static ssize_t asus_hwmon_pwm1(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct asus_wmi *asus = dev_get_drvdata(dev);
+ u32 value;
+ int err;
+
+ err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_FAN_CTRL, value);
+
+ if (err 0)
+ return err;
+
+ value |= 0xFF;
+
+ if (value == 1) /* Low Speed */
+ value = 85;
+ else if (value == 2)
+ value = 170;
+ else if (value == 3)
+ value = 255;
+ else if (value != 0) {
+ pr_err(Unknown fan speed %#x, value);
+ value = -1;
+ }
+
+ return sprintf(buf, %d\n, value);
+}
+
+static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO, asus_hwmon_pwm1, NULL, 0);
+
+static ssize_t
+show_name(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, asus\n);
+}
+static SENSOR_DEVICE_ATTR(name, S_IRUGO, show_name, NULL, 0);
+
+static struct attribute *hwmon_attributes[] = {
+ sensor_dev_attr_pwm1.dev_attr.attr,
+ sensor_dev_attr_name.dev_attr.attr,
+ NULL
+};
+
+static mode_t asus_hwmon_sysfs_is_visible(struct kobject *kobj,
+ struct attribute *attr, int idx)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct platform_device *pdev = to_platform_device(dev-parent);
+ struct asus_wmi *asus = platform_get_drvdata(pdev);
+ bool ok = true;
+ int dev_id = -1;
+ u32 value = ASUS_WMI_UNSUPPORTED_METHOD;
+
+ if (attr == sensor_dev_attr_pwm1.dev_attr.attr)
+ dev_id = ASUS_WMI_DEVID_FAN_CTRL;
+
+ if (dev_id != -1) {
+ int err = asus_wmi_get_devstate(asus, dev_id, value);
+
+ if (err 0)
+ return err;
+ }
+
+ if (dev_id == ASUS_WMI_DEVID_FAN_CTRL) {
+ /*
+* We need to find a better way, probably using sfun,
+* bits or spec ...
+* Currently we disable it if:
+* - ASUS_WMI_UNSUPPORTED_METHOD is returned
+* - reverved bits are non-zero
+* - sfun and presence bit are not set
+*/
+ if (value != ASUS_WMI_UNSUPPORTED_METHOD || value 0xFFF8
+ || (!asus-sfun !(value ASUS_WMI_DSTS_PRESENCE_BIT)))
+ ok = false;
+ }
+
+ return ok ? attr-mode : 0;
+}
+
+static struct attribute_group hwmon_attribute_group = {
+ .is_visible = asus_hwmon_sysfs_is_visible,
+ .attrs = hwmon_attributes
+};
+
+static void asus_wmi_hwmon_exit(struct asus_wmi *asus)
+{
+ struct device *hwmon;
+
+ hwmon = asus-hwmon_device;
+ if (!hwmon)
+ return;
+ sysfs_remove_group(hwmon-kobj, hwmon_attribute_group);
+ hwmon_device_unregister(hwmon);
+ asus-hwmon_device = NULL;
+}
+
+static int asus_wmi_hwmon_init(struct asus_wmi *asus)
+{
+ struct device *hwmon;
+ int result;
+
+ hwmon = hwmon_device_register(asus-platform_device-dev);
+ if (IS_ERR(hwmon)) {
+ pr_err(Could not register asus hwmon device\n);
+ return PTR_ERR(hwmon);
+ }
+ asus-hwmon_device = hwmon;
+ result = sysfs_create_group(hwmon-kobj, hwmon_attribute_group);
+ if (result)
+ asus_wmi_hwmon_exit(asus);
+ return result;
+}
+
+/*
* Backlight
*/
static int read_backlight_power(struct
[PATCH 06/14] asus-wmi: factorise wmi_evaluate_method call
This patch create a single function to call the
WMI methods. This function handle inexistent methods (when
implemented by the WMI devices, and this is not the case on
Eee PCs), ACPI errors, etc..
Also pack struct bios_arg, and make sure that we always send
a 64bit buffer when calling a WMI method, because this is
needed on Asus notebooks.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c | 162 ---
1 files changed, 65 insertions(+), 97 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 39ce3c1..34e6b4d 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -70,6 +70,8 @@ MODULE_LICENSE(GPL);
#define ASUS_WMI_METHODID_DEVS 0x53564544
#define ASUS_WMI_METHODID_CFVS 0x53564643
+#define ASUS_WMI_UNSUPPORTED_METHOD0xFFFE
+
/* Wireless */
#define ASUS_WMI_DEVID_WLAN0x00010011
#define ASUS_WMI_DEVID_BLUETOOTH 0x00010013
@@ -98,9 +100,9 @@ MODULE_LICENSE(GPL);
#define ASUS_WMI_DSTS_MAX_BRIGTH_MASK 0xFF00
struct bios_args {
- u32 dev_id;
- u32 ctrl_param;
-};
+ u32 arg0;
+ u32 arg1;
+} __packed;
/*
* platform/- debugfs root directory
@@ -187,20 +189,24 @@ static void asus_wmi_input_exit(struct asus_wmi *asus)
asus-inputdev = NULL;
}
-static acpi_status asus_wmi_get_devstate(u32 dev_id, u32 *retval)
+static int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
+ u32 *retval)
{
- struct acpi_buffer input = { (acpi_size) sizeof(u32), dev_id };
+ struct bios_args args = {
+ .arg0 = arg0,
+ .arg1 = arg1,
+ };
+ struct acpi_buffer input = { (acpi_size) sizeof(args), args };
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
- union acpi_object *obj;
acpi_status status;
+ union acpi_object *obj;
u32 tmp;
- status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
-1, ASUS_WMI_METHODID_DSTS,
+ status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 1, method_id,
input, output);
if (ACPI_FAILURE(status))
- return status;
+ goto exit;
obj = (union acpi_object *)output.pointer;
if (obj obj-type == ACPI_TYPE_INTEGER)
@@ -213,60 +219,39 @@ static acpi_status asus_wmi_get_devstate(u32 dev_id, u32
*retval)
kfree(obj);
- return status;
+exit:
+ if (ACPI_FAILURE(status))
+ return -EIO;
+
+ if (tmp == ASUS_WMI_UNSUPPORTED_METHOD)
+ return -ENODEV;
+ return 0;
}
-static acpi_status asus_wmi_set_devstate(u32 dev_id, u32 ctrl_param,
-u32 *retval)
+static int asus_wmi_get_devstate(u32 dev_id, u32 *retval)
{
- struct bios_args args = {
- .dev_id = dev_id,
- .ctrl_param = ctrl_param,
- };
- struct acpi_buffer input = { (acpi_size) sizeof(args), args };
- acpi_status status;
-
- if (!retval) {
- status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 1,
-ASUS_WMI_METHODID_DEVS,
-input, NULL);
- } else {
- struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
- union acpi_object *obj;
- u32 tmp;
-
- status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 1,
-ASUS_WMI_METHODID_DEVS,
-input, output);
-
- if (ACPI_FAILURE(status))
- return status;
-
- obj = (union acpi_object *)output.pointer;
- if (obj obj-type == ACPI_TYPE_INTEGER)
- tmp = (u32) obj-integer.value;
- else
- tmp = 0;
-
- *retval = tmp;
-
- kfree(obj);
- }
+ return asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS, dev_id,
+ 0, retval);
+}
- return status;
+static int asus_wmi_set_devstate(u32 dev_id, u32 ctrl_param,
+u32 *retval)
+{
+ return asus_wmi_evaluate_method(ASUS_WMI_METHODID_DEVS, dev_id,
+ ctrl_param, retval);
}
/* Helper for special devices with magic return codes */
static int asus_wmi_get_devstate_bits(u32 dev_id, u32 mask)
{
u32 retval = 0;
- acpi_status status;
+ int err;
- status = asus_wmi_get_devstate(dev_id, retval);
+ err = asus_wmi_get_devstate(dev_id, retval);
- if (ACPI_FAILURE(status))
- return -EINVAL;
+ if (err 0)
+ return err;
if (!(retval
[PATCH 04/14] asus-wmi: introduce struct asus_rfkill
First, this allow use to remove the custom asusrfkill_wlan_query,
but this will also allow us to give struct asus_wmi * to
get_devstate/set_devstate later.
Signed-off-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c | 115 ---
1 files changed, 59 insertions(+), 56 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 4c3f68a..d0f0931 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -114,6 +114,12 @@ struct asus_wmi_debug {
u32 ctrl_param;
};
+struct asus_rfkill {
+ struct asus_wmi *asus;
+ struct rfkill *rfkill;
+ u32 dev_id;
+};
+
struct asus_wmi {
struct input_dev *inputdev;
struct backlight_device *backlight_device;
@@ -124,10 +130,10 @@ struct asus_wmi {
struct workqueue_struct *led_workqueue;
struct work_struct tpd_led_work;
- struct rfkill *wlan_rfkill;
- struct rfkill *bluetooth_rfkill;
- struct rfkill *wimax_rfkill;
- struct rfkill *wwan3g_rfkill;
+ struct asus_rfkill wlan;
+ struct asus_rfkill bluetooth;
+ struct asus_rfkill wimax;
+ struct asus_rfkill wwan3g;
struct hotplug_slot *hotplug_slot;
struct mutex hotplug_lock;
@@ -377,8 +383,8 @@ static void asus_rfkill_hotplug(struct asus_wmi *asus)
mutex_lock(asus-hotplug_lock);
- if (asus-wlan_rfkill)
- rfkill_set_sw_state(asus-wlan_rfkill, blocked);
+ if (asus-wlan.rfkill)
+ rfkill_set_sw_state(asus-wlan.rfkill, blocked);
if (asus-hotplug_slot) {
bus = pci_find_bus(0, 1);
@@ -570,11 +576,11 @@ error_workqueue:
*/
static int asus_rfkill_set(void *data, bool blocked)
{
- int dev_id = (unsigned long)data;
+ struct asus_rfkill *priv = data;
u32 ctrl_param = !blocked;
acpi_status status;
- status = asus_wmi_set_devstate(dev_id, ctrl_param, NULL);
+ status = asus_wmi_set_devstate(priv-dev_id, ctrl_param, NULL);
if (ACPI_FAILURE(status))
return -EIO;
@@ -584,20 +590,21 @@ static int asus_rfkill_set(void *data, bool blocked)
static void asus_rfkill_query(struct rfkill *rfkill, void *data)
{
- int dev_id = (unsigned long)data;
+ struct asus_rfkill *priv = data;
int result;
- result = asus_wmi_get_devstate_simple(dev_id);
+ result = asus_wmi_get_devstate_simple(priv-dev_id);
if (result 0)
return;
- rfkill_set_sw_state(rfkill, !result);
+ rfkill_set_sw_state(priv-rfkill, !result);
}
static int asus_rfkill_wlan_set(void *data, bool blocked)
{
- struct asus_wmi *asus = data;
+ struct asus_rfkill *priv = data;
+ struct asus_wmi *asus = priv-asus;
int ret;
/*
@@ -608,19 +615,14 @@ static int asus_rfkill_wlan_set(void *data, bool blocked)
* any wmi method
*/
mutex_lock(asus-wmi_lock);
- ret = asus_rfkill_set((void *)(long)ASUS_WMI_DEVID_WLAN, blocked);
+ ret = asus_rfkill_set(data, blocked);
mutex_unlock(asus-wmi_lock);
return ret;
}
-static void asus_rfkill_wlan_query(struct rfkill *rfkill, void *data)
-{
- asus_rfkill_query(rfkill, (void *)(long)ASUS_WMI_DEVID_WLAN);
-}
-
static const struct rfkill_ops asus_rfkill_wlan_ops = {
.set_block = asus_rfkill_wlan_set,
- .query = asus_rfkill_wlan_query,
+ .query = asus_rfkill_query,
};
static const struct rfkill_ops asus_rfkill_ops = {
@@ -629,20 +631,24 @@ static const struct rfkill_ops asus_rfkill_ops = {
};
static int asus_new_rfkill(struct asus_wmi *asus,
- struct rfkill **rfkill,
+ struct asus_rfkill *arfkill,
const char *name, enum rfkill_type type, int dev_id)
{
int result = asus_wmi_get_devstate_simple(dev_id);
+ struct rfkill **rfkill = arfkill-rfkill;
if (result 0)
return result;
+ arfkill-dev_id = dev_id;
+ arfkill-asus = asus;
+
if (dev_id == ASUS_WMI_DEVID_WLAN asus-driver-hotplug_wireless)
*rfkill = rfkill_alloc(name, asus-platform_device-dev, type,
- asus_rfkill_wlan_ops, asus);
+ asus_rfkill_wlan_ops, arfkill);
else
*rfkill = rfkill_alloc(name, asus-platform_device-dev, type,
- asus_rfkill_ops, (void *)(long)dev_id);
+ asus_rfkill_ops, arfkill);
if (!*rfkill)
return -EINVAL;
@@ -662,10 +668,10 @@ static void asus_wmi_rfkill_exit(struct asus_wmi *asus)
asus_unregister_rfkill_notifier(asus, \\_SB.PCI0.P0P5);
asus_unregister_rfkill_notifier(asus, \\_SB.PCI0.P0P6);
asus_unregister_rfkill_notifier(asus
Re: eeepc: rfkill on 900A defunct
On Tue, Mar 8, 2011 at 10:06 AM, Jiri Slaby jirisl...@gmail.com wrote: On 02/28/2011 10:49 AM, Jiri Slaby wrote: On 11/24/2010 09:18 PM, Matthew Garrett wrote: Hm. As a shorter term fix, can you try this (entirely untested!) approach? What is the status of this? Was there any alternative merged? Ping. Because this is Matthew's patch, and I have no hardware to test that patch, I'm not touching it. Jiri, on what models was this patch tested (only got 701 and 901 here) ? Matthew, will you merge this patch in your tree ? Thanks, -- Corentin Chary http://xf.iksaif.net -- 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: [ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features
Hi Thomas, Do you think handling really vendor specific boosts like EeePC's SHE is in cpupower scope This is an oem/vendor specific way to modify the front-side-bus throughput on (Intel atom only?) eeepc like machines (acer, asus and others?)? I don't know exactly what it does, but yes it seems to modify the fsb (and possibly something else on some models, who know ...), and it's only specific to Asus EeePCs. But Asus notebooks seems to have a similar Power4Gear function, that may also overclock/downclock the gpu. You could try to experiment with registering your own delayed work queue in eeepc-laptopc.c and try to find best tunings and fittings for such requirements. If it works out and/or other xy-laptop.c or whatever drivers provide similar functionality it could get moved up into a more generic framework. A separate one next to cpuidle and cpufreq, for example fsb_mod? I'll see if other platform drivers have something similar, but I believe that at least one of them has a peformance mode. PS: Wouldn't the cpufreq subsystem suffice to register for this SHE thing? Could it be that SHE and real CPU freq (speedstep) is mutual exclusive? Is the only problem that p4_clockmod cannot be loaded then? p4_clockmod is only loaded on olds EeePCs. New ones are using acpi-cpufreq. And you can only load one cpufreq driver at a time. -- Corentin Chary http://xf.iksaif.net -- 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] asus-wmi: potential NULL dereference in show_call()
On Tue, Mar 15, 2011 at 8:07 AM, Dan Carpenter erro...@gmail.com wrote: In the earlier check we assumed that obj could be NULL. I looked at some of the other places that call evaluate_object() and they check for NULL as well. Signed-off-by: Dan Carpenter erro...@gmail.com --- Can obj actually be NULL here? Perhaps a better fix would be to remove the first check. Yes I think it can. diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index a038595..efc776c 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -1343,7 +1343,7 @@ static int show_call(struct seq_file *m, void *data) else seq_printf(m, %#x(%#x, %#x) = t:%d\n, asus-debug.method_id, asus-debug.dev_id, asus-debug.ctrl_param, - obj-type); + obj ? obj-type : -1); Seems ok, I may change that later if we need to support more types. Acked-by: Corentin Chary corentin.ch...@gmail.com -- Corentin Chary http://xf.iksaif.net -- 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] eeepc-wmi: Add support for T101MT Express Gate key
On Wed, Mar 23, 2011 at 8:39 PM, Seth Forshee seth.fors...@canonical.com wrote: Signed-off-by: Seth Forshee seth.fors...@canonical.com --- This button is unusual. On press it emits scanocde 0xe4, on release 0xe5, and when held for a few seconds it begins emitting 0xea about twice per second. I chose to handle only the press event in order to make it behave like the other hotkeys. Probably the closest thing to the intended function of this button would be to alternate the display orientation between portrait and landscape, but since there doesn't appear to be a keycode defined for that function I went with KEY_PROG2. I'm open to other suggestions however. Hi, The manual says that under Windows, this is the Home Key, so KEY_HOME would be more appropriate. Also, it would be great to preserve key up and key down informations (sparse keymap have an autorelease parameter to control that). Thanks, -- Corentin Chary http://xf.iksaif.net -- 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 support for T101MT Home/Express Gate key
Here is how I envision using these keys. I wanted to map quick press
to GNOME3/KDE4/Unity's Activities menu and map press-and-hold to
script that rotates screen. I like the repeating of rotates but I
didn't really want a rotate to also force a pop up of the activities
menu.
Makes sense.
And back to the question of KEY_HOME -- that's not really what you want,
is it? As in move cursor to start of line?
Ho .. right, that's what mean KEY_HOME :/. So no, I don't want that...
What about:
- KEY_CYCLEWINDOWS
- KEY_COMPUTER
- KEY_HOMEPAGE
- KEY_DASHBOARD
I think KEY_HOMEPAGE is the best choice.
I've only had limited time to look more. So far, I found under udev a
toshiba tablet that maps what is probably a rotate button to
KEY_DIRECTION so thats one option for it instead of KEY_PROG2. I
couldn't find anybody using that though.
I see in /usr/share/X11/symbols/inet:
key I162 { [ XF86RotateWindows ] };
and in /usr/share/X11/xkb/symbols/evdev:
xkb/keycodes/evdev: I162 = 162; // #define KEY_CYCLEWINDOWS 154
Looks like KEY_CYCLEWINDOWS is already hooked up to
gnome-settings-daemon to auto-rotate screen?
XF86RotateWindows is probably more alt-tab than rotate screen.
I ran into total dead end for finding a pre-existing example of home
button usage. I'm really surprised we do not yet have a KEY_LAUNCHER
or similar because so many tablet PCs/smartphones/pads do have a
button with this specific concept of bring up your icon based
application launcher.
KEY_LAUNCHER sounds like Alt-F2 (that means krunner on KDE).
The advantage over KEY_HOMEPAGE is that it would work even when a
browser have the focus.
- KEY_MENU
- KEY_EXIT (smartphones sometime mean this)
- KEY_PROG3 (basically all that Windows is doing)
- KEY_LAUNCHER (why not be the first to finally create it!)
I vote for either KEY_PROG3 or KEY_HOMEPAGE for at least short term.
So now, I vote (in order):
- KEY_LAUNCHER
- KEY_DASHBOARD
- KEY_PROG3
With this behavior (I'll use KEY_LAUCHER and KEY_PROG2)
- On press, do nothing
- On release, emit KEY_LAUNCHER if KEY_PROG2 wasn't emited
- On press, emit only one KEY_PROG2 (I'd like to emit repeated
KEY_PROG2, but I understand that it makes things harder for
userspace).
--
Corentin Chary
http://xf.iksaif.net
--
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 v3 2/3] eeepc-wmi: Add support for T101MT Home/Express Gate key
On Mon, Mar 28, 2011 at 6:33 PM, Seth Forshee
seth.fors...@canonical.com wrote:
This key is different than other hotkeys, having seperate scan
codes for press, release, and hold, so it requires some special
filtering. Press and release events are passed on, and hold events
are ignored since sparse-keymap does not support hardware
autorepeat.
Note that Home in the context of this button doesn't mean the
same thing as the usual Home key, and it really isn't clear at
all what is meant by Home. The manufacurer's description of the
button indicates that it should launch some sort of touch screen
settings interface on short press and apply a desktop rotation on
long press.
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/platform/x86/eeepc-wmi.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c
b/drivers/platform/x86/eeepc-wmi.c
index 0ddc434..8f3112d5 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -56,6 +56,11 @@ MODULE_PARM_DESC(hotplug_wireless,
If your laptop needs that, please report to
acpi4asus-u...@lists.sourceforge.net.);
+/* Values for T101MT Home key */
+#define HOME_PRESS 0xe4
+#define HOME_HOLD 0xea
+#define HOME_RELEASE 0xe5
+
static const struct key_entry eeepc_wmi_keymap[] = {
/* Sleep already handled via generic ACPI code */
{ KE_KEY, 0x30, { KEY_VOLUMEUP } },
@@ -70,6 +75,7 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
{ KE_KEY, 0xe0, { KEY_PROG1 } }, /* Task Manager */
{ KE_KEY, 0xe1, { KEY_F14 } }, /* Change Resolution */
+ { KE_KEY, HOME_PRESS, { KEY_CONFIG } },
What X11 key is mapped to KEY_CONFIG ?
{ KE_KEY, 0xe9, { KEY_BRIGHTNESS_ZERO } },
{ KE_KEY, 0xeb, { KEY_CAMERA_ZOOMOUT } },
{ KE_KEY, 0xec, { KEY_CAMERA_UP } },
@@ -79,6 +85,25 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_END, 0},
};
+static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code,
+ unsigned int *value, bool *autorelease)
+{
+ switch (*code) {
+ case HOME_PRESS:
+ *value = 1;
+ *autorelease = 0;
+ break;
+ case HOME_HOLD:
+ *code = ASUS_WMI_KEY_IGNORE;
+ break;
+ case HOME_RELEASE:
+ *code = HOME_PRESS;
+ *value = 0;
+ *autorelease = 0;
+ break;
+ }
+}
+
static acpi_status eeepc_wmi_parse_device(acpi_handle handle, u32 level,
void *context, void **retval)
{
@@ -149,6 +174,7 @@ static struct asus_wmi_driver asus_wmi_driver = {
.keymap = eeepc_wmi_keymap,
.input_name = Eee PC WMI hotkeys,
.input_phys = EEEPC_WMI_FILE /input0,
+ .key_filter = eeepc_wmi_key_filter,
.probe = eeepc_wmi_probe,
.quirks = eeepc_wmi_quirks,
};
--
1.7.4.1
I think this version is ok,
Matthew, do you think this should be delayed for 2.6.40 (merge window
will close soon, so now it's probably time for fix only) ?
--
Corentin Chary
http://xf.iksaif.net
--
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 00/23] drivers/platform/x86: Remove warnings and use pr_level
On Tue, Mar 29, 2011 at 10:21 PM, Joe Perches j...@perches.com wrote: Removed a couple of compilation warnings. Use pr_level consistently. Did you do that using coccinelle or by hand ? If you used coccinelle, is the .cocci file available ? If not, you should try it :). Joe Perches (23): asus-wmi: Remove __init from asus_wmi_platform_init ibm_rtl: Remove warnings from casts of pointer to int acer-wmi: pr_level cleanups asus: Add pr_fmt and convert printks to pr_level compal-laptop: Convert printks to pr_level dell: Convert printks to pr_level eeepc: Use pr_warn fujitsu-laptop: Convert printks to pr_level hdaps: Convert printks to pr_level hp-wmi: Convert printks to pr_level ibm_rtl: Use pr_fmt and pr_level ideapad-laptop: Add pr_fmt intel_menlow: Add pr_fmt and use pr_level intel_pmic_gpio: Convert printks to pr_level msi-laptop: pr_level neatening msi-wmi: Use pr_fmt and pr_level sony-laptop: Add and use #define pr_fmt tc1100-wmi: Add pr_fmt, use pr_level thinkpad_acpi: Convert printks to pr_level topstar-laptop: Convert remaining printk to pr_info toshiba: Convert printks to pr_level wmi: Removed trailing whitespace from logging message. xo15-ebook: Use pr_level drivers/platform/x86/acer-wmi.c | 32 +- drivers/platform/x86/asus-laptop.c | 34 +- drivers/platform/x86/asus-wmi.c | 22 +- drivers/platform/x86/asus_acpi.c | 77 ++--- drivers/platform/x86/compal-laptop.c | 22 +- drivers/platform/x86/dell-laptop.c | 12 +- drivers/platform/x86/dell-wmi-aio.c | 3 +- drivers/platform/x86/dell-wmi.c | 17 +- drivers/platform/x86/eeepc-laptop.c | 20 +- drivers/platform/x86/eeepc-wmi.c | 14 +- drivers/platform/x86/fujitsu-laptop.c | 39 ++-- drivers/platform/x86/hdaps.c | 19 +- drivers/platform/x86/hp-wmi.c | 43 +-- drivers/platform/x86/ibm_rtl.c | 23 +- drivers/platform/x86/ideapad-laptop.c | 2 + drivers/platform/x86/intel_menlow.c | 5 +- drivers/platform/x86/intel_pmic_gpio.c | 14 +- drivers/platform/x86/msi-laptop.c | 9 +- drivers/platform/x86/msi-wmi.c | 45 ++-- drivers/platform/x86/sony-laptop.c | 104 +++ drivers/platform/x86/tc1100-wmi.c | 7 +- drivers/platform/x86/thinkpad_acpi.c | 471 -- drivers/platform/x86/topstar-laptop.c | 2 +- drivers/platform/x86/toshiba_acpi.c | 59 ++-- drivers/platform/x86/toshiba_bluetooth.c | 11 +- drivers/platform/x86/wmi.c | 10 +- drivers/platform/x86/xo15-ebook.c | 5 +- 27 files changed, 495 insertions(+), 626 deletions(-) -- 1.7.4.2.g597a6.dirty -- 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 -- Corentin Chary http://xf.iksaif.net -- 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/3] asus-laptop: remove removed features from feature-removal-schedule.txt
commit 3b81cf9d558c57406b4ed9b0d2639113d1d428b6 removed those features. Signed-off-by: Corentin Chary corentin.ch...@gmail.com --- Documentation/feature-removal-schedule.txt | 20 1 files changed, 0 insertions(+), 20 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 274b32d..492e81d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -387,26 +387,6 @@ Who: Tejun Heo t...@kernel.org -What: Support for lcd_switch and display_get in asus-laptop driver -When: March 2010 -Why: These two features use non-standard interfaces. There are the - only features that really need multiple path to guess what's - the right method name on a specific laptop. - - Removing them will allow to remove a lot of code an significantly - clean the drivers. - - This will affect the backlight code which won't be able to know - if the backlight is on or off. The platform display file will also be - write only (like the one in eeepc-laptop). - - This should'nt affect a lot of user because they usually know - when their display is on or off. - -Who: Corentin Chary corentin.ch...@gmail.com - - - What: sysfs-class-rfkill state file When: Feb 2014 Files: net/rfkill/core.c -- 1.7.3.4 -- 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/3] asus-wmi: swap input name and phys
Signed-off-by: Corentin Chary corentin.ch...@gmail.com --- drivers/platform/x86/asus-wmi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index efc776c..832a3fd7 100644 --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -201,8 +201,8 @@ static int asus_wmi_input_init(struct asus_wmi *asus) if (!asus-inputdev) return -ENOMEM; - asus-inputdev-name = asus-driver-input_phys; - asus-inputdev-phys = asus-driver-input_name; + asus-inputdev-name = asus-driver-input_name; + asus-inputdev-phys = asus-driver-input_phys; asus-inputdev-id.bustype = BUS_HOST; asus-inputdev-dev.parent = asus-platform_device-dev; -- 1.7.3.4 -- 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/3] eeepc-wmi: add keys found on EeePC 1215T
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
drivers/platform/x86/eeepc-wmi.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 0ddc434..649dcad 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -67,9 +67,11 @@ static const struct key_entry eeepc_wmi_keymap[] = {
{ KE_KEY, 0x82, { KEY_CAMERA } },
{ KE_KEY, 0x83, { KEY_CAMERA_ZOOMIN } },
{ KE_KEY, 0x88, { KEY_WLAN } },
+ { KE_KEY, 0xbd, { KEY_CAMERA } },
{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
{ KE_KEY, 0xe0, { KEY_PROG1 } }, /* Task Manager */
{ KE_KEY, 0xe1, { KEY_F14 } }, /* Change Resolution */
+ { KE_KEY, 0xe8, { KEY_SCREENLOCK } },
{ KE_KEY, 0xe9, { KEY_BRIGHTNESS_ZERO } },
{ KE_KEY, 0xeb, { KEY_CAMERA_ZOOMOUT } },
{ KE_KEY, 0xec, { KEY_CAMERA_UP } },
--
1.7.3.4
--
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 01/23] asus-wmi: Remove __init from asus_wmi_platform_init
On Wed, Mar 30, 2011 at 12:21 AM, Joe Perches j...@perches.com wrote:
It's used by a non-init function.
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-wmi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index efc776c..c382af6 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1223,7 +1223,7 @@ static int asus_wmi_sysfs_init(struct platform_device
*device)
/*
* Platform device
*/
-static int __init asus_wmi_platform_init(struct asus_wmi *asus)
+static int asus_wmi_platform_init(struct asus_wmi *asus)
{
int rv;
--
1.7.4.2.g597a6.dirty
--
Corentin Chary
http://xf.iksaif.net
--
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 04/23] asus: Add pr_fmt and convert printks to pr_level
On Wed, Mar 30, 2011 at 12:21 AM, Joe Perches j...@perches.com wrote:
Add pr_fmt, prefixes each log message.
Convert printks to pr_level.
Convert pr_warning to pr_warn.
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/asus-laptop.c | 34
drivers/platform/x86/asus-wmi.c | 20 +-
drivers/platform/x86/asus_acpi.c | 77
+++-
3 files changed, 59 insertions(+), 72 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index c53b3ff..d65df92 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -318,7 +318,7 @@ static int acpi_check_handle(acpi_handle handle, const
char *method,
if (status != AE_OK) {
if (ret)
- pr_warning(Error finding %s\n, method);
+ pr_warn(Error finding %s\n, method);
return -ENODEV;
}
return 0;
@@ -383,7 +383,7 @@ static int asus_kled_lvl(struct asus_laptop *asus)
rv = acpi_evaluate_integer(asus-handle, METHOD_KBD_LIGHT_GET,
params, kblv);
if (ACPI_FAILURE(rv)) {
- pr_warning(Error reading kled level\n);
+ pr_warn(Error reading kled level\n);
return -ENODEV;
}
return kblv;
@@ -397,7 +397,7 @@ static int asus_kled_set(struct asus_laptop *asus, int
kblv)
kblv = 0;
if (write_acpi_int(asus-handle, METHOD_KBD_LIGHT_SET, kblv)) {
- pr_warning(Keyboard LED display write failed\n);
+ pr_warn(Keyboard LED display write failed\n);
return -EINVAL;
}
return 0;
@@ -531,7 +531,7 @@ static int asus_read_brightness(struct backlight_device
*bd)
rv = acpi_evaluate_integer(asus-handle, METHOD_BRIGHTNESS_GET,
NULL, value);
if (ACPI_FAILURE(rv))
- pr_warning(Error reading brightness\n);
+ pr_warn(Error reading brightness\n);
return value;
}
@@ -541,7 +541,7 @@ static int asus_set_brightness(struct backlight_device
*bd, int value)
struct asus_laptop *asus = bl_get_data(bd);
if (write_acpi_int(asus-handle, METHOD_BRIGHTNESS_SET, value)) {
- pr_warning(Error changing brightness\n);
+ pr_warn(Error changing brightness\n);
return -EIO;
}
return 0;
@@ -730,7 +730,7 @@ static ssize_t store_ledd(struct device *dev, struct
device_attribute *attr,
rv = parse_arg(buf, count, value);
if (rv 0) {
if (write_acpi_int(asus-handle, METHOD_LEDD, value)) {
- pr_warning(LED display write failed\n);
+ pr_warn(LED display write failed\n);
return -ENODEV;
}
asus-ledd_status = (u32) value;
@@ -752,7 +752,7 @@ static int asus_wireless_status(struct asus_laptop *asus,
int mask)
rv = acpi_evaluate_integer(asus-handle, METHOD_WL_STATUS,
NULL, status);
if (ACPI_FAILURE(rv)) {
- pr_warning(Error reading Wireless status\n);
+ pr_warn(Error reading Wireless status\n);
return -EINVAL;
}
return !!(status mask);
@@ -764,7 +764,7 @@ static int asus_wireless_status(struct asus_laptop *asus,
int mask)
static int asus_wlan_set(struct asus_laptop *asus, int status)
{
if (write_acpi_int(asus-handle, METHOD_WLAN, !!status)) {
- pr_warning(Error setting wlan status to %d, status);
+ pr_warn(Error setting wlan status to %d\n, status);
return -EIO;
}
return 0;
@@ -792,7 +792,7 @@ static ssize_t store_wlan(struct device *dev, struct
device_attribute *attr,
static int asus_bluetooth_set(struct asus_laptop *asus, int status)
{
if (write_acpi_int(asus-handle, METHOD_BLUETOOTH, !!status)) {
- pr_warning(Error setting bluetooth status to %d, status);
+ pr_warn(Error setting bluetooth status to %d\n, status);
return -EIO;
}
return 0;
@@ -821,7 +821,7 @@ static ssize_t store_bluetooth(struct device *dev,
static int asus_wimax_set(struct asus_laptop *asus, int status)
{
if (write_acpi_int(asus-handle, METHOD_WIMAX, !!status)) {
- pr_warning(Error setting wimax status to %d, status);
+ pr_warn(Error setting wimax status to %d\n, status);
return -EIO;
}
return 0;
@@ -850,7 +850,7 @@ static ssize_t store_wimax(struct device *dev,
static int asus_wwan_set(struct asus_laptop *asus, int status)
{
if (write_acpi_int(asus-handle, METHOD_WWAN, !!status
Re: [PATCH 07/23] eeepc: Use pr_warn
On Wed, Mar 30, 2011 at 12:21 AM, Joe Perches j...@perches.com wrote:
Just a trivial pr_warning to pr_warn conversion
while adding a few missing newlines.
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Corentin Chary corenti...@iksaif.net
---
drivers/platform/x86/eeepc-laptop.c | 20 ++--
drivers/platform/x86/eeepc-wmi.c | 14 +++---
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index 5f2dd38..e5feadd 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -228,7 +228,7 @@ static int set_acpi(struct eeepc_laptop *eeepc, int cm,
int value)
return -ENODEV;
if (write_acpi_int(eeepc-handle, method, value))
- pr_warning(Error writing %s\n, method);
+ pr_warn(Error writing %s\n, method);
return 0;
}
@@ -243,7 +243,7 @@ static int get_acpi(struct eeepc_laptop *eeepc, int cm)
return -ENODEV;
if (read_acpi_int(eeepc-handle, method, value))
- pr_warning(Error reading %s\n, method);
+ pr_warn(Error reading %s\n, method);
return value;
}
@@ -261,7 +261,7 @@ static int acpi_setter_handle(struct eeepc_laptop *eeepc,
int cm,
status = acpi_get_handle(eeepc-handle, (char *)method,
handle);
if (status != AE_OK) {
- pr_warning(Error finding %s\n, method);
+ pr_warn(Error finding %s\n, method);
return -ENODEV;
}
return 0;
@@ -417,7 +417,7 @@ static ssize_t store_cpufv_disabled(struct device *dev,
switch (value) {
case 0:
if (eeepc-cpufv_disabled)
- pr_warning(cpufv enabled (not officially supported
+ pr_warn(cpufv enabled (not officially supported
on this model)\n);
eeepc-cpufv_disabled = false;
return rv;
@@ -601,7 +601,7 @@ static void eeepc_rfkill_hotplug(struct eeepc_laptop
*eeepc)
if (eeepc-hotplug_slot) {
bus = pci_find_bus(0, 1);
if (!bus) {
- pr_warning(Unable to find PCI bus 1?\n);
+ pr_warn(Unable to find PCI bus 1?\n);
goto out_unlock;
}
@@ -612,12 +612,12 @@ static void eeepc_rfkill_hotplug(struct eeepc_laptop
*eeepc)
absent = (l == 0x);
if (blocked != absent) {
- pr_warning(BIOS says wireless lan is %s,
- but the pci device is %s\n,
+ pr_warn(BIOS says wireless lan is %s,
+ but the pci device is %s\n,
blocked ? blocked : unblocked,
absent ? absent : present);
- pr_warning(skipped wireless hotplug as probably
- inappropriate for this model\n);
+ pr_warn(skipped wireless hotplug as probably
+ inappropriate for this model\n);
goto out_unlock;
}
@@ -671,7 +671,7 @@ static int eeepc_register_rfkill_notifier(struct
eeepc_laptop *eeepc,
eeepc_rfkill_notify,
eeepc);
if (ACPI_FAILURE(status))
- pr_warning(Failed to register notify on %s\n, node);
+ pr_warn(Failed to register notify on %s\n, node);
} else
return -ENODEV;
diff --git a/drivers/platform/x86/eeepc-wmi.c
b/drivers/platform/x86/eeepc-wmi.c
index 0ddc434..4155884 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -82,7 +82,7 @@ static const struct key_entry eeepc_wmi_keymap[] = {
static acpi_status eeepc_wmi_parse_device(acpi_handle handle, u32 level,
void *context, void **retval)
{
- pr_warning(Found legacy ATKD device (%s), EEEPC_ACPI_HID);
+ pr_warn(Found legacy ATKD device (%s)\n, EEEPC_ACPI_HID);
*(bool *)context = true;
return AE_CTRL_TERMINATE;
}
@@ -103,12 +103,12 @@ static int eeepc_wmi_check_atkd(void)
static int eeepc_wmi_probe(struct platform_device *pdev)
{
if (eeepc_wmi_check_atkd()) {
- pr_warning(WMI device present, but legacy ATKD device is
also
- present and enabled.);
- pr_warning(You probably booted with acpi_osi=\Linux\ or
- acpi_osi=\!Windows 2009\);
- pr_warning(Can't load eeepc-wmi, use default acpi_osi
Re: [PATCH 3/4] asus-laptop: Pegatron Lucid accelerometer
test platform printk
On Mon, Mar 28, 2011 at 3:36 PM, Andy Ross andy.r...@windriver.com wrote:
[combined responses for clarity]
Corentin Chary wrote:
Wow :/ How long is an acpi_evaluate_integer call here ?
Early on I benchmarked the per-axis ACPI calls about about 50us, which
is shockingly high to me. But honestly that note there is just
pedantry: the hi/lo race (and the fact that errors live in the same
space with valid data values) is a real condition that lets me justify
the retry on large deltas behavior, which most definitely improves
data quality.
Ok,
When is asus_platform_probe called exactly ? Because I'd say it's
called during asus_platform_probe(), and that doesn't fix your issue
right ?
Admittedly this is voodoo. Moving the input_polldev device
initialization to asus_laptop (originally in asus_acpi_add(), which is
called out of the ACPI framwwork) caused reliable panics on boot. I
moved it to asus_platform_probe() to restore the structure of the
original pega_accel module, which did it in a platform probe.
I don't know enough about the platform driver model to say exactly,
but I strongly suspect that platform probe calls are not done
synchronously underneath the platform_{device|driver}_register()
calls.
I'll check that this weekend.
Dmitry Torokhov wrote:
This I do not quite understand... Do we bind acpi drivers to devices
before ACPI initialization is done? Then this should be fixed in
ACPI layer, but I doubt even early userspace is active at the time
ACPI core is being initialized. Also, input polling is done in a
separate thread so you not moving the poll out of ACPI binding
thread but delay poll execution by a few microseconds...
See comments above. The current model in asus-laptop is to register
its keyboard input device underneat the .add callback in the acpi
driver. That was crashing with the accelerometer.
And there's definitely a userspace interaction: disabling the sensor
daemon (the distro in question is a MeeGo tablet image) at startup
avoided the crash (and in fact worked fine when started up manually
later).
Just to try to fix the crash in a more cleaner way, can you (re-)tell
us more about it ? It's a kernel crash, or the hardware just start
doing stupid things ? Any traces ? Does it also happens when you load
the model *after* boot (blacklist it, then modprobe) ? Could you also
re-send me the dsdt ? I think I lost it.
Thanks,
--
Corentin Chary
http://xf.iksaif.net
--
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 3/4] asus-laptop: Pegatron Lucid accelerometer
On Thu, Apr 7, 2011 at 5:56 PM, Anisse Astier ani...@astier.eu wrote: On Mon, 4 Apr 2011 17:16:05 +, Corentin Chary corentin.ch...@gmail.com wrote : On Thu, Mar 31, 2011 at 7:23 AM, Corentin Chary corentin.ch...@gmail.com wrote: snip Just to try to fix the crash in a more cleaner way, can you (re-)tell us more about it ? It's a kernel crash, or the hardware just start doing stupid things ? Any traces ? Does it also happens when you load the model *after* boot (blacklist it, then modprobe) ? Could you also re-send me the dsdt ? I think I lost it. ping ? I have a Pegatron Lucid. Please find the DSDT attached. Thanks for the DSDT. After a quick read I didn't find anything in it that could produce the crash. I'll wait for Andy's answers. -- Corentin Chary http://xf.iksaif.net -- 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: asus-wmi for Asus G73SW
By default the brightness values are set to 10 (max_brightness) but changing any of them does not do anything (display stays at maximum brightness level). Do you have an idea what could be missing? [...] I used acpi_backlight=vendor and /sys/class/backlight/asus-nb-wmi shows up as expected. Also the kernel code that sets the brightness value in the asus-nb-wmi driver works (no error is returned, also the changed values show up in sysfs). It just does not seem to get applied. I found out that if after I switch to the console (alt+F1) changing the brightness in sysfs suddenly does have an effect. Since I use the proprietary nvidia driver (for full OpenGL 3D support) I suspect that it has something to do with it. I tried the Kubuntu Live installer CD which uses nouveau and changing the brightness works for Xorg there, too (even using the generic acpi_backlight code and the brightness value in acpi_video1). I guess the Nvidia driver or something related to it is doing something nasty here which keeps the brightness from being applied. Switching back to Xorg from the console resets the value to 10 (I added some debug output to update_bl_status) so that's not a workaround unfortunately. Since I have no idea what actual piece of hardware controls the backlight I wonder if it is part of the NVidia hardware and as soon as the nvidia driver takes over it will no longer accept updates from the BIOS? Unfortunatly I didn't found anything in the DSDT. CCing Zhang Rui, maybe he can help us here. -- Corentin Chary http://xf.iksaif.net -- 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
What's the state of i915: Add native backlight controllogin register about ?
Hi Matthew, Recently I got a lot of complaint from people that wanted to use the backlight to be as dim as on windows or their EeePC. It seems that setpci -s 00:02.0 f4.b=ff do the trick, but I don't really want to advertise this method. I believe that https://patchwork.kernel.org/patch/480141/ (and the rest the the series) would fix the issue in a more cleaner way. I didn't found any re-send or new version., what's the current status of this series ? Thanks, -- Corentin Chary http://xf.iksaif.net -- 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] asus-laptop: Remove historic reminder of the pre sparse-keymap era
On Mon, May 9, 2011 at 6:47 PM, Anisse Astier ani...@astier.eu wrote:
Back when every driver managed it's own sparse keymap directly,
asus_laptop needed to keep track of its keymap. Not anymore.
Signed-off-by: Anisse Astier ani...@astier.eu
---
drivers/platform/x86/asus-laptop.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index c53b3ff..0379798 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -198,7 +198,6 @@ struct asus_laptop {
struct backlight_device *backlight_device;
struct input_dev *inputdev;
- struct key_entry *keymap;
struct asus_led mled;
struct asus_led tled;
--
1.7.4.3
I remember writing the exact same patch, but it seems that it was lost.
Acked-by: Corentin Chary corenti...@iksaif.net
--
Corentin Chary
http://xf.iksaif.net
--
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] x86: Don't enable EEEPC_LAPTOP in default configs
On Thu, May 19, 2011 at 1:54 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, May 19, 2011 at 01:47:01PM +0200, Jean Delvare wrote: Can someone explain why CONFIG_EEEPC_LAPTOP=y in x86/configs/*_defconfig when all other laptop support is off by default? Linus owns an Eee? Then it's probably not a 901 or a 701, and CONFIG_EEEPC_WMI=y should be used instead :). -- Corentin Chary http://xf.iksaif.net -- 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/4] acer-wmi: check the existence of internal 3G device when set capability
On Sun, May 22, 2011 at 2:02 AM, Joey Lee j...@novell.com wrote: 於 日，2011-05-22 於 00:43 +0100，Carlos Corbacho 提到： On Sunday 22 May 2011 00:33:52 Lee, Chun-Yi wrote: That will be better to check the existence of internal 3G device when we set threeg capability and generate killswitch for threeg. It can avoid userland access 3G rfkill but the machine doesn't have internal 3G device. Reference: bko#32862 https://bugzilla.kernel.org/show_bug.cgi?id=32862 Tested on Acer Aspire 8930G, Acer Travelmate 8572 Tested-by: Hector Martin hec...@marcansoft.com Acked-by: Carlos Corbacho car...@strangeworlds.co.uk If you can now autodetect 3G and already have the relevant rfkill device, then you should also rip out the remaining sysfs support for it as it's no longer necessary. -Carlos Got it! I will send another patch to remove threeg sysfs file. I'm not sure you can drop sysfs files like that, as it will break the ABI. Could you document acer-wmi in Documentation/ABI/testing/sysfs-platform-acer-wmi.txt ? This allows to check when a sysfs file was added, who use it, etc... Thanks, -- Corentin Chary http://xf.iksaif.net -- 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/4] acer-wmi: check the existence of internal 3G device when set capability
On Mon, May 23, 2011 at 8:41 AM, Carlos Corbacho car...@strangeworlds.co.uk wrote: On Monday 23 May 2011 07:39:36 Joey Lee wrote: I'm not sure you can drop sysfs files like that, as it will break the ABI. Could you document acer-wmi in Documentation/ABI/testing/sysfs-platform-acer-wmi.txt ? This allows to check when a sysfs file was added, who use it, etc... I don't agree, the 3G sysfs interface should just be dropped as it's the only remaining sysfs stuff for this driver - it's not worth documenting as it's already exposed as an rfkill device, and we've already dropped all the remaining sysfs interfaces a long time ago without going through any of this. Besides, anybody who used it (and I never could find any 3G users of Acer laptops on Linux) was never guaranteed it wouldn't break horribly anyway as we couldn't properly autodetect 3G in the past or knew much about it other than Acer's WMI API suggested it existed. I asked for documentation because I didn't check if there were other sysfs files remaining, if it's the last, we don't really care. I did a quick search, and you're right, this file doesn't seems to have a lot of user, but it would still break the ABI without any notice. I would be more confortable with one or two cycle with this feature marked as deprecated and scheduled for removal. -- Corentin Chary http://xf.iksaif.net -- 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 3/3] ideapad: Show negative when no camera
On Thu, Jun 2, 2011 at 11:24 AM, Ike Panhc ike@canonical.com wrote:
Signed-off-by: Ike Panhc ike@canonical.com
---
drivers/platform/x86/ideapad-laptop.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 9c09891..4a54ed1 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -38,6 +38,7 @@
#define CFG_BT_BIT (16)
#define CFG_3G_BIT (17)
#define CFG_WIFI_BIT (18)
+#define CFG_CAMERA_BIT (19)
struct ideapad_private {
struct rfkill *rfk[IDEAPAD_RFKILL_DEV_NUM];
@@ -199,6 +200,10 @@ static ssize_t show_ideapad_cam(struct device *dev,
struct device_attribute *attr,
char *buf)
{
+ struct ideapad_private *priv = dev_get_drvdata(dev);
+
+ if (!test_bit(CFG_CAMERA_BIT, (priv-cfg)))
+ return sprintf(buf, -1\n);
return show_ideapad_helper(dev, attr, buf, 0x1D);
}
--
1.7.4.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
I think it would be better to not add the file when the camera is not
available. Another option is to return -ENODEV. But printing -1
doesn't seems right.
--
Corentin Chary
http://xf.iksaif.net
--
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
