Re: [PATCH] platform/x86: fujitsu-laptop: Simplify soft key handling

, use a bitmask to filter for all > known soft keys, and use the for_each_set_bit iterator. I agree. Reviewed-by: Jonathan Woithe <jwoi...@just42.net> Regards jonathan > Cc: Jan-Marek Glogowski <glo...@fbihome.de> > Cc: Micha?? K??pie?? <ker...@kempniu.pl> > Cc: Jona

Re: [PATCH] platform/x86: fujitsu-laptop: Simplify soft key handling

, use a bitmask to filter for all > known soft keys, and use the for_each_set_bit iterator. I agree. Reviewed-by: Jonathan Woithe Regards jonathan > Cc: Jan-Marek Glogowski > Cc: Micha?? K??pie?? > Cc: Jonathan Woithe > Signed-off-by: Darren Hart (VMware) > --- > > N

Re: [PATCH] platform/x86: fujitsu-laptop: Revert UNSUPPORTED_CMD back to an int

s */ > -#define UNSUPPORTED_CMD BIT(31) > +#define UNSUPPORTED_CMD 0x8000 > > /* FUNC interface - status flags */ > #define FLAG_RFKILL BIT(5) This looks like a sensible, succinct solution to the regression. Reviewed-by: Jonathan Woithe <jwoi...@just42.net> Regards jonathan

Re: [PATCH] platform/x86: fujitsu-laptop: Revert UNSUPPORTED_CMD back to an int

BIT(31) > +#define UNSUPPORTED_CMD 0x8000 > > /* FUNC interface - status flags */ > #define FLAG_RFKILL BIT(5) This looks like a sensible, succinct solution to the regression. Reviewed-by: Jonathan Woithe Regards jonathan

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

On Sun, Mar 04, 2018 at 08:44:26PM +0100, Micha?? K??pie?? wrote: > > On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote: > > > And plain 0 doesn't look right in this concept (something like (0 << > > > 0) would probably do it). > > > > Given that all other definitions are in terms

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

On Sun, Mar 04, 2018 at 08:44:26PM +0100, Micha?? K??pie?? wrote: > > On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote: > > > And plain 0 doesn't look right in this concept (something like (0 << > > > 0) would probably do it). > > > > Given that all other definitions are in terms

Re: [PATCH 0/7] fujitsu-laptop: Consistent naming of constants

Hi Michal On Tue, Feb 27, 2018 at 10:15:32PM +0100, Micha?? K??pie?? wrote: > 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 >

Re: [PATCH 0/7] fujitsu-laptop: Consistent naming of constants

Hi Michal On Tue, Feb 27, 2018 at 10:15:32PM +0100, Micha?? K??pie?? wrote: > 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 >

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote: > On Tue, Feb 27, 2018 at 11:15 PM, Micha?? K??pie?? wrote: > > Various functions exposed by the firmware through the FUNC interface > > tend to use a consistent set of integers for denoting the type of > >

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote: > On Tue, Feb 27, 2018 at 11:15 PM, Micha?? K??pie?? wrote: > > Various functions exposed by the firmware through the FUNC interface > > tend to use a consistent set of integers for denoting the type of > > operation to be performed

Re: [PATCH v2 0/7] fujitsu-laptop: Miscellaneous cleanups

ename BACKLIGHT_POWER to BACKLIGHT_PARAM_POWER. > > - [6/7] Use BACKLIGHT_OFF instead of a numeric constant. > > - [7/7] Include due to the use of BIT(). Thanks for the revision; the result looks good to me. Collectively these changes improve the readability of the code and make its intent clear

Re: [PATCH v2 0/7] fujitsu-laptop: Miscellaneous cleanups

ename BACKLIGHT_POWER to BACKLIGHT_PARAM_POWER. > > - [6/7] Use BACKLIGHT_OFF instead of a numeric constant. > > - [7/7] Include due to the use of BIT(). Thanks for the revision; the result looks good to me. Collectively these changes improve the readability of the code and make its intent clear

Re: [PATCH 6/7] platform/x86: fujitsu-laptop: Define constants for backlight power control

