lkml.org 
[lkml]   [2020]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH 0/9] Add support for Microsoft Surface System Aggregator Module
On Thu, Sep 24, 2020 at 10:38 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Sep 24, 2020 at 8:59 PM Maximilian Luz <luzmaximilian@gmail.com> wrote:
> > On 9/24/20 10:26 AM, Arnd Bergmann wrote:
> > > On Thu, Sep 24, 2020 at 1:28 AM Maximilian Luz <luzmaximilian@gmail.com> wrote:
>
> > > Note that drivers that connect to the bus typically don't live in the
> > > same subdirectory as the driver that operates the bus. E.g. the
> > > battery driver would go into drivers/power/supply and the input
> > > would go into drivers/input/ or drivers/hid.
> >
> > Right. I wonder if this also holds for devices that are directly
> > dependent on a special platform though? It could make sense to have them
> > under plaform/surface rather than in the individual subsystems as they
> > are only ever going to be used on this platform. On the other hand, one
> > could argue that having them in the subsystem directories is better for
> > maintainability.
>
> Yes, absolutely. The subsystem maintainers are the ones that are
> most qualified of reviewing code that uses their subsystem, regardless
> of which bus is used underneath the device, and having all drivers
> for a subsystem in one place makes it much easier to refactor them
> all at once in case the internal interfaces are changed or common bugs
> are found in multiple drivers.

The problem is that some of the drivers are mostly reincarnation of
board files due to the platform being Windows-oriented with badly
written ACPI tables / firmware as a whole (which means a lot of quirks
are required).

--
With Best Regards,
Andy Shevchenko

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