Re: [RFT][PATCH 0/2] cpufreq: intel_pstate: Handle _PPC updates on global turbo disable/enable

Hi, I applied these patches on top of 4.20. The max frequency of all the cores now reflects the actual value and it's updated whenever I change the power source. Regards, Gabriele On Fri, 1 Mar 2019 at 13:51, Rafael J. Wysocki wrote: > > Hi All, > > This is how I would fix the issue reported

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 07/08/2018 23:22, Srinivas Pandruvada wrote: > On Tue, 2018-08-07 at 22:12 +0200, Gabriele Mazzotta wrote: >> On 07/08/2018 00:11, Srinivas Pandruvada wrote: >>> On Mon, 2018-08-06 at 23:50 +0200, Gabriele Mazzotta wrote: >>>> On 06/08/2018 18:49, Srinivas Pandru

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 07/08/2018 23:22, Srinivas Pandruvada wrote: > On Tue, 2018-08-07 at 22:12 +0200, Gabriele Mazzotta wrote: >> On 07/08/2018 00:11, Srinivas Pandruvada wrote: >>> On Mon, 2018-08-06 at 23:50 +0200, Gabriele Mazzotta wrote: >>>> On 06/08/2018 18:49, Srinivas Pandru

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 07/08/2018 00:11, Srinivas Pandruvada wrote: > On Mon, 2018-08-06 at 23:50 +0200, Gabriele Mazzotta wrote: >> On 06/08/2018 18:49, Srinivas Pandruvada wrote: >>> On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote: >>>> On Sat, Aug 4, 2018 at 7:31 PM,

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 07/08/2018 00:11, Srinivas Pandruvada wrote: > On Mon, 2018-08-06 at 23:50 +0200, Gabriele Mazzotta wrote: >> On 06/08/2018 18:49, Srinivas Pandruvada wrote: >>> On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote: >>>> On Sat, Aug 4, 2018 at 7:31 PM,

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 06/08/2018 18:49, Srinivas Pandruvada wrote: > On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote: >> On Sat, Aug 4, 2018 at 7:31 PM, Gabriele Mazzotta >> wrote: >>> On 04/08/2018 17:29, Gabriele Mazzotta wrote: >>>> This change does not take

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 06/08/2018 18:49, Srinivas Pandruvada wrote: > On Mon, 2018-08-06 at 10:30 +0200, Rafael J. Wysocki wrote: >> On Sat, Aug 4, 2018 at 7:31 PM, Gabriele Mazzotta >> wrote: >>> On 04/08/2018 17:29, Gabriele Mazzotta wrote: >>>> This change does not take

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 04/08/2018 17:29, Gabriele Mazzotta wrote: > This change does not take into account that some BIOSes change > MSR_IA32_MISC_ENABLE_TURBO_DISABLE depending on the power source. > If the turbo is disabled when the system boots, policy.max_freq > is set to pstate.max_pstate. However,