On Sun, Feb 11, 2018 at 10:07:26PM +0100, Micha?? K??pie?? wrote: > 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?? > ---

Re: [PATCH 6/7] platform/x86: fujitsu-laptop: Define constants for backlight power control

On Sun, Feb 11, 2018 at 10:07:26PM +0100, Micha?? K??pie?? wrote: > 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?? > --- [cut] > +/* FUNC

Re: [PATCH 0/7] fujitsu-laptop: Miscellaneous cleanups

S7020. AFAICT it does not > conflict with the recent draft patch from Jan-Marek Glogowski and may > thus be applied independently. I agree. I'm interested to hear your thoughts in connection with my queries about patch 6 before merging. That aside, I have no issues with this series.

Re: [PATCH 0/7] fujitsu-laptop: Miscellaneous cleanups

S7020. AFAICT it does not > conflict with the recent draft patch from Jan-Marek Glogowski and may > thus be applied independently. I agree. I'm interested to hear your thoughts in connection with my queries about patch 6 before merging. That aside, I have no issues with this series.

Re: r8169 regression: UDP packets dropped intermittantly

On Wed, Dec 20, 2017 at 03:50:11PM +1030, Jonathan Woithe wrote: > On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote: > > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote: > > > This clearly indicates that not every card using the r8169 driver i

Re: r8169 regression: UDP packets dropped intermittantly

On Wed, Dec 20, 2017 at 03:50:11PM +1030, Jonathan Woithe wrote: > On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote: > > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote: > > > This clearly indicates that not every card using the r8169 driver i

Re: r8169 regression: UDP packets dropped intermittantly

On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote: > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote: > > This clearly indicates that not every card using the r8169 driver is > > vulnerable to the problem. It also explains why Holger was unable t

Re: r8169 regression: UDP packets dropped intermittantly

On Tue, Dec 19, 2017 at 01:25:23PM +0100, Michal Kubecek wrote: > On Tue, Dec 19, 2017 at 04:15:32PM +1030, Jonathan Woithe wrote: > > This clearly indicates that not every card using the r8169 driver is > > vulnerable to the problem. It also explains why Holger was unable t

Re: r8169 regression: UDP packets dropped intermittantly

Hi again This is a follow up to my earlier message. On Tue, Dec 19, 2017 at 09:02:25AM +1030, Jonathan Woithe wrote: > On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote: > > Since I've seen your postings several times now with no comment or > > resolution > >

Re: r8169 regression: UDP packets dropped intermittantly

Hi again This is a follow up to my earlier message. On Tue, Dec 19, 2017 at 09:02:25AM +1030, Jonathan Woithe wrote: > On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote: > > Since I've seen your postings several times now with no comment or > > resolution > >

Re: r8169 regression: UDP packets dropped intermittantly

Hi Holger On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote: > On 12/18/17 06:49, Jonathan Woithe wrote: > > Resend to netdev. LKML CCed in case anyone in the wider kernel community > > can suggest a way forward. Please CC responses if replying only to LKML. &g

Re: r8169 regression: UDP packets dropped intermittantly

Hi Holger On Mon, Dec 18, 2017 at 02:38:53PM +0100, Holger Hoffstätte wrote: > On 12/18/17 06:49, Jonathan Woithe wrote: > > Resend to netdev. LKML CCed in case anyone in the wider kernel community > > can suggest a way forward. Please CC responses if replying only to LKML. &g

Re: r8169 regression: UDP packets dropped intermittantly

, despite the identification of the commit which broke it. Cards using this driver will therefore remain unusable for certain workloads utilising UDP. - Original message from 14 Nov 2017 - Date: Tue, 14 Nov 2017 16:09:23 +1030 From: Jonathan Woithe To: net...@vger.kernel.org Subject: Re

Re: r8169 regression: UDP packets dropped intermittantly

, despite the identification of the commit which broke it. Cards using this driver will therefore remain unusable for certain workloads utilising UDP. - Original message from 14 Nov 2017 - Date: Tue, 14 Nov 2017 16:09:23 +1030 From: Jonathan Woithe To: net...@vger.kernel.org Subject: Re

Re: [PATCH] platform/x86: fujitsu-laptop: Fix radio LED detection

It's not a regression as such and is largely cosmetic. Others may argue differently though. BTW, it looks like you may have missed my Reviewed-by tag on this patch, sent on 25 Oct. There was also a Tested-by added by Heinrich Siebmanns on the same day: Reviewed-by: Jonathan Woithe <jwoi...@just42.net> Tested-by: Heinrich Siebmanns <h...@gmx.de> Or perhaps such peripheral tags aren't carried forward on patches like this, in which case it's a moot point. Regards jonathan

Re: [PATCH] platform/x86: fujitsu-laptop: Fix radio LED detection

metic. Others may argue differently though. BTW, it looks like you may have missed my Reviewed-by tag on this patch, sent on 25 Oct. There was also a Tested-by added by Heinrich Siebmanns on the same day: Reviewed-by: Jonathan Woithe Tested-by: Heinrich Siebmanns Or perhaps such peripheral tags aren't carried forward on patches like this, in which case it's a moot point. Regards jonathan

Re: [PATCH] platform/x86: fujitsu-laptop: Fix radio LED detection

Lifebook models (E744, E751, S7110, S8420). > > Reported-by: Heinrich Siebmanns <h...@gmx.de> > Signed-off-by: Micha?? K??pie?? <ker...@kempniu.pl> This seems to be a reasonable approach given the most recent set of observations. Assuming it tests ok on the E751: Rev

Re: [PATCH] platform/x86: fujitsu-laptop: Fix radio LED detection

Lifebook models (E744, E751, S7110, S8420). > > Reported-by: Heinrich Siebmanns > Signed-off-by: Micha?? K??pie?? This seems to be a reasonable approach given the most recent set of observations. Assuming it tests ok on the E751: Reviewed-by: Jonathan Woithe Regards jonat

Re: [PATCH 4.13 103/110] platform/x86: fujitsu-laptop: Dont oops when FUJ02E3 is not presnt

On Tue, Oct 03, 2017 at 05:27:25PM -0700, Darren Hart wrote: > On Wed, Oct 04, 2017 at 08:39:34AM +1030, Jonathan Woithe wrote: > > : > > Reviewed-by: Jonathan Woithe <jwoi...@just42.net> > > Thanks for the due diligence here Jonathan, but for stable backport >

Re: [PATCH 4.13 103/110] platform/x86: fujitsu-laptop: Dont oops when FUJ02E3 is not presnt

On Tue, Oct 03, 2017 at 05:27:25PM -0700, Darren Hart wrote: > On Wed, Oct 04, 2017 at 08:39:34AM +1030, Jonathan Woithe wrote: > > : > > Reviewed-by: Jonathan Woithe > > Thanks for the due diligence here Jonathan, but for stable backport > announcements, you don't nee

Re: [PATCH 4.13 103/110] platform/x86: fujitsu-laptop: Dont oops when FUJ02E3 is not presnt

On Tue, Oct 03, 2017 at 02:30:05PM +0200, Greg Kroah-Hartman wrote: > 4.13-stable review patch. If anyone has any objections, please let me know. As per my earlier suggestion, I'm more than happy for this to go to stable since it fixes a regression. Reviewed-by: Jonathan Woithe <jwoi...@

Re: [PATCH 4.13 103/110] platform/x86: fujitsu-laptop: Dont oops when FUJ02E3 is not presnt

On Tue, Oct 03, 2017 at 02:30:05PM +0200, Greg Kroah-Hartman wrote: > 4.13-stable review patch. If anyone has any objections, please let me know. As per my earlier suggestion, I'm more than happy for this to go to stable since it fixes a regression. Reviewed-by: Jonathan Woi

Re: NULL pointer dereference in call_fext_func [fujitsu_laptop]

On Tue, Sep 19, 2017 at 09:56:47AM +0200, Jiri Slaby wrote: > we have this report from 4.13.1: > BUG: unable to handle kernel NULL pointer dereference at 0004 > IP: call_fext_func.isra.3+0x82/0xf0 [fujitsu_laptop] > *pdpt = 35e79001 *pde = > : > It looks like fext is

Re: NULL pointer dereference in call_fext_func [fujitsu_laptop]

On Tue, Sep 19, 2017 at 09:56:47AM +0200, Jiri Slaby wrote: > we have this report from 4.13.1: > BUG: unable to handle kernel NULL pointer dereference at 0004 > IP: call_fext_func.isra.3+0x82/0xf0 [fujitsu_laptop] > *pdpt = 35e79001 *pde = > : > It looks like fext is

Re: NULL pointer dereference in call_fext_func [fujitsu_laptop]

On Tue, Sep 19, 2017 at 11:07:29AM +0300, Andy Shevchenko wrote: > On Tue, Sep 19, 2017 at 10:56 AM, Jiri Slaby wrote: > > we have this report from 4.13.1: > > BUG: unable to handle kernel NULL pointer dereference at 0004 > > IP: call_fext_func.isra.3+0x82/0xf0

Re: NULL pointer dereference in call_fext_func [fujitsu_laptop]

On Tue, Sep 19, 2017 at 11:07:29AM +0300, Andy Shevchenko wrote: > On Tue, Sep 19, 2017 at 10:56 AM, Jiri Slaby wrote: > > we have this report from 4.13.1: > > BUG: unable to handle kernel NULL pointer dereference at 0004 > > IP: call_fext_func.isra.3+0x82/0xf0 [fujitsu_laptop] > > *pdpt =

Re: Kernel error messages: leds fujitsu::radio_led: Setting an LED's brightness failed

to you, maybe you > > can point me in the right direction where to report the issue. > > No worries, that is fine, though I have CCed Jonathan Woithe, who is the > maintainer of fujitsu-laptop, and both the platform-driver-x86 mailing > list and LKML (both are open lists). This

Re: Kernel error messages: leds fujitsu::radio_led: Setting an LED's brightness failed

to you, maybe you > > can point me in the right direction where to report the issue. > > No worries, that is fine, though I have CCed Jonathan Woithe, who is the > maintainer of fujitsu-laptop, and both the platform-driver-x86 mailing > list and LKML (both are open lists). This

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: constify attribute_group structures.

21ff > drivers/platform/x86/fujitsu-laptop.o > > Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com> I have no objections to this patch - it seems like the sensible thing to do in the interests of remaining consistent with the rest of the kernel. Thanks Arvind. Reviewe

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: constify attribute_group structures.

21ff > drivers/platform/x86/fujitsu-laptop.o > > Signed-off-by: Arvind Yadav I have no objections to this patch - it seems like the sensible thing to do in the interests of remaining consistent with the rest of the kernel. Thanks Arvind. Reviewed-by: Jonathan Woithe Regards jo

Re: [PATCH] platform/x86: fujitsu-laptop: add NULL check on devm_kzalloc() return value

t's extremely unlikely in practice) so we should check for this. Reviewed-by: Jonathan Woithe <jwoi...@just42.net> > --- > drivers/platform/x86/fujitsu-laptop.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/platform/x86/fujitsu-laptop.c > b/drivers

Re: [PATCH] platform/x86: fujitsu-laptop: add NULL check on devm_kzalloc() return value

n x; > identifier fld; > @@ > > * x = devm_kzalloc(...); > ... when != x == NULL > x->fld > > Signed-off-by: Gustavo A. R. Silva These checks should be added in the interest of code correctness. devm_kzalloc() can fail (even if it's extremely unlikely in practice) so

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Mon, Jun 26, 2017 at 05:07:18PM -0700, Darren Hart wrote: > On Sat, Jun 24, 2017 at 02:25:46AM +0200, Rafael Wysocki wrote: > > > Rafael, the above rationale appears sound to me. Do you have any concerns? > > > > I actually do. > > > > While this is the case today, making the driver code

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Mon, Jun 26, 2017 at 05:07:18PM -0700, Darren Hart wrote: > On Sat, Jun 24, 2017 at 02:25:46AM +0200, Rafael Wysocki wrote: > > > Rafael, the above rationale appears sound to me. Do you have any concerns? > > > > I actually do. > > > > While this is the case today, making the driver code

Re: [PATCH 5/7] platform/x86: fujitsu-laptop: do not update ACPI device power status

On Thu, Jun 22, 2017 at 04:58:43PM -0700, Darren Hart wrote: > On Thu, Jun 22, 2017 at 11:02:35PM +0200, Micha?? K??pie?? wrote: > > > 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

Re: [PATCH 5/7] platform/x86: fujitsu-laptop: do not update ACPI device power status

On Thu, Jun 22, 2017 at 04:58:43PM -0700, Darren Hart wrote: > On Thu, Jun 22, 2017 at 11:02:35PM +0200, Micha?? K??pie?? wrote: > > > 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

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Thu, Jun 22, 2017 at 04:58:09PM -0700, Darren Hart wrote: > On Thu, Jun 22, 2017 at 10:46:19PM +0200, Micha?? K??pie?? wrote: > > > 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 >

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Thu, Jun 22, 2017 at 04:58:09PM -0700, Darren Hart wrote: > On Thu, Jun 22, 2017 at 10:46:19PM +0200, Micha?? K??pie?? wrote: > > > 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 >

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

Hi Darren On Wed, Jun 21, 2017 at 07:44:13PM -0700, Darren Hart wrote: > > I think the buffer size could probably be reduced a little without impacting > > on functionality. I suspect the value was chosen so as to be well above the > > number of events which could be generated ahead of a button

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

Hi Darren On Wed, Jun 21, 2017 at 07:44:13PM -0700, Darren Hart wrote: > > I think the buffer size could probably be reduced a little without impacting > > on functionality. I suspect the value was chosen so as to be well above the > > number of events which could be generated ahead of a button

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Wed, Jun 21, 2017 at 11:15:43AM -0700, Darren Hart wrote: > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Micha?? K??pie?? wrote: > > -#define RINGBUFFERSIZE 40 > > > > /* Debugging */ > > #define FUJLAPTOP_DBG_ERROR 0x0001 > > @@ -146,8 +144,8 @@ struct fujitsu_laptop { > > struct

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

