[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201206070705.GA686270@unreal>
Date: Sun, 6 Dec 2020 09:07:05 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Maximilian Luz <luzmaximilian@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, Hans de Goede <hdegoede@...hat.com>,
Mark Gross <mgross@...ux.intel.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Barnabás Pőcze <pobrn@...tonmail.com>,
Arnd Bergmann <arnd@...db.de>, Rob Herring <robh@...nel.org>,
Jiri Slaby <jirislaby@...nel.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Jonathan Corbet <corbet@....net>,
Blaž Hrastnik <blaz@...n.io>,
Dorian Stoll <dorian.stoll@...p.io>,
platform-driver-x86@...r.kernel.org, linux-serial@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 0/9] Add support for Microsoft Surface System
Aggregator Module
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@gmail.com/
>
> 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.
More on that, the whole purpose of proposed interface is to debug and
not intended to be used by any user space code.
Also the idea that you are creating new bus just for this device doesn't
really sound right. I recommend you to take a look on auxiliary bus and
use it or come with very strong justifications why it is not fit yet.
I'm sorry to say, but this series is not ready to be merged yet.
NAK: Leon Romanovsky <leon@...nel.org>
Thanks
Powered by blists - more mailing lists