[PATCH] wmi: Set wmi devices' parents

Without this patch, wmi devices are in /sys/virtual/wmi. They're logically children of the ACPI WMI device, so slot them into the device hierarchy. With this change, on my laptop, they end up in /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C14:00/wmi and

Re: [PATCH] dell-rbtn: Ignore ACPI notifications if device is suspended

On Mon, Nov 23, 2015 at 03:48:58PM +0100, Pali Rohár wrote: > On Saturday 21 November 2015 15:16:15 Gabriele Mazzotta wrote: > > Some BIOSes unconditionally send an ACPI notification to RBTN when the > > system is resuming from suspend. This makes dell-rbtn send an input > > event to userspace as

Re: [PATCH] wmi: Set wmi devices' parents

On Mon, Nov 23, 2015 at 11:25:30AM -0800, Andy Lutomirski wrote: > Without this patch, wmi devices are in /sys/virtual/wmi. They're > logically children of the ACPI WMI device, so slot them into the > device hierarchy. With this change, on my laptop, they end up in >

Re: [PATCH v2] dell-wmi: Improve unknown hotkey handling

On Friday 20 November 2015 17:27:00 Andy Lutomirski wrote: > + if (keycode == KEY_RESERVED) { > + pr_info("firmware scancode %d maps to unrecognized > keycode %d\n", > + bios_entry->scancode, bios_entry->keycode); > +

Re: [PATCH 1/1] apple-gmux: Assign apple_gmux_data before registering

On Mon, Nov 16, 2015 at 09:38:40PM +0100, Lukas Wunner wrote: > From: Matthew Garrett > > Registering the handler after both GPUs will trigger a DDC switch for > connector reprobing. This will oops if apple_gmux_data hasn't already > been assigned. Reorder the code to

Re: Regression with dell-rbtn: radio killed on resume after suspend to RAM

On Mon, Nov 23, 2015 at 07:23:29PM +0300, Andrei Borzenkov wrote: > 23.11.2015 18:14, Gabriele Mazzotta пишет: > >On 23/11/2015 15:50, Pali Rohár wrote: > >>On Sunday 22 November 2015 09:23:19 Andrei Borzenkov wrote: > >>>21.11.2015 23:39, Andrei Borzenkov пишет: > 21.11.2015 22:08, Pali Rohár

Re: [PATCH v2] dell-wmi: Improve unknown hotkey handling

On Mon, Nov 23, 2015 at 10:47 AM, Darren Hart wrote: > On Mon, Nov 23, 2015 at 03:56:43PM +0100, Pali Rohár wrote: >> On Friday 20 November 2015 17:30:13 Andy Lutomirski wrote: >> > On Fri, Nov 20, 2015 at 5:27 PM, Andy Lutomirski wrote: >> > > If DMI lists

Re: [PATCH 2/5] eeepc-wmi: Use acpi_dev_present

Hi Darren, On Mon, Nov 23, 2015 at 11:04:13AM -0800, Darren Hart wrote: > On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote: > > Use shiny new acpi_dev_present and remove all the boilerplate to search > > for a particular ACPI device. No functional change. > > You did add a pr_warn,

Re: [PATCH] wmi: Set wmi devices' parents

Works for me. -- Matthew Garrett | mj...@srcf.ucam.org -- 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/5] ACPICA: Add acpi_dev_present

There are 7 drivers which call acpi_get_devices to check for the presence of a particular ACPI HID, each defining its own copy of a mostly identical callback. Add acpi_dev_present, the ACPI equivalent to pci_dev_present, allowing us to deduplicate all that boilerplate in the drivers.

[PATCH 2/5] eeepc-wmi: Use acpi_dev_present

Use shiny new acpi_dev_present and remove all the boilerplate to search for a particular ACPI device. No functional change. Cc: Corentin Chary Signed-off-by: Lukas Wunner --- drivers/platform/x86/eeepc-wmi.c | 24 ++-- 1 file

[PATCH 0/5] Add acpi_dev_present

Hi everyone, I need to detect the presence of apple-gmux (ACPI HID "APP000B") in several DRM drivers to handle backlight, runtime pm and deferred probing properly. There's an idiom in use by 7 other drivers to detect presence of a particular ACPI HID which involves calling acpi_get_devices() and

[PATCH 3/5] acer-wmi: Use acpi_dev_present