On Wed, Jun 21, 2017 at 11:15:43AM -0700, Darren Hart wrote: > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Micha?? K??pie?? wrote: > > -#define RINGBUFFERSIZE 40 > > > > /* Debugging */ > > #define FUJLAPTOP_DBG_ERROR 0x0001 > > @@ -146,8 +144,8 @@ struct fujitsu_laptop { > > struct

Re: [PATCH 0/7] fujitsu-laptop: ACPI-related cleanups

pplying this will assist with the end-goal of splitting the driver into two modules since it will minimise the changes needed at the time the split is carried out. Reviewed-by: Jonathan Woithe <jwoi...@just42.net> Regards jonathan

Re: [PATCH 0/7] fujitsu-laptop: ACPI-related cleanups

pplying this will assist with the end-goal of splitting the driver into two modules since it will minimise the changes needed at the time the split is carried out. Reviewed-by: Jonathan Woithe Regards jonathan

Re: [PATCH v2 0/8] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Mon, May 22, 2017 at 08:53:23AM +0930, Jonathan Woithe wrote: > On Fri, May 19, 2017 at 09:44:40AM +0200, Micha?? K??pie?? wrote: > > fujitsu-laptop registers two ACPI drivers that access each other's > > module-wide structures. To improve data encaps

Re: [PATCH v2 0/8] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Mon, May 22, 2017 at 08:53:23AM +0930, Jonathan Woithe wrote: > On Fri, May 19, 2017 at 09:44:40AM +0200, Micha?? K??pie?? wrote: > > fujitsu-laptop registers two ACPI drivers that access each other's > > module-wide structures. To improve data encaps

