se 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
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
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 of
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
> c
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
me 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
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 in
a Lifebook 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
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 is
>
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 to
&g
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
>
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
,
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
h 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
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
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
jonathan
&g
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'
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: Jonatha
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 NU
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 = 000
long' 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 list
870321ff
> 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
Re
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
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 depen
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
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
>
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 r
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
f no consequence. Applying 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
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 encap
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 a
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 mod
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 ACPI
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
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 c
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 priva
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 an
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: M
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 bee
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.
>
> Signed-off-b
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,
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
> driv
t; What do you 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 rep
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
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
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:
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
> > --- a/drivers/platform/x86/fujit
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
> @
bg_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
Regards
jonathan
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
>
ee that all 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
On Sat, Apr 01, 2017 at 01:00:23PM -0700, Darren Hart wrote:
> On Fri, Mar 31, 2017 at 01:22:02PM +0200, Micha?? K??pie?? wrote:
> > > @@ -1098,14 +1075,8 @@ static void acpi_fujitsu_laptop_notify(struct
> > > acpi_device *device, u32 event)
> > >* handled in software; its state is queried usi
Hi Michael
On Thu, Mar 30, 2017 at 08:41:15AM +0200, Micha?? K??pie?? wrote:
> I noted your concerns about error handling in the driver ... For the time
> being I would rather concentrate on the issues I personally consider more
> pressing as I will most likely lose access to modern Fujitsu hardw
On Wed, Mar 29, 2017 at 12:54:15PM -0700, Darren Hart wrote:
> On Mon, Mar 20, 2017 at 10:32:17AM +0100, Micha?? K??pie?? wrote:
> > +
> > + return error;
>
> This return path could be cleaned up a bit:
>
> error = input_register_device(input);
> if (error)
> input_fre
l some scope for making things more consistent,
especially with regard to error handling. However, that is really a
separate task which can be addressed in a later series. This present series
doesn't impact on this issue in any significant way so it makes sense that
be applied.
Reviewed-by: Jonathan Woithe
Regards
jonathan
On Tue, Mar 28, 2017 at 08:16:18AM +0200, Micha?? K??pie?? wrote:
> > On Fri, Mar 24, 2017 at 09:19:59PM +1030, Jonathan Woithe wrote:
> > > On Mon, Mar 20, 2017 at 10:32:16AM +0100, Micha?? K??pie?? wrote:
> > > > This series simplifies handling of both brig
On Fri, Mar 24, 2017 at 09:19:59PM +1030, Jonathan Woithe wrote:
> On Mon, Mar 20, 2017 at 10:32:16AM +0100, Micha?? K??pie?? wrote:
> > This series simplifies handling of both brightness key and hotkey input
> > events on Fujitsu laptops by making use of sparse keymaps. This not
On Mon, Mar 20, 2017 at 10:32:23AM +0100, Micha?? K??pie?? wrote:
> Some laptop models need to have different keycodes assigned to hotkey
> scancodes. Change the sparse keymap upon a DMI match, before the hotkey
> input device is setup.
>
> Instead of using three different callbacks in the DMI ma
On Mon, Mar 20, 2017 at 10:32:16AM +0100, Micha?? K??pie?? wrote:
> This series simplifies handling of both brightness key and hotkey input
> events on Fujitsu laptops by making use of sparse keymaps. This not
> only makes the driver shorter and, hopefully, cleaner, but also enables
> us to get ri
facilitated by these changes are also worthwhile. The patch series has been
tested on the S7020 hardware and no regressions have been observed with the
hardware devices of that platform. Please apply.
Tested-by: Jonathan Woithe
Reviewed-by: Jonathan Woithe
Regards
jonathan
Hi Michael
On Tue, Mar 14, 2017 at 11:26:26AM +0100, Micha?? K??pie?? wrote:
> This series removes backlight-related sysfs attributes from the platform
> device registered by fujitsu-laptop and does some other cleanups to
> platform device code which hopefully make it easier to understand.
Thanks
patch series is identical to V3 except for the backlight
device name fix. No regressions are evident on the hardware I have (S7020).
I am therefore happy to see this series applied. It represents a further
worthwhile improvement to the fujitsu-laptop driver which will facilitate
future maintenance and provide a more consistent basis for upcoming
improvements.
Tested-by: Jonathan Woithe
Reviewed-by: Jonathan Woithe
Regards
jonathan
Hi Michael
On Fri, Mar 10, 2017 at 10:08:49AM +0100, Micha?? K??pie?? wrote:
> > Move code responsible for backlight device registration to a separate
> > function in order to simplify error handling and decrease indentation.
> > Simplify initialization of struct backlight_properties. Use
> > KBU
ore suggest KBUILD_MODNAME be
replaced with "fujitsu-laptop" in patch 1/4.
If the above substitution is made in patch 1/4 I am happy to see this series
applied. It represents a further worthwhile improvement to the
fujitsu-laptop driver which will facilitate future maintenance and provide a
more consistent basis for upcoming improvements.
Tested-by: Jonathan Woithe
Reviewed-by: Jonathan Woithe
Regards
jonathan
On Tue, Mar 07, 2017 at 11:15:12AM +0100, Micha?? K??pie?? wrote:
> These patches should make fujitsu_init() a bit more palatable. No
> changes are made to platform device code yet, for clarity these will be
> posted in a separate series after this one gets applied.
I will test and review these a
Hi Michael
On Mon, Mar 06, 2017 at 07:47:23PM +0100, Micha?? K??pie?? wrote:
> > > In light of the above findings, what would you like to do?
> >
> > Thanks for testing, good that we caught this before the patch series was
> > applied. I think it is reasonable to skip applying this version of th
Hi Michael
Some quick feedback.
On Mon, Mar 06, 2017 at 03:31:04PM +1030, Jonathan Woithe wrote:
> > > I can add that immediately after loading the driver the value returned by
> > > a
> > > read of bl_power is 0. As noted above, setting to 1 makes no difference
&
Hi Michael
On Mon, Mar 06, 2017 at 05:49:05AM +0100, Micha?? K??pie?? wrote:
> > > With regard to patch 2/4 you wrote:
> > > > Jonathan, this *really* needs testing on relevant hardware. After
> > > > applying this patch, you should be able to turn LCD backlight on and off
> > > > using /sys/clas
Hi Michael
On Sat, Mar 04, 2017 at 12:17:23PM +1030, Jonathan Woithe wrote:
> On Wed, Mar 01, 2017 at 09:10:40AM +0100, Micha?? K??pie?? wrote:
> > These patches should make fujitsu_init() a bit more palatable. No
> > changes are made to platform device code yet, for clarit
e, improve the clarity of
the driver code and permit some minor optimisations. No regressions are
evident when tested on S7020 hardware. Please apply.
Tested-by: Jonathan Woithe
Reviewed-by: Jonathan Woithe
Regards
jonathan
Hi Michael
On Wed, Mar 01, 2017 at 09:10:40AM +0100, Micha?? K??pie?? wrote:
> These patches should make fujitsu_init() a bit more palatable. No
> changes are made to platform device code yet, for clarity these will be
> posted in a separate series after this one gets applied.
I have a prelimina
On Thu, Mar 02, 2017 at 08:19:38AM +0100, Micha?? K??pie?? wrote:
> > On Wed, Mar 01, 2017 at 09:10:40AM +0100, Micha?? K??pie?? wrote:
> > > These patches should make fujitsu_init() a bit more palatable. No
> > > changes are made to platform device code yet, for clarity these will be
> > > posted
On Wed, Mar 01, 2017 at 09:10:40AM +0100, Micha?? K??pie?? wrote:
> These patches should make fujitsu_init() a bit more palatable. No
> changes are made to platform device code yet, for clarity these will be
> posted in a separate series after this one gets applied.
Thanks for these. As for the
On Wed, Mar 01, 2017 at 07:42:52AM +0100, Micha?? K??pie?? wrote:
> Here are two minor cleanups for acpi_fujitsu_bl_notify() that I came up
> with while preparing the sparse keymap migration.
These both look innoculous at first glance. I will review them and test on
hardware within the next 48 ho
On Tue, Feb 28, 2017 at 09:33:28AM +0100, Micha?? K??pie?? wrote:
> GregKH wrote:
> > On Mon, Feb 27, 2017 at 10:17:55PM -0800, Darren Hart wrote:
> > > GregKH - Can you please confirm the above? Moving an attribute is
> > > different than
> > > the format and contents, which is what I explicitly
On Tue, Feb 28, 2017 at 09:07:04AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 27, 2017 at 10:17:55PM -0800, Darren Hart wrote:
> > > > > > > The problem I have with this driver is that it is generally
> > > > > > > oblivious to
> > > > > > > the user's chosen backlight provider. It was writte
On Mon, Feb 27, 2017 at 12:58:40PM +0800, Fengguang Wu wrote:
> Here is another bisect result. The attached reproduce-* script may
> help debug the issue.
Thanks for this. FYI the cause of this issue is already understood (refer
to previous linux-platform-driver ML discussions). The relevant par
On Mon, Feb 27, 2017 at 09:04:14AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
>
> commit: a869ab5dabf6ec5327a3b2bb366eccf80b207d76 ("platform/x86:
> fujitsu-laptop: only register backlight device if FUJ02B1 is present")
> git://git.infradead.org/users/dvhart/linux-pla
On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
> On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > Do you want me to continue to use Acked-by, or should I switch to
> > Reviewed-by?
>
> These tags do have different meanings, and have come up
On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> > On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe wrote:
> > > On Wed, Feb 08, 2017 at 02:46:23PM +0100, Micha?? K??pie?? wrote:
> >
&g
On Mon, Feb 13, 2017 at 09:14:40AM +0100, Micha?? K??pie?? wrote:
> > On Mon, Feb 13, 2017 at 10:40:15AM +0800, kernel test robot wrote:
> > > FYI, we noticed the following commit:
> > >
> > > commit: b925ff7dcd1fc45b86baaebd3442f8b484123716 ("platform/x86:
> > > fujitsu-laptop: only register bac
Michael
On Mon, Feb 13, 2017 at 10:40:15AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
>
> commit: b925ff7dcd1fc45b86baaebd3442f8b484123716 ("platform/x86:
> fujitsu-laptop: only register backlight device if FUJ02B1 is present")
> url:
> https://github.com/0day-ci/li
naming conventions within the fujitsu-laptop
driver. I'm happy for this series (patches 1-10/10) to be applied.
Signed-off-by: Jonathan Woithe
Regards
jonathan
Hi Michael
Thanks very much for the work you've put in to clean up these patches. I
very much appreciate it. I will go through them myself in the next day or
so, and most importantly test them on my hardware to confirm there are no
regressions. Some initial comments follow.
On Wed, Feb 08, 201
On Fri, Jan 13, 2017 at 02:19:15PM +0100, Micha?? K??pie?? wrote:
> > It might be worth glancing through these because the resulting renames in
> > particular definitely improved the clarity of the driver:
> >
> > Date: Thu, 17 Sep 2009
> > From: Alan Jenkins
> > Subject: [PATCH 1/4] fujitsu
Hi Michael
On Tue, Jan 17, 2017 at 12:07:33PM +0100, Micha?? K??pie?? wrote:
> Here are two minor cleanups for acpi_fujitsu_notify() that I came up
> with while preparing the sparse keymap migration. They can be reviewed
> and applied independently of the other series for fujitsu-laptop I
> poste
> Signed-off-by: Micha?? K??pie??
Acked-by: Jonathan Woithe
> ---
> Changes introduced by this patch are best viewed when whitespace changes
> are ignored.
>
> drivers/platform/x86/fujitsu-laptop.c | 152
> +-
> 1 file changed, 75 inse
ame variable keycode_r to keycode as there is no longer any need to
> differentiate between the two. Tweak indentations to make checkpatch
> happy.
>
> Signed-off-by: Micha?? K??pie??
Acked-by: Jonathan Woithe
> ---
> drivers/platform/x86/fujitsu-laptop.c | 76
>
_locked() fails.
>
> Signed-off-by: Micha?? K??pie??
Acked-by: Jonathan Woithe
> ---
> drivers/platform/x86/fujitsu-laptop.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/platform/x86/fujitsu-laptop.c
> b/drivers/platform/x8
readability.
>
> Signed-off-by: Micha?? K??pie??
Acked-by: Jonathan Woithe
> ---
> drivers/platform/x86/fujitsu-laptop.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/platform/x86/fujitsu-laptop.c
> b/drivers/platform/x86/f
On Fri, Jan 13, 2017 at 12:02:36PM +0100, Micha?? K??pie?? wrote:
> These patches should make fujitsu_init() a bit more palatable. I
> intentionally stopped after four patches, because they should do no harm
> and the next steps require some discussion.
I will review these as soon as I can, which
code into ringbuffer" debug message,
> which is now only printed upon a successful push due to the last patch).
Thanks for clarifying. It may be worth adding a comment to the effect that
the patches were tested on a Lifebook E744. That aside, I'm happy with
these clean ups.
Acked-by: Jonathan Woithe
Darren: do you want me to explicitly ack all 4 parts, or the above
sufficient for your processes?
Regards
jonathan
On Wed, Jan 11, 2017 at 09:59:29AM +0100, Micha?? K??pie?? wrote:
> I am currently preparing a patch series which makes fujitsu-laptop use a
> sparse keymap for hotkey handling. Before that will happen, though,
> acpi_fujitsu_hotkey_notify() could use a revamp because it is pretty
> hard to read a
al variables.
>
> Signed-off-by: Micha?? K??pie??
Seems sensible to me.
Acked-by: Jonathan Woithe
> ---
> Changes from v1:
>
> - This patch was not present in v1.
>
> One thing worth noting is that in case call_fext_func() returns an
> error, logolamp_get() will still
LED_OFF case, though one could argue that this is logically the
> right thing to do (even though the extra call is not needed to shut the
> LED off).
>
> Signed-off-by: Micha?? K??pie??
Acked-by: Jonathan Woithe
> ---
> Changes from v1:
>
> - Decrease indentati
On Fri, Jan 06, 2017 at 08:24:31PM +0100, Micha?? K??pie?? wrote:
> > On Thu, Jan 5, 2017 at 3:11 PM, Micha?? K??pie?? wrote:
> > > Potential errors returned by some call_fext_func() calls inside
> > > logolamp_set() are currently ignored. Rework logolamp_set() to properly
> > > handle them. Thi
LED_OFF case, though one could argue that this is logically the
> right thing to do (even though the extra call is not needed to shut the
> LED off).
>
> Signed-off-by: Micha?? K??pie??
Acked-by: Jonathan Woithe
> ---
> This is a follow-up to a recent patch, "
failures
> in that function, if you think that would be helpful.
I would welcome such a patch if you wish to submit it. My fujitsu hardware
does not have a logo lamp so I am not in a position to develop or test such
a change, but I agree that it is something we should address.
Since my Fuji
. At the end of the day it's only the
default; if for some reason it's inappropriate for any systems we could do
an override.
Acked-by: Jonathan Woithe
> Signed-off-by: Micha?? K??pie??
> ---
> Note: the rfkill-any trigger is currently only present in
> mac80211-next/maste
On Mon, Jul 04, 2016 at 12:04:12PM +0200, Matej Groma wrote:
> For the sake of internal consistency, unset maximum brightness of eco
> led and make it activatable only on values >= LED_FULL.
>
> Signed-off-by: Matej Groma
Acked-by: Jonathan Woithe
> ---
> Here is a smal
On Fri, Jul 01, 2016 at 11:29:14PM +0200, Matej Groma wrote:
> On Fri, Jul 01, 2016 at 12:19:27PM -0700, Darren Hart wrote:
> > 1) Matej, why do you want to make this change? You mention consistency with
> > other LEDs drivers - which ones? Also, why? Is there a tool or something
> > that
> > expe
1 - 100 of 155 matches
Mail list logo
