[lkml]   [2020]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/9] Add support for Microsoft Surface System Aggregator Module
On 9/25/20 4:58 PM, Andy Shevchenko wrote:
> On Thu, Sep 24, 2020 at 10:17 PM Maximilian Luz <> wrote:
>> On 9/24/20 10:30 AM, Andy Shevchenko wrote:
>>> On Wed, Sep 23, 2020 at 6:32 PM Arnd Bergmann <> wrote:
>>>> On Wed, Sep 23, 2020 at 5:15 PM Maximilian Luz <> wrote:
> ...
>>>> I think this should go to drivers/platform/x86 or drivers/platform/surface/
>>>> along with other laptop vendor specific code rather than drivers/misc/.
>>> +1 here. drivers/platform/surface is a good place to start.
>>> And you may begin with moving a few Surface drivers out of PDx86 to
>>> the new folder.
>> Perfect, thanks! I'll draft up a patch series over the weekend.
>> A couple questions regarding structure and maintenance:
>> - Should I CC the platform-driver-x86 list on future submissions to
>> drivers/platform/surface? I.e. is this something you would want to
>> review if it doesn't touch the drivers/platform/x86 directory?
> Include PDx86 mailing list to the list of that. Current SURFACE*
> drivers have per driver record in MAINTAINERS IIRC. So, update them as
> well if needed.

Will do.

>> - How would you want the layout to be, specifically regarding to the
>> surface-aggregator stuff? My suggestion would be simply:
>> drivers/platform/surface/
>> surface_aggregator/
> Don't repeat parts of the path, the aggregator is enough as a folder
> name, but the driver of course should be in its own namespace
> ('surface').


>> Kconfig
>> Makefile
>> core.c
>> controller.c
>> ... (all core stuff built into the surface_aggregator module)
>> Kconfig
>> Makefile
>> surface_aggregator_debugfs.c
> (Not sure why it's not a part of aggregator folder)

I kind of thought of the aggregator folder to contain only files that
build the core module. surface_aggregator_debugfs is intended as
separate module, to be loaded when needed. So I'd consider it a client
driver to the aggregator in the same way that surface_acpi_notify is.

Let me know if you still want me to move this into the aggregator folder
though. Personally, I just feel that that might lead to a bit of
confusion, specifically the idea that it's built into the core when it's

>> surface_acpi_notify.c
>> surface_*.c (any other surface platform driver as well
>> as drivers dependent on surface_aggregator)
>> - Regarding future things like HID transport driver, battery/AC driver:
>> Submit them to drivers/platform/surface or to their respective
>> subsystem directories?
> Respective subsystem _if_ it is a subsystem related driver and not
> kinda board file. Use common sense and existing examples.

Right, thank you!


 \ /
  Last update: 2020-09-25 17:43    [W:0.061 / U:12.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site