Re: [PATCH v2 5/8] platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device

On Tue, May 23, 2017 at 11:47:06PM +0200, Micha?? K??pie?? wrote: > > On Fri, May 19, 2017 at 09:44:45AM +0200, Micha?? K??pie?? wrote: > > > It is easier to simply store a module-wide > > > pointer to the last (most likely only) FUJ02E3 ACPI device found, make > > > the aforementioned API use it

Re: [PATCH v2 5/8] platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device

On Tue, May 23, 2017 at 11:47:06PM +0200, Micha?? K??pie?? wrote: > > On Fri, May 19, 2017 at 09:44:45AM +0200, Micha?? K??pie?? wrote: > > > It is easier to simply store a module-wide > > > pointer to the last (most likely only) FUJ02E3 ACPI device found, make > > > the aforementioned API use it

Re: [PATCH v2 0/8] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Fri, May 19, 2017 at 09:44:40AM +0200, Micha?? K??pie?? wrote: > 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

Re: [PATCH v2 0/8] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Fri, May 19, 2017 at 09:44:40AM +0200, Micha?? K??pie?? wrote: > 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

Re: [PATCH v2 5/8] platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device

On Fri, May 19, 2017 at 09:44:45AM +0200, Micha?? K??pie?? wrote: > It is easier to simply store a module-wide > pointer to the last (most likely only) FUJ02E3 ACPI device found, make > the aforementioned API use it and cover our bases by warning the user if > firmware exposes multiple FUJ02E3

