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: <8b5f3a9b1ed8d31a84129dc284a95091aebb25fd.camel@redhat.com>
Date:   Tue, 20 Dec 2022 10:40:40 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Enguerrand de Ribaucourt 
        <enguerrand.de-ribaucourt@...oirfairelinux.com>,
        netdev@...r.kernel.org
Cc:     woojung.huh@...rochip.com, davem@...emloft.net,
        UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH] net: lan78xx: isolate LAN88XX specific operations

On Fri, 2022-12-16 at 15:49 +0100, Enguerrand de Ribaucourt wrote:
> Some operations during the cable switch workaround modify the register
> LAN88XX_INT_MASK of the PHY. However, this register is specific to the
> LAN8835 PHY. For instance, if a DP8322I PHY is connected to the LAN7801,
> that register (0x19), corresponds to the LED and MAC address
> configuration, resulting in unapropriate behavior.
> 
> Fixes: 14437e3fa284 ("lan78xx: workaround of forced 100 Full/Half duplex mode error")

AFACS LAN7801 support was introduced after the above commit, so I guess
 89b36fb5e532 ("lan78xx: Lan7801 Support for Fixed PHY")
should be a better fixes tag.

> Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@...oirfairelinux.com>
> ---
>  drivers/net/usb/lan78xx.c | 28 ++++++++++++++++++----------
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index f18ab8e220db..ea0a56e6cd40 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -2116,6 +2116,7 @@ static void lan78xx_link_status_change(struct net_device *net)
>  {
>  	struct phy_device *phydev = net->phydev;
>  	int temp;
> +	bool lan88_fixup;
>  
>  	/* At forced 100 F/H mode, chip may fail to set mode correctly
>  	 * when cable is switched between long(~50+m) and short one.
> @@ -2123,10 +2124,15 @@ static void lan78xx_link_status_change(struct net_device *net)
>  	 * at forced 100 F/H mode.
>  	 */
>  	if (!phydev->autoneg && (phydev->speed == 100)) {
> -		/* disable phy interrupt */
> -		temp = phy_read(phydev, LAN88XX_INT_MASK);
> -		temp &= ~LAN88XX_INT_MASK_MDINTPIN_EN_;
> -		phy_write(phydev, LAN88XX_INT_MASK, temp);
> +		lan88_fixup = (PHY_LAN8835 & 0xfffffff0) ==
> +			(phydev->phy_id & 0xfffffff0);
> +
> +		if(lan88_fixup) {
> +			/* disable phy interrupt */
> +			temp = phy_read(phydev, LAN88XX_INT_MASK);
> +			temp &= ~LAN88XX_INT_MASK_MDINTPIN_EN_;
> +			phy_write(phydev, LAN88XX_INT_MASK, temp);
> +		}

Why don't you use instead something alike:

		phy_config_interrupt(phydev, 0);

		//force 10 and 100 speed

		phy_config_interrupt(phydev, 1);

so that you properly keep interrupt disabled regardless of the chip
version?

Thanks!

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