Re: [PATCH net-next v2 3/4] net: dsa: mxl862xx: add devlink flash_update and info_get

[Jakub Kicinski]

On Tue, 14 Jul 2026 20:14:56 +0100 Daniel Golle wrote:
> On Tue, Jul 14, 2026 at 01:51:02AM +0100, Daniel Golle wrote:
> [...]
> > +	if (!of_property_read_string_index(ds->dev->of_node, "compatible", 0,
> > +					   &compatible)) {
> > +		ret = devlink_info_version_fixed_put(req,
> > +						     DEVLINK_INFO_VERSION_GENERIC_ASIC_ID,
> > +						     compatible);  
> 
> Review of the fwupd counterpart of this series[1] made me reconsider
> what the driver reports as the "asic.id" fixed version. The devicetree
> compatible string used here ("maxlinear,mxl86252") turned out to be an
> unfortunate choice as the comma is awkward for userspace consumers, so
> for v3 I plan to follow the mv88e6xxx example and report a chip name
> from a per-model info table instead:
> 
>   fixed:
>     asic.id MaxLinear MxL86252
> 
> Before sending v3 I would like to clarify the preferred format of the
> value. Existing implementations differ: mv88e6xxx reports for example
> "Marvell 88E6085", including the vendor name and a space, sja1105
> reports "SJA1105E", hellcreek reports "hellcreek", and bnxt and ionic
> report bare chip identifiers.
> 
> Documentation/networking/devlink/devlink-info.rst only describes
> "asic.id" as "ASIC design identifier" without any format constraints.
> 
> Userspace builds firmware matching identifiers from these values, in
> the case of fwupd for example
> 
>   MDIO_BUS\COMPONENT_fw&ASIC.ID_MaxLinear MxL86252
> 
> and while a space works there, such identifiers commonly avoid spaces
> in favour of underscores, hyphens or dots.
> 
> Is there a preference for new drivers? Should the vendor name be part
> of "asic.id" as done by mv88e6xxx, or would a single token such as
> "MxL86252" be more appropriate?
> 
> [1] https://github.com/fwupd/fwupd/pull/10667

The embedded drivers are probably doing it wrong, I wasn't paying
enough attention. devlink versions are supposed to be broken up into
components, the vendor name does not belong in asic id.

IIUC asic.id was supposed to be the numerical version of the design
(excluding revision, which is asic.rev). Something that's usually read
from a static CSR.