linux-kernel - Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Feb 2017 07:57:02 +0100
From:   Michał Kępień <kernel@...pniu.pl>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Jonathan Woithe <jwoithe@...t42.net>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups

> Regarding ACPI case and device presents you may assume it if you just call
> acpi_walk_namespace() (AFAIU) and check _STA for the device if it's in
> the table.
> 
> So, at any point you may have got understanding if device is present
> or not, and if it's active or not.

Thank you for the tip, though I am a bit confused, sorry.  I infer the
above is a response to this part of my message:

> >     On the other hand, registering the platform device before the ACPI
> >     driver is also incorrect due to reasons I already pointed out in
> >     another thread (in short: we cannot _assume_ FUJ02E3 is present).

Perhaps my wording was inaccurate, but I do not have a technical problem
with detecting an ACPI device.  Instead, this passage was meant to be a
reference to the fourth paragraph of my cover letter for the series
titled "fujitsu_init() cleanup", i.e. the lengthy one awaiting comments
from you and/or Darren.  For your convenience, here is the paragraph in
question (roughly the second half is relevant):

> That would leave us with the remaining three sysfs attributes of the
> platform device, namely dock, lid and radios.  These all depend on the
> FUJ02E3 ACPI device.  Which begs the question: shall we reassign them to
> that ACPI device and drop the platform device altogether?  This would
> logically be the correct thing to do (panasonic-laptop and toshiba_acpi
> already assign extra sysfs attributes to ACPI nodes).  But I understand
> that this would break an 8-year-old userspace interface as functions
> previously exposed through /sys/devices/platform/fujitsu-laptop would be
> moved to /sys/bus/acpi/devices/FUJ02E3:00.  If that is unacceptable, the
> least we can (and should) do is to move platform device registration to
> acpi_fujitsu_hotkey_add().  What the driver currently does may create
> confusion in the future, because the platform device is registered
> unconditionally while it clearly depends on FUJ02E3 being present.  I do
> not know whether FUJ02E3 is present on all Fujitsu devices today without
> exception, but I do know that if Fujitsu ever decides to drop that
> device from its firmware, we would again (see above) expose a userspace
> interface (dock, lid, radios) which simply will not be able to function
> properly.

Perhaps things will become a bit more clear once you dig through that
thread :)

-- 
Best regards,
Michał Kępień