On 12/6/20 9:32 AM, Greg Kroah-Hartman wrote:
On Sun, Dec 06, 2020 at 09:07:05AM +0200, Leon Romanovsky wrote:
On Thu, Dec 03, 2020 at 10:26:31PM +0100, Maximilian Luz wrote:
Hello,
Here is version two of the Surface System Aggregator Module (SAM/SSAM)
driver series, adding initial support for the embedded controller on 5th
and later generation Microsoft Surface devices. Initial support includes
the ACPI interface to the controller, via which battery and thermal
information is provided on some of these devices.
The previous version and cover letter detailing what this series is
about can be found at
https://lore.kernel.org/platform-driver-x86/20201115192143.21571-1-luzmaximilian@xxxxxxxxx/
This patch-set can also be found at the following repository and
reference, if you prefer to look at a kernel tree instead of these
emails:
https://github.com/linux-surface/kernel tags/s/surface-aggregator/v2
Thank you all for the feedback to v1, I hope I have addressed all
comments.
I think that it is too far fetched to attempt and expose UAPI headers
for some obscure char device that we are all know won't be around in
a couple of years from now due to the nature of how this embedded world
works.
No, that's not ok, we do this for loads of devices out there. If there
is a device that wants to be supported for Linux, and a developer that
wants to support it, we will take it.
More on that, the whole purpose of proposed interface is to debug and
not intended to be used by any user space code.
I thought that debugfs was going to be used for most of the debugging
code, or has that changed in newer versions of this patchset?
As per previous discussion (https://lkml.org/lkml/2020/9/24/96) I have
replaced the debugfs device by a misc-device with stable interface.
I also believe that this is probably the better option long-term. The
general idea is to have a device that has direct access to the
EC/transport protocol and can be used for development and prototyping.
Debugging is a part of that. So it's more akin to something raw access
via i2cdev, hidraw, or raw access to USB devices as Hans de Goede
mentioned in one of his mails. Note that the module must still be loaded
manually
Regards,
Max