Re: [PATCH v2 5/8] platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device

On Fri, May 19, 2017 at 09:44:45AM +0200, Micha?? K??pie?? wrote: > It is easier to simply store a module-wide > pointer to the last (most likely only) FUJ02E3 ACPI device found, make > the aforementioned API use it and cover our bases by warning the user if > firmware exposes multiple FUJ02E3

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

On Mon, May 15, 2017 at 04:27:25PM -0700, Darren Hart wrote: > > In light of the above, I still feel the split is worth going through > > with. The question is whether Jonathan feels the same :) > > In the interest of keeping this moving... As I'm not sure there is a "right > answer" to split or

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

On Mon, May 15, 2017 at 04:27:25PM -0700, Darren Hart wrote: > > In light of the above, I still feel the split is worth going through > > with. The question is whether Jonathan feels the same :) > > In the interest of keeping this moving... As I'm not sure there is a "right > answer" to split or

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael Apologies for the delayed response - things have been a bit crazy lately. Darren's mail just now has reminded me that you were awaiting feedback. On Thu, May 11, 2017 at 03:40:28PM +0200, Micha?? K??pie?? wrote: > > You could accomplish this by making call_fext_func() not static and

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael Apologies for the delayed response - things have been a bit crazy lately. Darren's mail just now has reminded me that you were awaiting feedback. On Thu, May 11, 2017 at 03:40:28PM +0200, Micha?? K??pie?? wrote: > > You could accomplish this by making call_fext_func() not static and

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

