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  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]
Date:   Fri, 23 Oct 2020 15:04:35 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Oleksij Rempel <o.rempel@...gutronix.de>,
        Marek Vasut <marex@...x.de>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        linux-kernel@...r.kernel.org, linux-can@...r.kernel.org,
        netdev@...r.kernel.org, kernel@...gutronix.de,
        David Jander <david@...tonic.nl>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [RFC PATCH v1 0/6] add initial CAN PHY support

On 10/23/20 2:22 PM, Russell King - ARM Linux admin wrote:
> On Fri, Oct 23, 2020 at 02:14:09PM +0200, Marc Kleine-Budde wrote:
>> On 10/23/20 1:45 PM, Russell King - ARM Linux admin wrote:
>>> On Fri, Oct 23, 2020 at 12:56:20PM +0200, Oleksij Rempel wrote:
>>>> - The upcoming CAN SIC and CAN SIC XL PHYs use a different interface to
>>>>   the CAN controller. This means the controller needs to know which type
>>>>   of PHY is attached to configure the interface in the correct mode. Use
>>>>   PHY link for that, too.
>>>
>>> Is this dynamic in some form?
>>
>> There isn't any CAN SIC transceivers out there yet. I suspect there will be no
>> auto detection possible, so we would describe the type of the attached
>> transceiver via device tree.
>>
>> In the future I can think of some devices that have a MUX and use the a classic
>> transceiver (CAN high-speed) for legacy deployments and CAN SIC transceivers if
>> connected to a "modern" CAN bus.
>>
>> Someone (i.e. the user or the system integrator) has to configure the MUX to
>> select the correct transceiver.
> 
> Hmm. So it's static, and described in firmware.

The use case where the system has a MUX (to route the signals to either one or
the other transceiver), the used transceiver would be selected by software.

It's static in that sense, as there is no hotplug of unknown devices, no-one
will swap the CAN-SPF+ module against a CAN-SIC-SFP+ module :)

> So, that brings me to
> the obvious question: why use phylink for this rather than the phylib
> APIs?

Oleksij is looking at code....

> phylink isn't obsoleting phylib in any way, and phylib does support
> the ability for the PHY to change its MAC side interface (if it didn't
> then PHYs such as 88x3310 and similar wouldn't be usable.)

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists