netdev - [PATCH v2 0/2] net: phy: micrel: add Microchip KSZ 9897 Switch PHY

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-next>] [day] [month] [year] [list]

Date:   Mon,  7 Feb 2022 18:45:31 +0100
From:   Enguerrand de Ribaucourt 
        <enguerrand.de-ribaucourt@...oirfairelinux.com>
To:     netdev@...r.kernel.org
Cc:     andrew@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk
Subject: [PATCH v2 0/2] net: phy: micrel: add Microchip KSZ 9897 Switch PHY

v2: I was on my way to convert the .phy_id_mask to PHY_ID_MATCH_EXACT()
following reviews, but I discovered that the datasheet actually contained PHY id
registers but they do not correspond to RMII ports. I rechecked the phy_id value
on my KSZ9897 and confirmed that I did not make this up. But this lead me to
find that the KSZ8081 revision A2's datasheet shared the exact same phy_id.
Hence, in order not to break compatibility with this model, I wrote a new way to
differenciate them with the default LED MODE configuration instead of
PHY_ID_MATCH_EXACT() by mimicking ksz8051_ksz8795_match_phy_device().

I abstained from converting MICREL_PHY_ID_MASK to PHY_ID_MATCH_MODEL() because
it is used in other drivers, and would take a very long time to check all the
datasheets of these models.

Thanks again to Andrew Lunn for your reviews and suggestions.

Original patch v1 discussion:
https://lore.kernel.org/all/20220204133635.296974-1-enguerrand.de-ribaucourt@savoirfairelinux.com/

---

Hi,
I've recently used a KSZ9897 DSA switch that was connected to an i.MX6 CPU
through SPI for the DSA control, and RMII as the data cpu-port. The SPI/DSA was
well supported in drivers/net/dsa/microchip/ksz9477.c, but the RMII connection
was not working. I would like to upstream the patch I developped to add support
for the KSZ9897 RMII bus. This is required for the cpu-port capability of
the DSA switch and have a complete support of this DSA switch.

Since PHY_ID_KSZ9897 and PHY_ID_KSZ8081 are very close, I had to modify the mask
used for the latter. I don't have this one, so it would be very appreciated if
someone could test this patch with the KSZ8081 or KSZ8091. In particular, I'd
like to know the exact phy_id used by those models to check that the new mask is
valid, and that they don't collide with the KSZ9897. The phy_ids cannot be found
in the datasheet, so I couldn't verify that myself.

My definition of the struct phy_driver was copied from the similar
PHY_ID_KSZ8873MLL and proved to work on a 5.4 kernel. However, my patch may not
support the Gigabit Ethernet but works reliably otherwise.

The second patch fixes an issue with the KSZ9477 declaration I noticed. I
couldn't find PHY_ID_KSZ9477, or an equivalent mask in the MODULE_DEVICE_TABLE
declaration. I fear the driver is not initialized properly with this PHY. I
don't have this model either so it would be great if someone could test this.