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] [day] [month] [year] [list]
Date:   Fri, 23 Oct 2020 22:53:36 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        David Jander <david@...tonic.nl>, kernel@...gutronix.de,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Russell King <linux@...linux.org.uk>, mkl@...gutronix.de,
        Marek Vasut <marex@...x.de>, linux-can@...r.kernel.org
Subject: Re: [RFC PATCH v1 1/6] net: phy: add CAN PHY Virtual Bus

On Fri, Oct 23, 2020 at 12:56:21PM +0200, Oleksij Rempel wrote:
> Most of CAN PHYs (transceivers) are not attached to any data bus, so we
> are not able to communicate with them. For this case, we introduce a CAN
> specific virtual bus to make use of existing PHY framework.

I don't think you are making the best use of the phylib framework.

MDIO busses can be standalone devices, with their own DT nodes. And
that device node can list the PHY devices on the bus.

can_mdio {
	compatible = "virtual,mdio-virtual";
        #address-cells = <1>;
        #size-cells = <0>;

	canphy0: can-phy@0 {
		compatible = "can,generic-transceiver",
		reg = <0>;
	}
	canphy1: can-phy@1 
		compatible = "nxp,tja1051",
		reg = <1>
	}
}

When you call of_mdiobus_register(fmb->mii_bus, np) it will parse this
tree and should create PHY devices for them, and since your PHY driver
has a match function, it should then bind the correct PHY driver.

Your 'MAC' driver then uses phy-handle as normal to point to the PHY.

There is also some interesting overlap here with what Intel posted
recently:

https://www.spinics.net/lists/kernel/msg3706164.html

I'm not sure anything can be shared here, but it is worth looking at
and thinking about.

    Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