On Tue, May 09, 2017 at 11:35:24AM +0200, Micha?? K??pie?? wrote: > > If FEXT is not below fujitsu laptop... then it is a shared function which > > either > > one of them can own and serialize (or not if fw indeed handles that). > > > > Either way, the owning driver should abstract away the

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

On Tue, May 09, 2017 at 11:35:24AM +0200, Micha?? K??pie?? wrote: > > If FEXT is not below fujitsu laptop... then it is a shared function which > > either > > one of them can own and serialize (or not if fw indeed handles that). > > > > Either way, the owning driver should abstract away the

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Tue, May 02, 2017 at 03:21:44PM +0200, Micha?? K??pie?? wrote: > In order to avoid accessing global structures from call_fext_func(), we > need to pass it an ACPI handle to FUJ02E3. This decreases code > readability in two ways: by increasing the function's parameter count > from

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Tue, May 02, 2017 at 03:21:44PM +0200, Micha?? K??pie?? wrote: > In order to avoid accessing global structures from call_fext_func(), we > need to pass it an ACPI handle to FUJ02E3. This decreases code > readability in two ways: by increasing the function's parameter count > from

Re: [PATCH 05/10] platform/x86: fujitsu-laptop: distinguish current uses of device-specific data

On Mon, Apr 24, 2017 at 03:33:29PM +0200, Micha?? K??pie?? wrote: > 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:

Re: [PATCH 05/10] platform/x86: fujitsu-laptop: distinguish current uses of device-specific data

On Mon, Apr 24, 2017 at 03:33:29PM +0200, Micha?? K??pie?? wrote: > 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:

Re: [PATCH 04/10] platform/x86: fujitsu-laptop: rework backlight power synchronization