Use shiny new acpi_dev_present and remove all the boilerplate to search for a particular ACPI device. No functional change. Cc: Lee, Chun-Yi Signed-off-by: Lukas Wunner --- drivers/platform/x86/acer-wmi.c | 16 1 file changed, 4 insertions(+),

Re: [PATCH] dell-rbtn: Ignore ACPI notifications if device is suspended

On Saturday 21 November 2015 15:16:15 Gabriele Mazzotta wrote: > Some BIOSes unconditionally send an ACPI notification to RBTN when the > system is resuming from suspend. This makes dell-rbtn send an input > event to userspace as if a function key was pressed. Prevent this by > ignoring all the

Re: [PATCH 1/5] ACPICA: Add acpi_dev_present

On Monday, November 23, 2015 03:34:55 PM Lukas Wunner wrote: > There are 7 drivers which call acpi_get_devices to check for the > presence of a particular ACPI HID, each defining its own copy of > a mostly identical callback. > > Add acpi_dev_present, the ACPI equivalent to pci_dev_present, >

RE: [PATCH 1/5] ACPICA: Add acpi_dev_present

>>acpi_dev_present Do you really want to be walking the ACPICA namespace for every call? > -Original Message- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Monday, November 23, 2015 2:35 PM > To: Lukas Wunner > Cc: linux-a...@vger.kernel.org; de...@acpica.org;

Re: Regression with dell-rbtn: radio killed on resume after suspend to RAM

On 23/11/2015 20:29, Darren Hart wrote: [cut] I looked at what dell-rbtn does. My system (Latitude E5450) has RBTN of type TOGGLE. In this case both del-laptop hooks itself into i8042 and dell-rbtn delivers KEY_RFKILL event to input susbsystem. IOW dell-rbtn looks completely redundant in this

Re: [PATCH 2/5] eeepc-wmi: Use acpi_dev_present

On Monday, November 23, 2015 11:04:13 AM Darren Hart wrote: > On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote: > > Use shiny new acpi_dev_present and remove all the boilerplate to search > > for a particular ACPI device. No functional change. > > You did add a pr_warn, which is

Re: [PATCH 1/5] ACPICA: Add acpi_dev_present

On 2015/11/24 7:32, Lukas Wunner wrote: > Hi Robert, > > On Mon, Nov 23, 2015 at 10:22:27PM +, Moore, Robert wrote: acpi_dev_present >> Do you really want to be walking the ACPICA namespace for every call? > That's what the drivers currently do. Typically this is called only once > on

Re: [PATCH 1/5] ACPICA: Add acpi_dev_present

Hi Robert, On Mon, Nov 23, 2015 at 10:22:27PM +, Moore, Robert wrote: > >>acpi_dev_present > > Do you really want to be walking the ACPICA namespace for every call? That's what the drivers currently do. Typically this is called only once on initialization by the driver's ->probe callback.

Re: Regression with dell-rbtn: radio killed on resume after suspend to RAM

On Sunday 22 November 2015 09:23:19 Andrei Borzenkov wrote: > 21.11.2015 23:39, Andrei Borzenkov пишет: > >21.11.2015 22:08, Pali Rohár пишет: > >>On Saturday 21 November 2015 19:57:18 Andrei Borzenkov wrote: > >>>After installing 4.2 on Dell Latitude E5450 I found that wireless was > >>>disabled

Re: [PATCH v2] dell-wmi: Improve unknown hotkey handling

On Friday 20 November 2015 17:30:13 Andy Lutomirski wrote: > On Fri, Nov 20, 2015 at 5:27 PM, Andy Lutomirski wrote: > > If DMI lists a hotkey that we don't recognize, log and ignore it > > instead of trying to map it to keycode 0. I haven't seen this happen, > > but it will

Re: [PATCH 1/3] dell_wmi: Support new hotkeys on the XPS 13 Skylake

On Saturday 21 November 2015 20:04:15 D. Jared Dominguez wrote: > On Fri, Nov 20, 2015 at 06:12:58PM -0600, Andy Lutomirski wrote: > >Jared, want to give us some guidance as to whether this code is > >correct at all and, if so, whether we should actually send a > >KEY_RFKILL event from dell-wmi

Re: Regression with dell-rbtn: radio killed on resume after suspend to RAM