Re: [PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

On 04/08/2018 17:29, Gabriele Mazzotta wrote: > This change does not take into account that some BIOSes change > MSR_IA32_MISC_ENABLE_TURBO_DISABLE depending on the power source. > If the turbo is disabled when the system boots, policy.max_freq > is set to pstate.max_pstate. However,

[PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

the turbo is enabled. This reverts commit 983e600e88835f0321d1a0ea06f52d48b7b5a544. Signed-off-by: Gabriele Mazzotta --- drivers/cpufreq/intel_pstate.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index

[PATCH] Revert "cpufreq: intel_pstate: Fix ->set_policy() interface for no_turbo"

the turbo is enabled. This reverts commit 983e600e88835f0321d1a0ea06f52d48b7b5a544. Signed-off-by: Gabriele Mazzotta --- drivers/cpufreq/intel_pstate.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index

Re: [RFC] iio: light: acpi-als: Enable the light sensor on the Zenbook UX430UQ

2017-11-19 18:03 GMT+01:00 Jonathan Cameron : > On Wed, 15 Nov 2017 20:27:54 -0700 > Kiernan Hager wrote: > >> This makes acpi-als properly enable the light sensor on the Zenbook UX430UQ. >> I don't know if the checking that I do to make sure that the

Re: [RFC] iio: light: acpi-als: Enable the light sensor on the Zenbook UX430UQ

2017-11-19 18:03 GMT+01:00 Jonathan Cameron : > On Wed, 15 Nov 2017 20:27:54 -0700 > Kiernan Hager wrote: > >> This makes acpi-als properly enable the light sensor on the Zenbook UX430UQ. >> I don't know if the checking that I do to make sure that the ACPI method >> exists is sufficient or if

Re: keyboard backlight max_brightness bug on Dell Latitude E6410

2017-09-14 15:54 GMT+02:00 Pali Rohár : > Adding Gabriele to thread, IIRC you have machine which uses > "supported keyboard light brightness levels" > Can you look at this bug, if your machine is affected by it too? My keyboard has two brightness levels + off. The value of

Re: keyboard backlight max_brightness bug on Dell Latitude E6410

2017-09-14 15:54 GMT+02:00 Pali Rohár : > Adding Gabriele to thread, IIRC you have machine which uses > "supported keyboard light brightness levels" > Can you look at this bug, if your machine is affected by it too? My keyboard has two brightness levels + off. The value of max_brightness is 2, as

Re: Crash caused by hid-rmi and no longer working touchscreen

Here the full log showing the errors up to the crash: Gabriele [0.00] Linux version 4.11.0-rc6 (gabriele@xps13) (gcc version 6.3.0 20170406 (Debian 6.3.0-12) ) #3 SMP Mon Apr 10 14:54:58 CEST 2017 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.11.0-rc6 root=/dev/sda6 ro quiet

Re: Crash caused by hid-rmi and no longer working touchscreen

Here the full log showing the errors up to the crash: Gabriele [0.00] Linux version 4.11.0-rc6 (gabriele@xps13) (gcc version 6.3.0 20170406 (Debian 6.3.0-12) ) #3 SMP Mon Apr 10 14:54:58 CEST 2017 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.11.0-rc6 root=/dev/sda6 ro quiet

Crash caused by hid-rmi and no longer working touchscreen

Hi, I'm having troubles with hid-rmi using 4.11-rc6. I'm getting some "rmi_hid_read_block: timeout elapsed" errors and ultimately the crash you can see at the end of this mail. I will reply to this mail with a full log that shows all the errors. The problem seems to be caused by commit

Crash caused by hid-rmi and no longer working touchscreen

Hi, I'm having troubles with hid-rmi using 4.11-rc6. I'm getting some "rmi_hid_read_block: timeout elapsed" errors and ultimately the crash you can see at the end of this mail. I will reply to this mail with a full log that shows all the errors. The problem seems to be caused by commit

Re: [PATCH] leds: Allow drivers to update the core, and generate events on changes

On 27/12/2016 21:07, Pavel Machek wrote: > Hi! > >> Similarily to commit 325253a6b2de ("backlight: Allow drivers to update >> the core, and generate events on changes"), inform userspace about >> brightness changes and allow drivers to request updates of the >> brightness value. > > First... we

Re: [PATCH] leds: Allow drivers to update the core, and generate events on changes

On 27/12/2016 21:07, Pavel Machek wrote: > Hi! > >> Similarily to commit 325253a6b2de ("backlight: Allow drivers to update >> the core, and generate events on changes"), inform userspace about >> brightness changes and allow drivers to request updates of the >> brightness value. > > First... we

[PATCH] leds: Allow drivers to update the core, and generate events on changes

Similarily to commit 325253a6b2de ("backlight: Allow drivers to update the core, and generate events on changes"), inform userspace about brightness changes and allow drivers to request updates of the brightness value. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> ---

[PATCH] leds: Allow drivers to update the core, and generate events on changes

Similarily to commit 325253a6b2de ("backlight: Allow drivers to update the core, and generate events on changes"), inform userspace about brightness changes and allow drivers to request updates of the brightness value. Signed-off-by: Gabriele Mazzotta --- This is exactly like 32

[PATCH 2/2] ALSA: hda - Fix click noises on Samsung Ativ Book 8

jack by automuting via amp instead of pinctl. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- sound/pci/hda/patch_realtek.c | 8 1 file changed, 8 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index d30cc49512e4..00df12

[PATCH 1/2] ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE

Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE. Signed-off-by: Gabriele Mazzotta <gabri

[PATCH 2/2] ALSA: hda - Fix click noises on Samsung Ativ Book 8

jack by automuting via amp instead of pinctl. Signed-off-by: Gabriele Mazzotta --- sound/pci/hda/patch_realtek.c | 8 1 file changed, 8 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index d30cc49512e4..00df12b6695a 100644 --- a/sound/pci/hda

[PATCH 1/2] ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE

Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE. Signed-off-by: Gabriele Mazzotta --- sound/pci/hda

[PATCH v3] rtc-cmos: Reject unsupported alarm values

, alarms are potentially programmed to go off in the wrong moment. Fix this by rejecting any unsupported value. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/rtc/rtc-cmos.c | 72 ++ 1 file changed, 72 insertions(+) diff

[PATCH v3] rtc-cmos: Reject unsupported alarm values

, alarms are potentially programmed to go off in the wrong moment. Fix this by rejecting any unsupported value. Signed-off-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 72 ++ 1 file changed, 72 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b

Re: [PATCH v2] rtc-cmos: Reject unsupported alarm values

2016-09-22 1:29 GMT+02:00 Alexandre Belloni <alexandre.bell...@free-electrons.com>: > On 02/09/2016 at 21:55:16 +0200, Gabriele Mazzotta wrote : >> Some platforms allows to specify the month and day of the month in >> which an alarm should go off, some others the day of

Re: [PATCH v2] rtc-cmos: Reject unsupported alarm values

2016-09-22 1:29 GMT+02:00 Alexandre Belloni : > On 02/09/2016 at 21:55:16 +0200, Gabriele Mazzotta wrote : >> Some platforms allows to specify the month and day of the month in >> which an alarm should go off, some others the day of the month and >> some others just the time

[PATCH v4 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.

[PATCH v4 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 23

[PATCH v4 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/rtc/rtc-cmos.c | 49 + 1 file changed, 49 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 1dec52f..fd7ec0a 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/d

[PATCH v4 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 49 + 1 file changed, 49 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 1dec52f..fd7ec0a 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -900,6

[PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/rtc/rtc-cmos.c | 32 1 file changed, 32 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 1dec52f..6042257 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-

[PATCH v3 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.

[PATCH v3 1/2] rtc-cmos: Clear ACPI-driven alarms upon resume

-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 32 1 file changed, 32 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 1dec52f..6042257 100644 --- a/drivers/rtc/rtc-cmos.c +++ b/drivers/rtc/rtc-cmos.c @@ -939,6 +939,22

[PATCH v3 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 23

Re: [PATCH v2 1/2] rtc-cmos: Ensure no expired alarm is left enabled after resume

2016-09-06 0:26 GMT+02:00 Alexandre Belloni <alexandre.bell...@free-electrons.com>: > Hi > > On 01/09/2016 at 00:58:59 +0200, Gabriele Mazzotta wrote : >> static int cmos_resume(struct device *dev) >> { >> struct cmos_rtc *cmos = dev_get_drvdata

Re: [PATCH v2 1/2] rtc-cmos: Ensure no expired alarm is left enabled after resume

2016-09-06 0:26 GMT+02:00 Alexandre Belloni : > Hi > > On 01/09/2016 at 00:58:59 +0200, Gabriele Mazzotta wrote : >> static int cmos_resume(struct device *dev) >> { >> struct cmos_rtc *cmos = dev_get_drvdata(dev); >> unsigned char tmp

[PATCH v2] rtc-cmos: Reject unsupported alarm values

, alarms are potentially programmed to go off in the wrong moment. Fix this by rejecting any value not supported by the hardware. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- I revisited the naive implementation of v1. I tested the new algorithm using some dates that and ve

[PATCH v2] rtc-cmos: Reject unsupported alarm values

, alarms are potentially programmed to go off in the wrong moment. Fix this by rejecting any value not supported by the hardware. Signed-off-by: Gabriele Mazzotta --- I revisited the naive implementation of v1. I tested the new algorithm using some dates that and verified that it behaved as expected

Re: [PATCH v2 1/2] rtc-cmos: Ensure no expired alarm is left enabled after resume

On 01/09/2016 00:58, Gabriele Mazzotta wrote: > Some BIOSes, such as the one of the Dell XPS13 9333, wake the system > when an alarm goes off without informing the OS. If any of the A clarification on this first sentence. I was looking at the ACPI specification [1] and it seems that there a

Re: [PATCH v2 1/2] rtc-cmos: Ensure no expired alarm is left enabled after resume

On 01/09/2016 00:58, Gabriele Mazzotta wrote: > Some BIOSes, such as the one of the Dell XPS13 9333, wake the system > when an alarm goes off without informing the OS. If any of the A clarification on this first sentence. I was looking at the ACPI specification [1] and it seems that there a

Re: [PATCH] rtc-cmos: Reject unsupported alarm values

On 01/09/2016 00:59, Gabriele Mazzotta wrote: > Return an error if the user tries to set an alarm that isn't > supported by the hardware. > > Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> > --- > drivers/rtc/rtc-cmos.c | 20 > 1

Re: [PATCH] rtc-cmos: Reject unsupported alarm values

On 01/09/2016 00:59, Gabriele Mazzotta wrote: > Return an error if the user tries to set an alarm that isn't > supported by the hardware. > > Signed-off-by: Gabriele Mazzotta > --- > drivers/rtc/rtc-cmos.c | 20 > 1 file changed, 20 insertions(+) >

[PATCH v2 1/2] rtc-cmos: Ensure no expired alarm is left enabled after resume

the alarm writing 0 to wakealarm before being able to set a new alarm. Ensure this never happens. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/rtc/rtc-cmos.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/d

[PATCH v2 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.

[PATCH] rtc-cmos: Reject unsupported alarm values

Return an error if the user tries to set an alarm that isn't supported by the hardware. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/rtc/rtc-cmos.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-

[PATCH v2 1/2] rtc-cmos: Ensure no expired alarm is left enabled after resume

the alarm writing 0 to wakealarm before being able to set a new alarm. Ensure this never happens. Signed-off-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index

[PATCH v2 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 23

[PATCH] rtc-cmos: Reject unsupported alarm values

Return an error if the user tries to set an alarm that isn't supported by the hardware. Signed-off-by: Gabriele Mazzotta --- drivers/rtc/rtc-cmos.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c index 4cdb335..b3f9298

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 31/08/2016 01:28, Alexandre Belloni wrote: > Hi, > > On 25/08/2016 at 16:54:18 +0200, Gabriele Mazzotta wrote : >> Hi, >> >> were you able to verify that no other driver is affect? >> > > I had a closer look at the issue. I think what is happening is t

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 31/08/2016 01:28, Alexandre Belloni wrote: > Hi, > > On 25/08/2016 at 16:54:18 +0200, Gabriele Mazzotta wrote : >> Hi, >> >> were you able to verify that no other driver is affect? >> > > I had a closer look at the issue. I think what is happening is t

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 04/06/2016 19:48, Alexandre Belloni wrote: > On 04/06/2016 at 18:58:59 +0200, Gabriele Mazzotta wrote : >> 2016-06-04 16:46 GMT+02:00 Alexandre Belloni >> <alexandre.bell...@free-electrons.com>: >>> On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote : >&

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 04/06/2016 19:48, Alexandre Belloni wrote: > On 04/06/2016 at 18:58:59 +0200, Gabriele Mazzotta wrote : >> 2016-06-04 16:46 GMT+02:00 Alexandre Belloni >> : >>> On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote : >>>> If the system wakes up because

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

On 22/06/2016 16:21, mario_limoncie...@dell.com wrote: >> -Original Message- >> From: Pali Rohár [mailto:pali.ro...@gmail.com] >> Sent: Wednesday, June 22, 2016 9:13 AM >> To: Limonciello, Mario >> Cc: gabriele@gmail.com; mj...@srcf.ucam.org;

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

On 22/06/2016 16:21, mario_limoncie...@dell.com wrote: >> -Original Message- >> From: Pali Rohár [mailto:pali.ro...@gmail.com] >> Sent: Wednesday, June 22, 2016 9:13 AM >> To: Limonciello, Mario >> Cc: gabriele@gmail.com; mj...@srcf.ucam.org; dvh...@infradead.org; >>

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

to go into linux-next? > > Series should be OK, but I would like to see if someone else test this > series... Gabriele, Alex or Andy? Do you have time? I tested this series and everything seems to be working fine here. Tested-by: Gabriele Mazzotta <gabriele@gmail.com>

Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

to go into linux-next? > > Series should be OK, but I would like to see if someone else test this > series... Gabriele, Alex or Andy? Do you have time? I tested this series and everything seems to be working fine here. Tested-by: Gabriele Mazzotta

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

On 08/06/2016 08:02, mario_limoncie...@dell.com wrote: >> -Original Message- >> From: Pali Rohár [mailto:pali.ro...@gmail.com] >> Sent: Tuesday, June 7, 2016 6:00 PM >> To: Gabriele Mazzotta <gabriele@gmail.com>; Limonciello, Mario >> <mario_limon

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

On 08/06/2016 08:02, mario_limoncie...@dell.com wrote: >> -Original Message- >> From: Pali Rohár [mailto:pali.ro...@gmail.com] >> Sent: Tuesday, June 7, 2016 6:00 PM >> To: Gabriele Mazzotta ; Limonciello, Mario >> >> Cc: Matthew Garrett ; Darren Hart

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

2016-06-04 16:46 GMT+02:00 Alexandre Belloni <alexandre.bell...@free-electrons.com>: > Hi, > > On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote : >> If the system wakes up because of a wake alarm, the internal state >> of the alarm is not updated. As conse

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

2016-06-04 16:46 GMT+02:00 Alexandre Belloni : > Hi, > > On 01/06/2016 at 17:40:14 +0200, Gabriele Mazzotta wrote : >> If the system wakes up because of a wake alarm, the internal state >> of the alarm is not updated. As consequence, the state no longer >> reflects the a

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 01/06/2016 17:40, Gabriele Mazzotta wrote: > If the system wakes up because of a wake alarm, the internal state > of the alarm is not updated. As consequence, the state no longer > reflects the actual state of the hardware and setting a new alarm > is not possible until the e

Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 01/06/2016 17:40, Gabriele Mazzotta wrote: > If the system wakes up because of a wake alarm, the internal state > of the alarm is not updated. As consequence, the state no longer > reflects the actual state of the hardware and setting a new alarm > is not possible until the e

[PATCH 1/2] rtc-cmos: Clear expired alarm after resume

If the system wakes up because of a wake alarm, the internal state of the alarm is not updated. As consequence, the state no longer reflects the actual state of the hardware and setting a new alarm is not possible until the expired alarm is cleared. Signed-off-by: Gabriele Mazzotta <gabri

[PATCH 1/2] rtc-cmos: Clear expired alarm after resume

If the system wakes up because of a wake alarm, the internal state of the alarm is not updated. As consequence, the state no longer reflects the actual state of the hardware and setting a new alarm is not possible until the expired alarm is cleared. Signed-off-by: Gabriele Mazzotta --- drivers

[PATCH 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.

[PATCH 2/2] rtc-cmos: Restore alarm after resume

), resulting in it running in a confined space and potentially overheating. This seems reasonably important. The Rapid Start support code got added in 3.11, but it can be configured in the firmware regardless of kernel support. Signed-off-by: Gabriele Mazzotta --- This a rework of http

Re: [Experimental PATCH] dell-smm-hwmon: Add support for disabling automatic BIOS fan control

On 30/05/2016 11:32, Pali Rohár wrote: > On Friday 27 May 2016 14:11:11 Gabriele Mazzotta wrote: >> On 22/05/2016 13:50, Pali Rohár wrote: >>> This patch exports standard hwmon pwmX_enable sysfs attribute for enabling >>> or disabling automatic fan control

Re: [Experimental PATCH] dell-smm-hwmon: Add support for disabling automatic BIOS fan control

On 30/05/2016 11:32, Pali Rohár wrote: > On Friday 27 May 2016 14:11:11 Gabriele Mazzotta wrote: >> On 22/05/2016 13:50, Pali Rohár wrote: >>> This patch exports standard hwmon pwmX_enable sysfs attribute for enabling >>> or disabling automatic fan control

Re: [Experimental PATCH] dell-smm-hwmon: Add support for disabling automatic BIOS fan control

On 22/05/2016 13:50, Pali Rohár wrote: > This patch exports standard hwmon pwmX_enable sysfs attribute for enabling > or disabling automatic fan control by BIOS. Standard value "1" is for > disabling automatic BIOS fan control and value "2" for enabling. > > Currently there is no way to check if

Re: [Experimental PATCH] dell-smm-hwmon: Add support for disabling automatic BIOS fan control

On 22/05/2016 13:50, Pali Rohár wrote: > This patch exports standard hwmon pwmX_enable sysfs attribute for enabling > or disabling automatic fan control by BIOS. Standard value "1" is for > disabling automatic BIOS fan control and value "2" for enabling. > > Currently there is no way to check if

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

gt; + I'm interested in knowing what's the meaning of this 0xe00e. This event is sent multiple times when I suspend/resume my laptop and it's definitely not a keypress. Anyway, I've been using this patch set and didn't notice any issue, so Tested-by: Gabriele Mazzotta <gabriele...

Re: [PATCH 3/4] dell-wmi: Add information about other WMI event codes

ing what's the meaning of this 0xe00e. This event is sent multiple times when I suspend/resume my laptop and it's definitely not a keypress. Anyway, I've been using this patch set and didn't notice any issue, so Tested-by: Gabriele Mazzotta > /* Wifi Catcher */ > { KE_KEY,0xe0

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

On 25/05/2016 22:36, Pali Rohár wrote: > On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: >> On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: >>> Some BIOSes unconditionally send an ACPI notification to RBTN when >>> the system is resuming from su

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

On 25/05/2016 22:36, Pali Rohár wrote: > On Wednesday 25 May 2016 22:28:47 Darren Hart wrote: >> On Tue, May 24, 2016 at 10:53:08PM +0200, Gabriele Mazzotta wrote: >>> Some BIOSes unconditionally send an ACPI notification to RBTN when >>> the system is resuming from su

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

://bugzilla.kernel.org/show_bug.cgi?id=106031 Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/platform/x86/dell-rbtn.c | 56 1 file changed, 56 insertions(+) diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-

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

://bugzilla.kernel.org/show_bug.cgi?id=106031 Signed-off-by: Gabriele Mazzotta --- drivers/platform/x86/dell-rbtn.c | 56 1 file changed, 56 insertions(+) diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c index 331d63c..dd22fb9

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

On 24/05/2016 00:22, Pali Rohár wrote: > On Tuesday 24 May 2016 00:17:15 Darren Hart wrote: >> On Tue, May 24, 2016 at 12:06:03AM +0200, Pali Rohár wrote: >>> On Monday 23 May 2016 23:26:55 Darren Hart wrote: I've queued this. Thanks for your patience. >>> >>> Ok, In that case I would update

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

On 24/05/2016 00:22, Pali Rohár wrote: > On Tuesday 24 May 2016 00:17:15 Darren Hart wrote: >> On Tue, May 24, 2016 at 12:06:03AM +0200, Pali Rohár wrote: >>> On Monday 23 May 2016 23:26:55 Darren Hart wrote: I've queued this. Thanks for your patience. >>> >>> Ok, In that case I would update

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

2016-04-18 14:35 GMT+02:00 Pali Rohár <pali.ro...@gmail.com>: > On Tuesday 29 March 2016 15:11:35 Rafael J. Wysocki wrote: >> On Monday, March 28, 2016 10:33:09 AM Darren Hart wrote: >> > On Thu, Mar 24, 2016 at 12:24:56PM +0100, Gabriele Mazzotta wrote: >> >

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

2016-04-18 14:35 GMT+02:00 Pali Rohár : > On Tuesday 29 March 2016 15:11:35 Rafael J. Wysocki wrote: >> On Monday, March 28, 2016 10:33:09 AM Darren Hart wrote: >> > On Thu, Mar 24, 2016 at 12:24:56PM +0100, Gabriele Mazzotta wrote: >> > > 2016-03-24 10:39 GMT+01:00 P

Oops in 4.6-rc2: NULL pointer dereference in cdc-acm

Hi, I'm getting a kernel oops when I plug some smartphone via USB to my laptop, which is currently running the v4.6-rc2. The problem seems to be caused by a81cf9799ad7 ("cdc-acm: implement put_char() and flush_chars()"). A simple NULL pointer check prevents the crash, but since I have no use of

Oops in 4.6-rc2: NULL pointer dereference in cdc-acm

Hi, I'm getting a kernel oops when I plug some smartphone via USB to my laptop, which is currently running the v4.6-rc2. The problem seems to be caused by a81cf9799ad7 ("cdc-acm: implement put_char() and flush_chars()"). A simple NULL pointer check prevents the crash, but since I have no use of

[PATCH v4 1/4] input: synaptics - fix pressure values calculation on image sensors

The pressure values retrieved from secondary packets was incorrectly shifted, making them lower than what they actually were. Since this only happened with secondary packets, the values reported when only one finger was present on the touchpad were correct. Signed-off-by: Gabriele Mazzotta

[PATCH v4 1/4] input: synaptics - fix pressure values calculation on image sensors

The pressure values retrieved from secondary packets was incorrectly shifted, making them lower than what they actually were. Since this only happened with secondary packets, the values reported when only one finger was present on the touchpad were correct. Signed-off-by: Gabriele Mazzotta

[PATCH v4 2/4] input: synaptics - fix width values calculation on image sensors

When multiple fingers are on the touchpad, W reports the finger count rather than the width. Retrieve the correct value that is encoded in X, Y and Z of AGM and SGM packets. The minimum width reported is 8 rather than 4 in this case, while the maximum remains 15. Signed-off-by: Gabriele Mazzotta

[PATCH v4 2/4] input: synaptics - fix width values calculation on image sensors

When multiple fingers are on the touchpad, W reports the finger count rather than the width. Retrieve the correct value that is encoded in X, Y and Z of AGM and SGM packets. The minimum width reported is 8 rather than 4 in this case, while the maximum remains 15. Signed-off-by: Gabriele Mazzotta

[PATCH v4 4/4] input: synaptics - make image sensors and cr48 sensors report widths

-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/input/mouse/synaptics.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index 27a091b..bed268b 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers

[PATCH v4 0/4] input: synaptics - report correct width and pressure values

The problem of the previous set, v3, was the use of ABS_MT_TOUCH_MAJOR to report finger widths without them being expressed in surface units. In this set only the width of the first touch is reported, this time using ABS_TOOL_WIDTH. Gabriele Mazzotta (4): input: synaptics - fix pressure values

[PATCH v4 4/4] input: synaptics - make image sensors and cr48 sensors report widths

-off-by: Gabriele Mazzotta --- drivers/input/mouse/synaptics.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index 27a091b..bed268b 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -943,6

[PATCH v4 0/4] input: synaptics - report correct width and pressure values

The problem of the previous set, v3, was the use of ABS_MT_TOUCH_MAJOR to report finger widths without them being expressed in surface units. In this set only the width of the first touch is reported, this time using ABS_TOOL_WIDTH. Gabriele Mazzotta (4): input: synaptics - fix pressure values

[PATCH v4 3/4] input: synaptics - change default width value of cr48 sensors

The minimum value these sensors can report is 4, so this should be the value used when W is not reporting the width. Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/input/mouse/synaptics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers

[PATCH v4 3/4] input: synaptics - change default width value of cr48 sensors

The minimum value these sensors can report is 4, so this should be the value used when W is not reporting the width. Signed-off-by: Gabriele Mazzotta --- drivers/input/mouse/synaptics.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/mouse/synaptics.c b/drivers

[PATCH] HID: multitouch: Synchronize MT frame on reset_resume

input_mt_get_slot_by_key() requires input_mt_sync_frame() to be called at each frame. Do it when releasing the touches, or else we won't get a proper slot number after mt_reset_resume(). Signed-off-by: Gabriele Mazzotta <gabriele@gmail.com> --- drivers/hid/hid-multitouch.c | 1 +

[PATCH] HID: multitouch: Synchronize MT frame on reset_resume

input_mt_get_slot_by_key() requires input_mt_sync_frame() to be called at each frame. Do it when releasing the touches, or else we won't get a proper slot number after mt_reset_resume(). Signed-off-by: Gabriele Mazzotta --- drivers/hid/hid-multitouch.c | 1 + 1 file changed, 1 insertion

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

2016-03-29 7:24 GMT+02:00 Darren Hart <dvh...@infradead.org>: > > On Mon, Mar 28, 2016 at 09:41:09PM +0200, Gabriele Mazzotta wrote: > > 2016-03-28 20:56 GMT+02:00 Darren Hart <dvh...@infradead.org>: > > > On Mon, Mar 28, 2016 at 07:58:09PM +0200, Gabriele Mazzot

  1   2   3   4   >