On Mon, Apr 24, 2017 at 03:33:28PM +0200, Micha?? K??pie?? wrote: > fujitsu-laptop registers two ACPI drivers: one for ACPI device FUJ02B1 > enabling backlight control and another for ACPI device FUJ02E3 which > handles various other stuff (hotkeys, LEDs, etc.) So far, these two > drivers have

Re: [PATCH 04/10] platform/x86: fujitsu-laptop: rework backlight power synchronization

On Mon, Apr 24, 2017 at 03:33:28PM +0200, Micha?? K??pie?? wrote: > fujitsu-laptop registers two ACPI drivers: one for ACPI device FUJ02B1 > enabling backlight control and another for ACPI device FUJ02E3 which > handles various other stuff (hotkeys, LEDs, etc.) So far, these two > drivers have

Re: [PATCH 02/10] platform/x86: fujitsu-laptop: shorten names of acpi_handle fields

On Mon, Apr 24, 2017 at 03:33:26PM +0200, Micha?? K??pie?? wrote: > 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. > >

Re: [PATCH 02/10] platform/x86: fujitsu-laptop: shorten names of acpi_handle fields

On Mon, Apr 24, 2017 at 03:33:26PM +0200, Micha?? K??pie?? wrote: > 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. > >

Re: [PATCH 01/10] platform/x86: fujitsu-laptop: introduce fext_*() helper functions

On Mon, Apr 24, 2017 at 03:33:25PM +0200, Micha?? K??pie?? wrote: > Stop invoking call_fext_func() directly to improve code clarity and save > some horizontal space. Adjust whitespace to make checkpatch happy. A comment: this patch in and of itself does not seem to be worthwhile. In particular,

Re: [PATCH 01/10] platform/x86: fujitsu-laptop: introduce fext_*() helper functions

On Mon, Apr 24, 2017 at 03:33:25PM +0200, Micha?? K??pie?? wrote: > Stop invoking call_fext_func() directly to improve code clarity and save > some horizontal space. Adjust whitespace to make checkpatch happy. A comment: this patch in and of itself does not seem to be worthwhile. In particular,

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Mon, Apr 24, 2017 at 03:33:24PM +0200, Micha?? K??pie?? wrote: > 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 >

Re: [PATCH 00/10] fujitsu-laptop: use device-specific data instead of module-wide globals

Hi Michael On Mon, Apr 24, 2017 at 03:33:24PM +0200, Micha?? K??pie?? wrote: > 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 >

Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures

guys think? > > Excellent rationale, I withdraw the concern. > Jonathan? I am happy to proceed based on Michael's subsequent explanation. The changes in this patch series are reasonably extensive but should not result in any observable changes in behaviour. They represent a significant

Re: [PATCH 5/6] platform/x86: fujitsu-laptop: do not log LED registration failures

guys think? > > Excellent rationale, I withdraw the concern. > Jonathan? I am happy to proceed based on Michael's subsequent explanation. The changes in this patch series are reasonably extensive but should not result in any observable changes in behaviour. They represent a significant

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > 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

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > 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

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > 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

Re: [PATCH 0/6] fujitsu-laptop: LED cleanup

On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > 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

Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup

On Wed, Apr 05, 2017 at 08:07:54PM -0700, Darren Hart wrote: > On Thu, Apr 06, 2017 at 10:15:14AM +0930, Jonathan Woithe wrote: > > On Wed, Apr 05, 2017 at 09:55:34PM +0200, Micha?? K??pie?? wrote: > > > > On Wed, Apr 05, 2017 at 08:48:59AM +0200, Micha?? K??pie?? wrote:

Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup

On Wed, Apr 05, 2017 at 08:07:54PM -0700, Darren Hart wrote: > On Thu, Apr 06, 2017 at 10:15:14AM +0930, Jonathan Woithe wrote: > > On Wed, Apr 05, 2017 at 09:55:34PM +0200, Micha?? K??pie?? wrote: > > > > On Wed, Apr 05, 2017 at 08:48:59AM +0200, Micha?? K??pie?? wrote:

Re: [PATCH v2 03/11] platform/x86: fujitsu-laptop: merge set_lcd_level_alt() into set_lcd_level()