23.11.2015 18:14, Gabriele Mazzotta пишет: On 23/11/2015 15:50, Pali Rohár wrote: On Sunday 22 November 2015 09:23:19 Andrei Borzenkov wrote: 21.11.2015 23:39, Andrei Borzenkov пишет: 21.11.2015 22:08, Pali Rohár пишет: On Saturday 21 November 2015 19:57:18 Andrei Borzenkov wrote: After

Re: Regression with dell-rbtn: radio killed on resume after suspend to RAM

On 23/11/2015 15:50, Pali Rohár wrote: On Sunday 22 November 2015 09:23:19 Andrei Borzenkov wrote: 21.11.2015 23:39, Andrei Borzenkov пишет: 21.11.2015 22:08, Pali Rohár пишет: On Saturday 21 November 2015 19:57:18 Andrei Borzenkov wrote: After installing 4.2 on Dell Latitude E5450 I found

Re: [PATCH v2] dell-wmi: Improve unknown hotkey handling

On Mon, Nov 23, 2015 at 03:56:43PM +0100, Pali Rohár wrote: > On Friday 20 November 2015 17:30:13 Andy Lutomirski wrote: > > On Fri, Nov 20, 2015 at 5:27 PM, Andy Lutomirski wrote: > > > If DMI lists a hotkey that we don't recognize, log and ignore it > > > instead of trying to

Re: [PATCH v3 0/2] toshiba_acpi: Add WWAN support

On Mon, Nov 23, 2015 at 10:49:09AM -0700, Azael Avalos wrote: > These two patches add WWAN support to the driver, the first adds the actual > support functions and the second adds RFKill handler functions to set the > device status according to the killswitch. > > Changes since v2: > - Changed

Re: [PATCH v2] toshiba_acpi: Fix keyboard backight sysfs entries not being updated

On Mon, Nov 23, 2015 at 10:51:30AM -0700, Azael Avalos wrote: > Certain Toshiba models with the second generation keyboard backlight > (type 2) do not generate the keyboard backlight changed event (0x92), > and thus, the sysfs entries are never being updated. > > This patch adds a workquee and a

Re: [PATCH 2/5] eeepc-wmi: Use acpi_dev_present

On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote: > Use shiny new acpi_dev_present and remove all the boilerplate to search > for a particular ACPI device. No functional change. You did add a pr_warn, which is technically a functional change. Did you intend to leave that in? I have

Re: [PATCH 3/5] acer-wmi: Use acpi_dev_present

On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote: > Use shiny new acpi_dev_present and remove all the boilerplate to search > for a particular ACPI device. No functional change. > > Cc: Lee, Chun-Yi > Signed-off-by: Lukas Wunner Rafael, I presume

[PATCH v3 1/2] toshiba_acpi: Add support for WWAN devices

Toshiba laptops with WWAN devices installed cannot use the device unless it is attached and powered, similar to how Toshiba Bluetooth devices work. This patch adds support to WWAN devices, introducing three functions, one to query the overall status of the wireless devices (RFKill, WLAN, BT,

[PATCH v3 0/2] toshiba_acpi: Add WWAN support

These two patches add WWAN support to the driver, the first adds the actual support functions and the second adds RFKill handler functions to set the device status according to the killswitch. Changes since v2: - Changed code according to review comments Changes since v1: - Added missing calls

[PATCH v3 2/2] toshiba_acpi: Add WWAN RFKill support

A previuos patch added WWAN support to the driver, allowing to query and set the device status. This patch adds RFKill support for the recently introduced WWAN device, making use of the WWAN and *wireless_status functions to query the killswitch and (de)activate the device accordingly to its

[PATCH v2] toshiba_acpi: Fix keyboard backight sysfs entries not being updated

Certain Toshiba models with the second generation keyboard backlight (type 2) do not generate the keyboard backlight changed event (0x92), and thus, the sysfs entries are never being updated. This patch adds a workquee and a global boolean variable to address the issue. For those models that do

Re: [PATCH 2/5] eeepc-wmi: Use acpi_dev_present

On Mon, Nov 23, 2015 at 08:55:27PM +0100, Lukas Wunner wrote: > Hi Darren, > > On Mon, Nov 23, 2015 at 11:04:13AM -0800, Darren Hart wrote: > > On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote: > > > Use shiny new acpi_dev_present and remove all the boilerplate to search > > > for a