linux-kernel - Re: [PATCH 2/4] firmware: arm

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: <aADhoX4Rkx8Eu_er@pluto>
Date: Thu, 17 Apr 2025 12:10:25 +0100
From: Cristian Marussi <cristian.marussi@....com>
To: Johan Hovold <johan@...nel.org>
Cc: Cristian Marussi <cristian.marussi@....com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	arm-scmi@...r.kernel.org, sudeep.holla@....com,
	james.quinlan@...adcom.com, f.fainelli@...il.com,
	vincent.guittot@...aro.org, peng.fan@....nxp.com,
	michal.simek@....com, quic_sibis@...cinc.com,
	dan.carpenter@...aro.org, maz@...nel.org
Subject: Re: [PATCH 2/4] firmware: arm_scmi: Add Quirks framework

On Thu, Apr 17, 2025 at 10:44:24AM +0200, Johan Hovold wrote:
> On Wed, Apr 16, 2025 at 05:37:13PM +0100, Cristian Marussi wrote:
> > On Wed, Apr 16, 2025 at 06:00:37PM +0200, Johan Hovold wrote:
> > > On Tue, Apr 15, 2025 at 03:29:31PM +0100, Cristian Marussi wrote:
> 
> > > > +static void scmi_enable_matching_quirks(struct scmi_info *info)
> > > > +{
> > > > +	struct scmi_revision_info *rev = &info->version;
> > > > +	const char *compatible = NULL;
> > > > +	struct device_node *root;
> > > > +
> > > > +	root = of_find_node_by_path("/");
> > > > +	if (root) {
> > > > +		of_property_read_string(root, "compatible", &compatible);
> > > 
> > > Looks like you still only allow matching on the most specific compatible
> > > string.
> > > 
> > > As we discussed in the RFC thread, this will result in one quirk entry
> > > for each machine in a SoC family in case the issue is not machine
> > > specific.
> > 
> > Well, yes but the solution would be to add multiple compatible on the
> > same quirk line, which is definitely less cumbersome than adding
> > multiple quirk defs for the same quirk but does NOT scale anyway....
> > 
> > ...anyway I will add that possibility..or I am missing something more ?
> 
> I was referring to the need to match on other compatible strings than
> the most specific one. For the ThinkPad T14s the strings are:
> 
> 	"lenovo,thinkpad-t14s-lcd", "lenovo,thinkpad-t14s",
> 	"qcom,x1e78100", "qcom,x1e80100"
> 
> Here you most certainly would not want to match on
> "lenovo,thinkpad-t14s-lcd" but rather on "lenovo,thinkpad-t14s" or one
> of the SoC compatibles.
> 
> For the FC quirk we may have to match on compatible and then a single
> SoC entry could cover tens of machines (and their SKU variants).
> 
> of_machine_is_compatible() can be used to match on any compatible
> string, but not sure if that fits with your current implementation.
>  

Yes I know, it will need a bit of rework on my side...the problem is
that anyway does not scale at all, even though matching on SoC could be
less cumbersome ... and the reason is that it is fundamentally wrong
to match SCMI Quirks on anything different from the SCMI vendor/subv/impl_ver
since these are fixes/workarounds against quirks that are completely Vendor
and fw-version specific...

...instead now we are considering using compatibles to overcome the fact
that the vendor probably messed (or will mess up) also the side of
the story related to SCMI fw versions management ... "quirking" SCMI stuff
on platform/sku compatibles is basically a quirk against their broken
fw release process...

...moreover this kind of carpet-quirking that hides the issue on any possible
fw version gives ZERO incentives to the aforementioned vendor to fix its
firmware...(or it fw-release process)...

Indeed, cross posting from your other mail thread, as of now we cannot
even be sure if the Vendor has somehow already updated the SCMI-related
firmware NEITHER we can be sure about this in the future since it has not
even confirmed how they are (or they will) be handling the Impl_Version field...

Having said that, I would add that in this specific case (FC quirk) since the
only way to make use of all of this SCMI stuff from the MicroZoft/ACPI world
is having working FCs and, since it's clear that our lovely vendor wont
certainly break this other lovely OS way of working with SCMI, MAYBE it could
be safe to just apply the quirk to this Vendor forever no matter what the
platform or FW version will be in the future...(so not using compats at all)

...but I will be very happy to leave all of these political/phylosophycal
decisions to Sudeep :P

Thanks,
Cristian