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 
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:


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.

Powered by blists - more mailing lists