Re: [PATCH v3 00/14] Add support for handling PCIe M.2 Key E connectors in devicetree

From: Bartosz Golaszewski

Date: Mon Jan 12 2026 - 05:54:19 EST


On Mon, 12 Jan 2026 09:04:15 +0100, Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> said:
> On Sat, Jan 10, 2026 at 12:26:18PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
>>

[snip]

>> Though this series adds the relevant functionality for handling the M.2 Key M
>> connectors, there are still a few open questions exists on the design.
>>
>> 1. I've used the DT compatible for the serdev swnode to match the existing OF
>> device_id of the bluetooth driver. This avoids implementing custom serdev id
>> matching as implemented till v2.
>
> Yeah, swnodes are not designed to replace the real DT or other firmware
> interface. The idea of swnodes is to have them providing quirks if needed (i.e.
> fixing up the broken or missed FW device properties). This should not have been
> done this way. Please, consider another approach, e.g. DT-overlay.
>

This may have been true historically but software nodes were introduced before
the auxiliary bus. With platform devices, the question has a clear response:
DT or ACPI first, then possibly additional software node. But with auxiliary
devices, where does the entirety of device properties come from if we - for
whatever reason - don't want to propagate any "real" firmware node?

This is not even about this particular series, rather it's a wider architecture
question.

Bartosz