mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Gross <mgross@linux.intel.com>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/6] platform/surface: Add Surface Aggregator device registry
Date: Mon, 8 Feb 2021 21:04:25 +0100	[thread overview]
Message-ID: <33e4cf40-4ed8-0b82-d4b2-ec483d8562e1@gmail.com> (raw)
In-Reply-To: <d11ec6b6-8fca-7174-3be8-22683798ffb6@redhat.com>

On 2/8/21 8:55 PM, Hans de Goede wrote:
> Hi,
> 
> On 2/8/21 8:35 PM, Maximilian Luz wrote:
>> The Surface System Aggregator Module (SSAM) subsystem provides various
>> functionalities, which are separated by spreading them across multiple
>> devices and corresponding drivers. Parts of that functionality / some of
>> those devices, however, can (as far as we currently know) not be
>> auto-detected by conventional means. While older (specifically 5th- and
>> 6th-)generation models do advertise most of their functionality via
>> standard platform devices in ACPI, newer generations do not.
>>
>> As we are currently also not aware of any feasible way to query said
>> functionalities dynamically, this poses a problem. There is, however, a
>> device in ACPI that seems to be used by Windows for identifying
>> different Surface models: The Windows Surface Integration Device (WSID).
>> This device seems to have a HID corresponding to the overall set of
>> functionalities SSAM provides for the associated model.
>>
>> This series introduces a device registry based on software nodes and
>> device hubs to solve this problem. The registry is intended to contain
>> all required non-detectable information.
>>
>> The platform hub driver is loaded against the WSID device and
>> instantiates and manages SSAM devices based on the information provided
>> by the registry for the given WSID HID of the Surface model. All new
>> devices created by this hub added as child devices to this hub.
>>
>> In addition, a base hub is introduced to manage devices associated with
>> the detachable base part of the Surface Book 3, as this requires special
>> handling (i.e. devices need to be removed when the base is removed).
>> Again, all devices created by the base hub (i.e. associated with the
>> base) are added as child devices to this hub.
>>
>> In total, this will yield the following device structure
>>
>>    WSID
>>     |- SSAM device 1 (physical device)
>>     |- SSAM device 2 (physical device)
>>     |- SSAM device 3 (physical device)
>>     |- ...
>>     \- SSAM base hub (virtual device)
>>        |- SSAM base device 1 (physical device)
>>        |- SSAM base device 2 (physical device)
>>        |- ...
>>
>> While software nodes seem to be well suited for this approach due to
>> extensibility, they still need to be hard-coded, so I'm open for ideas
>> on how this could be improved.
> 
> This series looks good to me.
> 
> One question is this 5.12 material, or is this intended for 5.13
> (together with drivers attaching to the newly instantiated devices) ?
> 
> I can drop this into for-next tomorrow, that gives it just about
> enough "baking" time in -next to still make it into 5.12
> (this should be pretty safe to push to for-next despite it being
> somewhat close to the cutoff point as it is a new driver).
> 
> Maximilian, do you want me to add this series to for-next tomorrow,
> or would you prefer for it to go to -next after 5.12-rc1
> (and thus end up in 5.13) ?

I wouldn't mind giving this a bit more time to maybe collect some more
reviews.

The only real functionality that depends on this and would be ready for
5.12 right now is the performance profile. Everything else will have to
go into 5.13 anyway (still need to cleanup and prepare patches for
that), so 5.13 seems to be the better target for me.

Regards,
Max

> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
> 
>>
>> Maximilian Luz (6):
>>    platform/surface: Set up Surface Aggregator device registry
>>    platform/surface: aggregator_registry: Add base device hub
>>    platform/surface: aggregator_registry: Add battery subsystem devices
>>    platform/surface: aggregator_registry: Add platform profile device
>>    platform/surface: aggregator_registry: Add DTX device
>>    platform/surface: aggregator_registry: Add HID subsystem devices
>>
>>   MAINTAINERS                                   |   1 +
>>   drivers/platform/surface/Kconfig              |  26 +
>>   drivers/platform/surface/Makefile             |   1 +
>>   .../surface/surface_aggregator_registry.c     | 641 ++++++++++++++++++
>>   4 files changed, 669 insertions(+)
>>   create mode 100644 drivers/platform/surface/surface_aggregator_registry.c
>>
> 

  reply	other threads:[~2021-02-08 21:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 19:35 Maximilian Luz
2021-02-08 19:35 ` [PATCH 1/6] platform/surface: Set up " Maximilian Luz
2021-02-09  0:30   ` Maximilian Luz
2021-02-08 19:35 ` [PATCH 2/6] platform/surface: aggregator_registry: Add base device hub Maximilian Luz
2021-02-08 19:35 ` [PATCH 3/6] platform/surface: aggregator_registry: Add battery subsystem devices Maximilian Luz
2021-02-08 19:35 ` [PATCH 4/6] platform/surface: aggregator_registry: Add platform profile device Maximilian Luz
2021-02-08 19:35 ` [PATCH 5/6] platform/surface: aggregator_registry: Add DTX device Maximilian Luz
2021-02-08 19:35 ` [PATCH 6/6] platform/surface: aggregator_registry: Add HID subsystem devices Maximilian Luz
2021-02-08 19:55 ` [PATCH 0/6] platform/surface: Add Surface Aggregator device registry Hans de Goede
2021-02-08 20:04   ` Maximilian Luz [this message]
2021-02-08 20:07     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33e4cf40-4ed8-0b82-d4b2-ec483d8562e1@gmail.com \
    --to=luzmaximilian@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®