ted-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
This fixes a bug introduced by a commit queued for 4.17, so it needs to
be applied on top of for-next.
drivers/platform/x86/fujitsu-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 del
ers/platform/x86/fujitsu-laptop.c:816 acpi_fujitsu_laptop_add() warn:
impossible condition '(priv->flags_supported == (1 << (31))) =>
(0-2147483647,18446744071562067968-u64max == 2147483648)'
Fixes: 819cddae7cfa ("platform/x86: fujitsu-laptop: Clean up constants"
by OP_GET_EVENTS).
So, given the above, does this layout look reasonable to you (at least
somewhat) or would you rather see these constants shuffled around in
some other way?
--
Best regards,
Michał Kępień
by OP_GET_EVENTS).
So, given the above, does this layout look reasonable to you (at least
somewhat) or would you rather see these constants shuffled around in
some other way?
--
Best regards,
Michał Kępień
roach,
I am all ears.
--
Best regards,
Michał Kępień
roach,
I am all ears.
--
Best regards,
Michał Kępień
> On Tue, Feb 27, 2018 at 11:15 PM, Michał Kępień <ker...@kempniu.pl> wrote:
> > The MAX_HOTKEY_RINGBUFFER_SIZE constant is set to 100, which allows up
> > to 100 hotkey events to be drained from the firmware ring buffer upon
> > module load. However, no known firmware
> On Tue, Feb 27, 2018 at 11:15 PM, Michał Kępień wrote:
> > The MAX_HOTKEY_RINGBUFFER_SIZE constant is set to 100, which allows up
> > to 100 hotkey events to be drained from the firmware ring buffer upon
> > module load. However, no known firmware is capable of holding mo
suggest that it is a pretty common thing. So no problem, I
will tweak this in v2. I understand I should apply the same concept in
these cases:
+/* Constants related to FUNC_BACKLIGHT */
+#define FEAT_BACKLIGHT_POWER BIT(2)
+#define STATE_BACKLIGHT_OFF(BIT(0) | BIT(1))
+#define STATE_BACKLIGHT_ON 0
+#define FEAT_RADIO_LED BIT(5)
+#define STATE_RADIO_LED_OFF0
+#define STATE_RADIO_LED_ON BIT(5)
Right?
--
Best regards,
Michał Kępień
tty common thing. So no problem, I
will tweak this in v2. I understand I should apply the same concept in
these cases:
+/* Constants related to FUNC_BACKLIGHT */
+#define FEAT_BACKLIGHT_POWER BIT(2)
+#define STATE_BACKLIGHT_OFF(BIT(0) | BIT(1))
+#define STATE_BACKLIGHT_ON 0
+#define FEAT_RADIO_LED BIT(5)
+#define STATE_RADIO_LED_OFF0
+#define STATE_RADIO_LED_ON BIT(5)
Right?
--
Best regards,
Michał Kępień
This patch series is an attempt to organize all the named constants used
throughout fujitsu-laptop so that their names more clearly convey their
purpose: a set of prefixes is introduced to "map" constant names to
call_fext_func() parameters.
The chosen constant naming patterns are a compromise
This patch series is an attempt to organize all the named constants used
throughout fujitsu-laptop so that their names more clearly convey their
purpose: a set of prefixes is introduced to "map" constant names to
call_fext_func() parameters.
The chosen constant naming patterns are a compromise
(OP_GET_EVENTS).
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 103 --
1 file changed, 60 insertions(+), 43 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
(OP_GET_EVENTS).
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 103 --
1 file changed, 60 insertions(+), 43 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 13bcdfea5349..74775caeb609
.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 50 +++
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 087b5d
.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 50 +++
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 087b5d1f2f4a..3e824e961260 100644
Rename KEYx_CODE constants to EVENT_HKx, so that their names better fit
the OP_GET_EVENTS operation they are used with.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 36 +--
1 file changed, 18 insertions(
Rename KEYx_CODE constants to EVENT_HKx, so that their names better fit
the OP_GET_EVENTS operation they are used with.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git
Stop invoking call_fext_func() directly to improve code clarity and save
some horizontal space.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 116 +-
1 file changed, 59 insertions(+), 57 deletions(-)
diff
Stop invoking call_fext_func() directly to improve code clarity and save
some horizontal space.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 116 +-
1 file changed, 59 insertions(+), 57 deletions(-)
diff --git a/drivers/platform/x86
Update comments used for each group of constants to better reflect their
current purpose. Ensure the layout of groups of constants follows the
order in which call_fext_func() takes its arguments. Use alphabetic
ordering for groups of constants.
Signed-off-by: Michał Kępień <ker...@kempniu
-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 53 +++
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 74775c
Update comments used for each group of constants to better reflect their
current purpose. Ensure the layout of groups of constants follows the
order in which call_fext_func() takes its arguments. Use alphabetic
ordering for groups of constants.
Signed-off-by: Michał Kępień
---
drivers
-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 53 +++
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 74775caeb609..087b5d1f2f4a 100644
d more accurately
represent the underlying data structure.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fuji
d more accurately
represent the underlying data structure.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 5acf1c
in acpi_fujitsu_laptop_add() into one line.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 85 +--
1 file changed, 41 insertions(+), 44 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/pl
. Do that instead of jumping to the end of the
function to improve code readability. Running out of memory while
allocating the kfifo does not seem probable enough to warrant logging an
error message, so do not do it.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/f
in acpi_fujitsu_laptop_add() into one line.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 85 +--
1 file changed, 41 insertions(+), 44 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu
. Do that instead of jumping to the end of the
function to improve code readability. Running out of memory while
allocating the kfifo does not seem probable enough to warrant logging an
error message, so do not do it.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 14
Do not include linux/slab.h as all module code now uses managed memory
allocations and thus neither k*alloc() nor kfree() is used.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platfo
In order to improve code clarity, move declarations of variables that
are module parameters higher up and add a comment.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/d
Do not include linux/slab.h as all module code now uses managed memory
allocations and thus neither k*alloc() nor kfree() is used.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b
In order to improve code clarity, move declarations of variables that
are module parameters higher up and add a comment.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/fujitsu
Align all constant values defined in the module to a common indentation.
Rename ACPI_FUJITSU_NOTIFY_CODE1 to ACPI_FUJITSU_NOTIFY_CODE as there is
only one ACPI notification code used throughout the driver. Define all
bitmasks using the BIT() macro. Clean up comments.
Signed-off-by: Michał
Only register input devices after the device-specific data structures
they access are fully initialized.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/d
Align all constant values defined in the module to a common indentation.
Rename ACPI_FUJITSU_NOTIFY_CODE1 to ACPI_FUJITSU_NOTIFY_CODE as there is
only one ACPI notification code used throughout the driver. Define all
bitmasks using the BIT() macro. Clean up comments.
Signed-off-by: Michał
Only register input devices after the device-specific data structures
they access are fully initialized.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/fujitsu
This patch series contains miscellaneous cleanups which I think are
worth getting done before splitting fujitsu-laptop into two separate
modules.
Changes from v1:
- [6/7] Rename BACKLIGHT_POWER to BACKLIGHT_PARAM_POWER.
- [6/7] Use BACKLIGHT_OFF instead of a numeric constant.
- [7/7]
This patch series contains miscellaneous cleanups which I think are
worth getting done before splitting fujitsu-laptop into two separate
modules.
Changes from v1:
- [6/7] Rename BACKLIGHT_POWER to BACKLIGHT_PARAM_POWER.
- [6/7] Use BACKLIGHT_OFF instead of a numeric constant.
- [7/7]
Use named constants instead of integers in call_fext_func() invocations
related to backlight power control in order to more clearly convey the
intent of each call.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 14 +++---
1 file chang
Use named constants instead of integers in call_fext_func() invocations
related to backlight power control in order to more clearly convey the
intent of each call.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 14 +++---
1 file changed, 11 insertions(+), 3
I think that is the
most coherent way of moving forward, but if you would rather see fixed
versions of patches 6/7 and 7/7 posted as 1/2 and 2/2, please just let
me know.
--
Best regards,
Michał Kępień
I think that is the
most coherent way of moving forward, but if you would rather see fixed
versions of patches 6/7 and 7/7 posted as 1/2 and 2/2, please just let
me know.
--
Best regards,
Michał Kępień
ht power value. If that's the case, is the value of 3 used in the
> test of the return function conceptually BACKLIGHT_OFF, and if so, should we
> use BACKLIGHT_OFF instead of the numeric constant? It seems likely given
> that it results in the backlight power property being set to
> FB_BLANK_POWERDOWN.
Ah, yes, good catch. Will fix, thanks.
--
Best regards,
Michał Kępień
ht power value. If that's the case, is the value of 3 used in the
> test of the return function conceptually BACKLIGHT_OFF, and if so, should we
> use BACKLIGHT_OFF instead of the numeric constant? It seems likely given
> that it results in the backlight power property being set to
> FB_BLANK_POWERDOWN.
Ah, yes, good catch. Will fix, thanks.
--
Best regards,
Michał Kępień
il.com>
> ---
> Changes since v1:
> * Added Dell Vostro V131 based on Michał Kępień testing
I tested this patch on a Vostro V131 and it seems to work as expected:
"lis3lv02d: 8 bits sensor found" is logged during boot, an input device
gets registered and its axis values seem t
mmit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to
> conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
> lis3lv02d correctly initialize accelerometer.
>
> Tested on Dell Latitude E6440.
>
> Signed-off-by: Pali Rohár
> ---
>
n ones
>that you use.
>
> Some $ARCH may work without it while another one may not.
Noted, thanks!
--
Best regards,
Michał Kępień
n ones
>that you use.
>
> Some $ARCH may work without it while another one may not.
Noted, thanks!
--
Best regards,
Michał Kępień
Only register input devices after the device-specific data structures
they access are fully initialized.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/d
Only register input devices after the device-specific data structures
they access are fully initialized.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/fujitsu
in acpi_fujitsu_laptop_add() into one line.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 85 +--
1 file changed, 41 insertions(+), 44 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/pl
in acpi_fujitsu_laptop_add() into one line.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 85 +--
1 file changed, 41 insertions(+), 44 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu
Use named constants instead of integers in call_fext_func() invocations
related to backlight power control in order to more clearly convey the
intent of each call.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 14 +++---
1 file chang
Use named constants instead of integers in call_fext_func() invocations
related to backlight power control in order to more clearly convey the
intent of each call.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 14 +++---
1 file changed, 11 insertions(+), 3
. Do that instead of jumping to the end of the
function to improve code readability. Running out of memory while
allocating the kfifo does not seem probable enough to warrant logging an
error message, so do not do it.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/f
In order to improve code clarity, move declarations of variables that
are module parameters higher up and add a comment.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/d
. Do that instead of jumping to the end of the
function to improve code readability. Running out of memory while
allocating the kfifo does not seem probable enough to warrant logging an
error message, so do not do it.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 14
In order to improve code clarity, move declarations of variables that
are module parameters higher up and add a comment.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/fujitsu
Align all constant values defined in the module to a common indentation.
Rename ACPI_FUJITSU_NOTIFY_CODE1 to ACPI_FUJITSU_NOTIFY_CODE as there is
only one ACPI notification code used throughout the driver. Define all
bitmasks using the BIT() macro. Clean up comments.
Signed-off-by: Michał
Align all constant values defined in the module to a common indentation.
Rename ACPI_FUJITSU_NOTIFY_CODE1 to ACPI_FUJITSU_NOTIFY_CODE as there is
only one ACPI notification code used throughout the driver. Define all
bitmasks using the BIT() macro. Clean up comments.
Signed-off-by: Michał
Do not include linux/slab.h as all module code now uses managed memory
allocations and thus neither k*alloc() nor kfree() is used.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platfo
Do not include linux/slab.h as all module code now uses managed memory
allocations and thus neither k*alloc() nor kfree() is used.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b
This is the second of the two patch series I started preparing back in
June 2017 [1]. It took me this long to post it purely due to permanent
spare time shortage, not because the changes are complicated.
The patch series contains miscellaneous cleanups which I think are worth
getting done
This is the second of the two patch series I started preparing back in
June 2017 [1]. It took me this long to post it purely due to permanent
spare time shortage, not because the changes are complicated.
The patch series contains miscellaneous cleanups which I think are worth
getting done
It's not a regression as
> such and is largely cosmetic. Others may argue differently though.
I agree as well. The erroneous log messages will only be generated when
any rfkill device in the system is enabled or disabled, so IMHO this is
mostly a nuisance thus can be handled when convenient.
--
Best regards,
Michał Kępień
It's not a regression as
> such and is largely cosmetic. Others may argue differently though.
I agree as well. The erroneous log messages will only be generated when
any rfkill device in the system is enabled or disabled, so IMHO this is
mostly a nuisance thus can be handled when convenient.
--
Best regards,
Michał Kępień
> On Wed, Oct 25, 2017 at 7:29 AM, Michał Kępień <ker...@kempniu.pl> wrote:
> > Radio LED detection method implemented in commit 4f62568c1fcf
> > ("fujitsu-laptop: Support radio LED") turned out to be incorrect as it
> > causes a radio LED to be erroneousl
> On Wed, Oct 25, 2017 at 7:29 AM, Michał Kępień wrote:
> > Radio LED detection method implemented in commit 4f62568c1fcf
> > ("fujitsu-laptop: Support radio LED") turned out to be incorrect as it
> > causes a radio LED to be erroneously detected on a Fujitsu Life
s LED can be controlled using ACPI.
--
Best regards,
Michał Kępień
s LED can be controlled using ACPI.
--
Best regards,
Michał Kępień
(the value returned by method S000 of ACPI device
FUJ02E3) to determine whether a radio LED is present as it seems to be a
more reliable indicator, based on comparing DSDT tables of four Fujitsu
Lifebook models (E744, E751, S7110, S8420).
Reported-by: Heinrich Siebmanns <h...@gmx.de>
Signe
(the value returned by method S000 of ACPI device
FUJ02E3) to determine whether a radio LED is present as it seems to be a
more reliable indicator, based on comparing DSDT tables of four Fujitsu
Lifebook models (E744, E751, S7110, S8420).
Reported-by: Heinrich Siebmanns
Signed-off-by: Michał Kępień
is LED is
handled. I will be happy to do that, but again, no promises about
how much time it will take. (And given the nature of this task, I
cannot promise I will find anything reasonable at all. I also might
ask you to do some further experiments as I do not have an E751
myself.)
--
Best regards,
Michał Kępień
is LED is
handled. I will be happy to do that, but again, no promises about
how much time it will take. (And given the nature of this task, I
cannot promise I will find anything reasonable at all. I also might
ask you to do some further experiments as I do not have an E751
myself.)
--
Best regards,
Michał Kępień
r
However, I would appreciate it if you could help us with finding out the
correct way to detect the radio LED (it may as well turn out it is not
possible by just checking firmware contents). For starters, we will
need your laptop's DSDT table, which you can extract using:
# cat /sys/firmware/acpi/tables/DSDT > dsdt.bin
The resulting binary file dsdt.bin is what is needed for further
analysis.
[1] http://www.lpmanual.com/manuals/fujitsu/Fujitsu_LIFEBOOK_E751.pdf
--
Best regards,
Michał Kępień
r
However, I would appreciate it if you could help us with finding out the
correct way to detect the radio LED (it may as well turn out it is not
possible by just checking firmware contents). For starters, we will
need your laptop's DSDT table, which you can extract using:
# cat /sys/firmware/acpi/tables/DSDT > dsdt.bin
The resulting binary file dsdt.bin is what is needed for further
analysis.
[1] http://www.lpmanual.com/manuals/fujitsu/Fujitsu_LIFEBOOK_E751.pdf
--
Best regards,
Michał Kępień
> On Sat, Jun 24, 2017 at 02:25:46AM +0200, Rafael Wysocki wrote:
> > On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote:
> > > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> > > > All ACPI device notify callbacks are invoked using acpi_os_e
> On Sat, Jun 24, 2017 at 02:25:46AM +0200, Rafael Wysocki wrote:
> > On Wednesday, June 21, 2017 11:15:43 AM Darren Hart wrote:
> > > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> > > > All ACPI device notify callbacks are invoked using acpi_os_e
> On Fri, Jun 16, 2017 at 06:40:56AM +0200, Michał Kępień wrote:
> > Calling acpi_bus_update_power() for ACPI devices FUJ02B1 and FUJ02E3 is
> > pointless as they are not power manageable (neither _PS0 nor _PR0 is
> > defined for any of them), which causes their power
> On Fri, Jun 16, 2017 at 06:40:56AM +0200, Michał Kępień wrote:
> > Calling acpi_bus_update_power() for ACPI devices FUJ02B1 and FUJ02E3 is
> > pointless as they are not power manageable (neither _PS0 nor _PR0 is
> > defined for any of them), which causes their power
ode would be "A-press",
> "B-press", "A-release", "B-release". With the revised code the order of the
> release events would be reversed compared to the previous behaviour. That
> is, unless I've misunderstood how sparse_keymap_report_event() works.
All you wrote above is correct and this patch does change the order of
release events sent to userspace when multiple hotkeys are pressed
simultaneously. The question is: is it relevant for any practical
scenario?
Anyway, I find this matter to be of secondary importance. The primary
objective of this patch is to get rid of the kfifo. If anyone has
strong feelings about the change in event ordering, I will be happy to
revert to FIFO in v2.
--
Best regards,
Michał Kępień
ode would be "A-press",
> "B-press", "A-release", "B-release". With the revised code the order of the
> release events would be reversed compared to the previous behaviour. That
> is, unless I've misunderstood how sparse_keymap_report_event() works.
All you wrote above is correct and this patch does change the order of
release events sent to userspace when multiple hotkeys are pressed
simultaneously. The question is: is it relevant for any practical
scenario?
Anyway, I find this matter to be of secondary importance. The primary
objective of this patch is to get rid of the kfifo. If anyone has
strong feelings about the change in event ordering, I will be happy to
revert to FIFO in v2.
--
Best regards,
Michał Kępień
> On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> > All ACPI device notify callbacks are invoked using acpi_os_execute(),
> > which causes the supplied callback to be queued to a static workqueue
> > which always executes on CPU 0. This means that th
> On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> > All ACPI device notify callbacks are invoked using acpi_os_execute(),
> > which causes the supplied callback to be queued to a static workqueue
> > which always executes on CPU 0. This means that th
In preparation for splitting fujitsu-laptop into two separate modules, I
prepared two more cleanup series to minimize the amount of code being
moved around. This first series contains all patches that touch ACPI in
some way, which is why I am CCing linux-acpi as per Rafael's previous
advice.
In preparation for splitting fujitsu-laptop into two separate modules, I
prepared two more cleanup series to minimize the amount of code being
moved around. This first series contains all patches that touch ACPI in
some way, which is why I am CCing linux-acpi as per Rafael's previous
advice.
the latter has nothing to do with video and assigning an
arbitrary product ID to it is redundant.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-lapto
date_power() calls along with parts of debug
messages that they were supposed to have an effect on.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/driv
date_power() calls along with parts of debug
messages that they were supposed to have an effect on.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-l
the latter has nothing to do with video and assigning an
arbitrary product ID to it is redundant.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86
FO to LIFO). The order of release events
generated by the input device should not matter from end user
perspective as upon releasing any hotkey the firmware only produces a
single event which means "all hotkeys were released".
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
dr
FO to LIFO). The order of release events
generated by the input device should not matter from end user
perspective as upon releasing any hotkey the firmware only produces a
single event which means "all hotkeys were released".
Signed-off-by: Michał Kępień
---
drivers/platform/x86/f
function
called by fujitsu_init().
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 54cb7ae541d4..c64d53
function
called by fujitsu_init().
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 54cb7ae541d4..c64d5305ff37 100644
sections of code which invoke and check evaluation status of the
_INI methods belonging to the ACPI devices handled by the driver.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/fujitsu-laptop.c | 16
1 file changed, 16 deletions(-)
diff --git a/d
ely, if ever at all. The rest
is interesting from driver development perspective as their presence in
the logs will mean the driver is unaware of certain events, handling of
which should be implemented.
Signed-off-by: Michał Kępień <ker...@kempniu.pl>
---
drivers/platform/x86/Kco
sections of code which invoke and check evaluation status of the
_INI methods belonging to the ACPI devices handled by the driver.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/platform/x86/fujitsu
ely, if ever at all. The rest
is interesting from driver development perspective as their presence in
the logs will mean the driver is unaware of certain events, handling of
which should be implemented.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/Kconfig | 10 -
drivers/
1 - 100 of 798 matches
Mail list logo
