#x27;
drivers/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 cons
uot; 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ń
t approach,
I am all ears.
--
Best regards,
Michał Kępień
> 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
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ń
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 bet
(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ń
---
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
--- a
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ń
---
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ń
---
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
--- a
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ń
---
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ń
---
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ń
---
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] Incl
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
7/7. 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ń
cklight 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ń
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
> ---
>
ing in 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ń
---
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ń
---
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ń
---
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ń
---
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ł
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 before
le. 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ń 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
t this 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
Signed-off-by: Michał Kępień
ow this 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ń
he following after every reboot should be enough:
# echo "none" > /sys/class/leds/fujitsu::radio_led/trigger
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 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
; The events seen by userspace with the original code 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 there is n
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.
This
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
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
IFO). 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ń
---
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
--- a
emove 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/fu
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/
No formatting is needed when setting ACPI device name and class, so
switch to using strcpy() for this purpose.
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
> On Mon, Jun 5, 2017 at 8:03 PM, Darren Hart wrote:
> > On Thu, Jun 01, 2017 at 10:43:39PM +0200, Michał Kępień wrote:
> >> I know I have probably started sounding like a broken record by now, but
> >> I still have not seen any response (apart from the typos getting fi
potential memory leak (granted, an unlikely one), so it
might be a good idea to at least take a second look before merging.
[1] https://www.spinics.net/lists/platform-driver-x86/msg08201.html
--
Best regards,
Michał Kępień
that the first argument of the macro is a conditional
expression ("fext" is functionally equivalent to "fext != NULL" in this
case). In other words, the warning will only ever be issued if
acpi_fujitsu_laptop_add() is called at least twice - note the assignment
on the line following WARN_ONCE().
--
Best regards,
Michał Kępień
In portions of the driver which use device-specific data, rename local
variables from fujitsu_bl and fujitsu_laptop to priv in order to clearly
distinguish these parts from code that uses module-wide data.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 48
the
acpi_handle field of struct fujitsu_bl and also enables a bit more
step-by-step migration to a device-specific implementation of
call_fext_func().
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/platform/x86
redundant, so remove them.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 75 ++-
1 file changed, 38 insertions(+), 37 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 63a9b98967fa
them dynamically using devm_kzalloc() and initialize them in
acpi_fujitsu_laptop_leds_register().
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 102 +-
1 file changed, 52 insertions(+), 50 deletions(-)
diff --git a/drivers/platform/x86
the allocated memory will remain stored in a module-wide
variable until the backlight driver is extracted into a separate module.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a
fujitsu_laptop useless,
so remove that field. While we are at it, the dev field of the same
structure is assigned in acpi_fujitsu_laptop_add() but not used for
anything, so remove it as well.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 81
fujitsu-laptop registers two ACPI drivers that access each other's
module-wide structures. To improve data encapsulation and lay the
groundwork for separating the two aforementioned ACPI drivers into
separate modules, move away from module-wide global data structures by
using device-specific data
Only allocate memory for struct fujitsu_laptop when the FUJ02E3 ACPI
device is present. Use devm_kzalloc() for allocating memory to simplify
cleanup.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 20
1 file changed, 8 insertions(+), 12 deletions
. Adjust whitespace to make checkpatch happy.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 123 ++
1 file changed, 64 insertions(+), 59 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu
orry Darren). Since Darren's preferred approach
> is to drop them for the moment let's run with that. As he said, once the
> split has been made we can obviously revisit this to see if there value in
> using them in the context of the split drivers.
Jonathan, Darren, thank you for all the feedback. Silence on my behalf
has not been coincidental as I have also been busy lately and had to put
kernel stuff on the back burner. Sadly, I can also now confirm that I
will no longer have access to the E744 I used to test my patches on as
of next Monday. I will do my best to prepare v2 of this series before
that.
--
Best regards,
Michał Kępień
> On Tuesday, May 09, 2017 09:47:34 AM Darren Hart wrote:
> > On Tue, May 09, 2017 at 11:35:24AM +0200, Michał Kępień wrote:
> > > > On Sat, May 06, 2017 at 02:45:16PM +0200, Michał Kępień wrote:
> > > > > > Just to make sure we are all on the same pa
fujitsu_bl any more.
3. You mentioned earlier that you were not really fond of the fext_*()
helper functions. Would you like me to drop them and simply use
call_fext_func() with five arguments everywhere? Or should I keep
the helper functions in v2?
Thanks,
--
Best regards,
Michał Kępień
> On Sat, May 06, 2017 at 02:45:16PM +0200, Michał Kępień wrote:
> > > Just to make sure we are all on the same page here, choosing the "two
> > > separate modules, each with one driver for one ACPI device" approach
> > > would mean ending up with two
acklight and FUJ02E3 handled by fujitsu-laptop) are not related
from the perspective of the ACPI device hierarchy. Unless there is a
better way of implementing this, in which case I am open to suggestions.
--
Best regards,
Michał Kępień
rate
header file which would then be included in fujitsu-backlight.
fext_backlight() causes the FUNC method of the FUJ02E3 ACPI device to be
called. This method is marked as Serialized, which AFAIU means we do
not need a separate lock in kernel code because all calls to this method
are implicitly serialized by firmware itself.
I do not see anything "unnatural" in this approach, but I would love to
be corrected if I am wrong.
> We'll accept either with supporting evidence for why it's the better choice.
> My
> preference, under ideal conditions, would be for separate drivers, separate
> modules, one per device.
Putting my two cents in, that would be my choice, too. Among other
issues, if we choose the "one module, one driver handling two ACPI
devices" approach, only FUJ02E3 will be bound to a driver from the
kernel's perspective, while FUJ02B1 will not, even though it actually
_will_ be handled by the same driver as FUJ02E3. Sounds ugly to me, but
I would also really like to hear Rafael's opinion.
--
Best regards,
Michał Kępień
ve symbolic identifiers
> defined for the "features" parameter, but in the backlight case we are still
> using arbitrary numeric constants. Although not necessary for this patch
> set, we should consider adding feature identifiers for the other fext_*()
> calls.
> Similarly for the "op" parameter where it makes sense to do so.
Good point, I will keep that in mind for the next patch series.
--
Best regards,
Michał Kępień
{
new style:
if ((fext_leds(priv->handle, 0x0, 0x0, 0x0) & KEYBOARD_LAMPS) &&
(fext_buttons(priv->handle, 0x0, 0x0, 0x0) == 0x0)) {
old style:
while (call_fext_func(fujitsu_laptop->acpi_handle, FUNC_BUTTONS,
0x1, 0x0, 0x0) != 0 &&
i++ < MAX_HOTKEY_RINGBUFFER_SIZE)
new style:
while (fext_buttons(priv->handle, 0x1, 0x0, 0x0) != 0 &&
i++ < MAX_HOTKEY_RINGBUFFER_SIZE)
--
Best regards,
Michał Kępień
Stop invoking call_fext_func() directly to improve code clarity and save
some horizontal space. Adjust whitespace to make checkpatch happy.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 90 ---
1 file changed, 51 insertions(+), 39
module-wide variable.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index fb46652250c7..f26abc41266e 100644
As both struct fujitsu_bl and struct fujitsu_laptop represent data
associated with ACPI devices, drop the "acpi_" prefix from the names of
the relevant fields of these structures to save some horizontal space.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-lap
it is now redundant.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 89 ++-
1 file changed, 46 insertions(+), 43 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 780e11b43d27
ned-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 113 --
1 file changed, 53 insertions(+), 60 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index f26abc41266e..77082e35f26a 100644
---
fujitsu_laptop as it is now redundant. Adjust
whitespace to make checkpatch happy.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 133 +-
1 file changed, 66 insertions(+), 67 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b
() to fujitsu_backlight_register().
This makes the bl_device field of struct fujitsu_bl redundant, so remove
it.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers
In portions of the driver which use device-specific data, rename local
variables from fujitsu_bl and fujitsu_laptop to priv in order to clearly
distinguish these parts from code that uses module-wide data.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 48
-wide variable.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index 536b601c7067..780e11b43d27 100644
Prepare for not using module-wide data in call_fext_func() by explicitly
passing it an ACPI handle to the FUJ02E3 device while still using the
module-wide handle in each call to fext_*() helper functions.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 97
fujitsu-laptop registers two ACPI drivers. Whenever an ACPI device with
a matching identifier is found by the ACPI bus, a new instance of the
relevant driver is bound to that ACPI device. However, both ACPI
drivers registered by fujitsu-laptop access module-wide global data
structures, assuming n
Jonathan, I hope this response to Darren's message also addresses your
concerns. Feel free to let me know if it does not.
> On Fri, Apr 07, 2017 at 03:07:12PM +0200, Michał Kępień wrote:
> > If acpi_fujitsu_laptop_leds_register() returns an error, the latter will
> > become
ware of anything like that existing and installing the Windows
Driver Kit just to run one command which spits out a single *.h file is
not something I would describe as convenient (been there).
[1] https://www.spinics.net/lists/platform-driver-x86/msg08201.html
--
Best regards,
Michał Kępień
in reviewing my submissions. We
are getting there, I only have three more series queued after this one.
--
Best regards,
Michał Kępień
Follow common subsystem practice of selecting LEDS_CLASS instead of
riddling module code with #ifdefs.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/Kconfig | 2 +-
drivers/platform/x86/fujitsu-laptop.c | 14 +-
2 files changed, 2 insertions(+), 14 deletions
the result variable in acpi_fujitsu_laptop_add()
redundant, so remove it. Adjust whitespace to make checkpatch happy.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 128 +++---
1 file changed, 70 insertions(+), 58 deletions(-)
diff --git a
whitespace to make checkpatch happy.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 261 --
1 file changed, 124 insertions(+), 137 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index
As LED class devices registered by fujitsu-laptop no longer depend on
the platform device, two function calls inside acpi_fujitsu_laptop_add()
can be rearranged in order to simplify error handling.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 8 +++-
1 file
to make the code easier to read.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index ce658789e748
ULL inside acpi_fujitsu_laptop_remove() to prevent call_fext_func()
from generating errors upon module removal.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 55 +++
1 file changed, 11 insertions(+), 44 deletions(-)
diff --git a/drivers/platform/x
This patch series cleans up parts of fujitsu-laptop responsible for
handling LED class devices. It was tested on a Lifebook E744. It
depends on the previous patch series I submitted for fujitsu-laptop and
should be applied on top of the backlight cleanup series.
drivers/platform/x86/Kconfig
Update debug message logged when the acpi_evaluate_integer() call inside
call_fext_func() fails so that it covers a broader set of possible
errors.
Signed-off-by: Michał Kępień
---
This patch is a follow-up to v1 of the call_fext_func() cleanup series
and as such, it should be applied to for
> On Wed, Apr 05, 2017 at 08:48:59AM +0200, Michał Kępień wrote:
> > This series introduces further changes to the way LCD backlight is
> > handled by fujitsu-laptop. These changes include fixing a bug in code
> > responsible for generating brightness-related inpu
> On Wed, Apr 05, 2017 at 08:50:20AM +0200, Michał Kępień wrote:
> > This series contains a few cleanups for the call_fext_func() function.
> > Just as a reminder, please note that v1 of this series is currently
> > applied in testing.
> >
> > Changes from v1:
Use a managed backlight device to get rid of acpi_fujitsu_bl_remove().
Change the parent of the backlight device from NULL to the FUJ02B1 ACPI
device as the latter is required for the backlight device to work.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 23
the user. Bail out immediately from
acpi_fujitsu_bl_add() unless using the vendor-specific interface was
either explicitly requested by the user or automatically selected by the
kernel.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 11 ++-
1 file changed, 6
to 4 in step 2 and pressing the "brightness up" key
increases it by 1). This in turn would cause acpi_fujitsu_bl_notify()
to observe a 6 -> 5 change, i.e. a decrease in brightness, while screen
brightness would in fact be increased.
Fix this by updating brightness_level in set_lcd_l
, move that check to set_lcd_level() and get rid of
set_lcd_level_alt().
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 54 +++
1 file changed, 16 insertions(+), 38 deletions(-)
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers
local variable storing the handle. Update
debug message to reflect this change. Also do not assign a default
value to status as it has no influence on execution flow.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 13 +
1 file changed, 5 insertions(+), 8
1 - 100 of 399 matches
Mail list logo
