On Tue, Feb 22, 2022 at 9:47 AM Clément Léger <clement.leger@xxxxxxxxxxx> wrote: > Le Tue, 22 Feb 2022 09:33:32 +0100, > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> a écrit : > > On Tue, Feb 22, 2022 at 9:24 AM Clément Léger <clement.leger@xxxxxxxxxxx> wrote: > > > Le Mon, 21 Feb 2022 19:46:12 +0200, > > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> a écrit : ... > > > The idea is to allow device with a software_node description to match > > > with the content of the of_match_table. Without this, we would need a > > > new type of match table that would probably duplicates part of the > > > of_match_table to be able to match software_node against a driver. > > > I did not found an other way to do it without modifying drivers > > > individually to support software_nodes. > > > > software nodes should not be used as a replacement of the real > > firmware nodes. The idea behind is to fill the gaps in the cases when > > firmware doesn't provide enough information to the OS. I think Heikki > > can confirm or correct me. > > Yes, the documentation states that: > > NOTE! The primary hardware description should always come from either > ACPI tables or DT. Describing an entire system with software nodes, > though possible, is not acceptable! The software nodes should only > complement the primary hardware description. > > > If you want to use the device on an ACPI based platform, you need to > > describe it in ACPI as much as possible. The rest we may discuss. > > Agreed but the PCIe card might also be plugged in a system using a > device-tree description (ARM for instance). I should I do that without > duplicating the description both in DT and ACPI ? Why is it (duplication) a problem? Each platform has its own kind of description, so one needs to provide it in the format the platform accepts. -- With Best Regards, Andy Shevchenko