linux-kernel - Re: [PATCH v3 3/3] platform/surface: Add OF support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VcbjR8HQqPASLFEGiyYLfTFQDa6Ri+jFy+7Q1xz7gY39Q@mail.gmail.com>
Date: Wed, 28 Aug 2024 19:56:42 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Maximilian Luz <luzmaximilian@...il.com>
Cc: Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, Hans de Goede <hdegoede@...hat.com>, 
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, linux-serial@...r.kernel.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.org, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <quic_kdybcio@...cinc.com>
Subject: Re: [PATCH v3 3/3] platform/surface: Add OF support

On Wed, Aug 28, 2024 at 12:10 PM Maximilian Luz <luzmaximilian@...il.com> wrote:

> I thought I should provide some context:

Thank you, my reply below.

> Am 26/08/2024 um 22:54 schrieb Andy Shevchenko:
> > Wed, Aug 14, 2024 at 12:27:27PM +0200, Konrad Dybcio kirjoitti:
> >> From: Konrad Dybcio <quic_kdybcio@...cinc.com>

[...]

> >>      nodes = (const struct software_node **)acpi_device_get_match_data(&pdev->dev);
> >
> > Hmm... Why this doesn't use simple device_get_match_data()?
> >
> >> -    if (!nodes)
> >> -            return -ENODEV;
> >> +    if (!nodes) {
> >> +            fdt_root = of_find_node_by_path("/");
> >> +            if (!fdt_root)
> >> +                    return -ENODEV;
> >> +
> >> +            match = of_match_node(ssam_platform_hub_of_match, fdt_root);
> >> +            of_node_put(fdt_root);
> >> +            if (!match)
> >> +                    return -ENODEV;
> >> +
> >> +            nodes = (const struct software_node **)match->data;
> >
> > This is quite strange! Where are they being defined?
>
> Essentially, this whole module is a giant workaround because there
> doesn't seem to be a way to auto-discover which functions or subdevices
> the EC actually supports. So this module builds a registry of software
> nodes and matches against a Surface-model-specific ACPI ID (in ACPI
> mode). Based on that ID, we retrieve the tree of software nodes that
> define the EC subdevices and register them using a (virtual) platform
> hub device.
>
> The snippet way above registers the platform hub device for DT,
> because there we don't have an equivalent ACPI device that we can
> use. The code here retrieves the respective nodes.

Yes, and software nodes for DT are quite strange things! Why can't you
simply fix the DT to begin with?

> >> +            if (!nodes)
> >> +                    return -ENODEV;
> >> +    }

...

> >> +MODULE_ALIAS("platform:surface_aggregator_platform_hub");
> >
> > Can it be platfrom device ID table instead? But do you really need it?
> >
>
> I think the explanation above already kind of answers this, but the
> module is named differently than the driver (so that they reflect the
> specific nature of each, registry vs hub device). And the platform hub
> device added in the snippet I left above is named after the driver. So
> for the registry module to load when the platform hub driver is
> requested, it is needed.

So, I believe it warrants a platform device ID table to make it explicit.

-- 
With Best Regards,
Andy Shevchenko