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-next>] [day] [month] [year] [list]
Date:   Fri,  4 Feb 2022 14:36:33 +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 0/2] net: phy: micrel: add Microchip KSZ 9897 Switch PHY support

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