On Fri, Apr 07, 2017 at 09:23:47PM +0930, I wrote: > On Wed, Apr 05, 2017 at 08:49:02AM +0200, Micha?? K??pie?? wrote: > > diff --git a/drivers/platform/x86/fujitsu-laptop.c > > b/drivers/platform/x86/fujitsu-laptop.c > > index 59107a599d22..2f563aa00592 100644 > > ---

Re: [PATCH v2 03/11] platform/x86: fujitsu-laptop: merge set_lcd_level_alt() into set_lcd_level()

On Fri, Apr 07, 2017 at 09:23:47PM +0930, I wrote: > On Wed, Apr 05, 2017 at 08:49:02AM +0200, Micha?? K??pie?? wrote: > > diff --git a/drivers/platform/x86/fujitsu-laptop.c > > b/drivers/platform/x86/fujitsu-laptop.c > > index 59107a599d22..2f563aa00592 100644 > > ---

Re: [PATCH v2 03/11] platform/x86: fujitsu-laptop: merge set_lcd_level_alt() into set_lcd_level()

On Wed, Apr 05, 2017 at 08:49:02AM +0200, Micha?? K??pie?? wrote: > diff --git a/drivers/platform/x86/fujitsu-laptop.c > b/drivers/platform/x86/fujitsu-laptop.c > index 59107a599d22..2f563aa00592 100644 > --- a/drivers/platform/x86/fujitsu-laptop.c > +++ b/drivers/platform/x86/fujitsu-laptop.c >

Re: [PATCH v2 03/11] platform/x86: fujitsu-laptop: merge set_lcd_level_alt() into set_lcd_level()

On Wed, Apr 05, 2017 at 08:49:02AM +0200, Micha?? K??pie?? wrote: > diff --git a/drivers/platform/x86/fujitsu-laptop.c > b/drivers/platform/x86/fujitsu-laptop.c > index 59107a599d22..2f563aa00592 100644 > --- a/drivers/platform/x86/fujitsu-laptop.c > +++ b/drivers/platform/x86/fujitsu-laptop.c >

Re: [PATCH] platform/x86: fujitsu-laptop: update debug message logged by call_fext_func()

vdbg_printk(FUJLAPTOP_DBG_ERROR, "Failed to evaluate FUNC\n"); > return -ENODEV; > } As per discussions on the list, this change is fine, is consistent with the generic nature of possible failure modes and makes sense in the context of the other recent changes. Reviewed-by: Jonathan Woithe <jwoi...@just42.net> Regards jonathan

Re: [PATCH] platform/x86: fujitsu-laptop: update debug message logged by call_fext_func()

JLAPTOP_DBG_ERROR, "Failed to evaluate FUNC\n"); > return -ENODEV; > } As per discussions on the list, this change is fine, is consistent with the generic nature of possible failure modes and makes sense in the context of the other recent changes. Reviewed-by: Jonathan Woithe Regards jonathan

Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup

Hi Michael On Wed, Apr 05, 2017 at 09:55:34PM +0200, Micha?? K??pie?? wrote: > > 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

Re: [PATCH v2 00/11] fujitsu-laptop: backlight cleanup

Hi Michael On Wed, Apr 05, 2017 at 09:55:34PM +0200, Micha?? K??pie?? wrote: > > 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

Re: [PATCH 0/3] fujitsu-laptop: call_fext_func() cleanup

l three patches contain worthwhile improvements. I'm happy for all three of them to be merged. Reviewed-by: Jonathan Woithe <jwoi...@just42.net> FYI I am still working through the more extensive backlight cleanup series. This is a particularly busy week for me so my review comments might only come through towards the end of the week or during the weekend. Regards jonathan

Re: [PATCH 0/3] fujitsu-laptop: call_fext_func() cleanup

l three patches contain worthwhile improvements. I'm happy for all three of them to be merged. Reviewed-by: Jonathan Woithe FYI I am still working through the more extensive backlight cleanup series. This is a particularly busy week for me so my review comments might only come through towards the end of the week or during the weekend. Regards jonathan

  1   2   3   4   >