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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 28 Mar 2022 15:27:00 +0200
From:   Clément Léger <>
To:     Andrew Lunn <>
Cc:     Heiner Kallweit <>,
        Russell King <>,
        "David S . Miller" <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Horatiu Vultur <>,
        Thomas Petazzoni <>,
        Alexandre Belloni <>,
        Allan Nielsen <>,,
Subject: Re: [net-next 1/5] net: mdio: fwnode: add fwnode_mdiobus_register()

Le Mon, 28 Mar 2022 15:03:16 +0200,
Andrew Lunn <> a écrit :

> > > 
> > > Does fwnode have any documentation? How does a developer know what
> > > properties can be passed? Should you be adding a
> > > 
> > > Documentation/fwnode/bindings/net/mdio.yaml ?
> > > 
> > > 	Andrew  
> > 
> > Hi Andrew,
> > 
> > Actually, fwnode is an abstraction for various firmware nodes such as
> > ACPI, device-tree and software nodes. It allows to access properties,
> > child and other attributes transparently from these various nodes but
> > does not actually defines how they should describe the hardware. If
> > there is specific hanling to be done, node type can be checked using
> > is_acpi_node(), is_of_node() and so on.
> > 
> > I think it is still needed to document the bindings for each node type.  
> But you seem to be implementing a subset of what each node type
> supports. So maybe it would be good to document which parts of the OF
> binding can be used, which parts of the ACPI binding can be used, etc.

With this series, fwnode_mdiobus_register() supports exactly the same
subset that is supported by of_mdiobus_register(). This is not true for
ACPI though, but I could easily add this support providing that someone
could test it. Or I can left it as is and document that ACPI is not
supported and add some checks to avoid fwnode_mdiobus_register being
called with an ACPI node. What would you prefer ?

The goal in the end is to be able to use only fwnode_mdiobus_register()
to register mdiobus device whatever the node type.

> 	Andrew

Clément Léger,
Embedded Linux and Kernel engineer at Bootlin

Powered by blists - more mailing lists