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: <418e86fb-dd7b-acbb-e648-1641f06b254b@gmail.com>
Date:   Thu, 25 Mar 2021 21:44:21 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Marek BehĂșn <kabel@...nel.org>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        "David S . Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>, kuba@...nel.org
Subject: Re: [PATCH net-next v2 11/12] net: phy: marvell10g: print exact model

On 25.03.2021 21:29, Marek BehĂșn wrote:
> On Thu, 25 Mar 2021 15:54:52 +0000
> Russell King - ARM Linux admin <linux@...linux.org.uk> wrote:
> 
>> The 88X3310 and 88X3340 can be differentiated by bit 3 in the revision.
>> In other words, 88X3310 is 0x09a0..0x09a7, and 88X3340 is
>> 0x09a8..0x09af. We could add a separate driver structure, which would
>> then allow the kernel to print a more specific string via standard
>> methods, like we do for other PHYs. Not sure whether that would work
>> for the 88X21x0 family though.
> 
> According to release notes it seems that we can also differentiate
> 88E211X from 88E218X (via bit 3 in register 1.3):
>  88E211X has 0x09B9
>  88E218X has 0x09B1
> 
> but not 88E2110 from 88E2111
>     nor 88E2180 from 88E2181.
> 
> These can be differentiated via register
>   3.0004.7
> (bit 7 of MDIO_MMD_PCS.MDIO_SPEED., which says whether device is capable
>  of 5g speed)
> 

If the PHY ID's are the same but you can use this register to
differentiate the two versions, then you could implement the
match_phy_device callback. This would allow you to have separate
PHY drivers. This is just meant to say you have this option, I don't
know the context good enough to state whether it's the better one.


> I propose creating separate structures for mv88x3340 and mv88e218x.
> We can then print the remaining info as
>   "(not) macsec/ptp capable"
> or
>   "(not) 5g capable"
> 
> What do you think?
> 
> Marek
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