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
| ||
|
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.
Powered by blists - more mailing lists