Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp598390pxf; Wed, 31 Mar 2021 11:00:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzare118OmPnE5gYqNAEqi9QaSzXoy1WEzx/y3oC0JMxCn+oeyT5MXt+qfcw2AslUVwXK9+ X-Received: by 2002:a17:906:6882:: with SMTP id n2mr4923336ejr.50.1617213646370; Wed, 31 Mar 2021 11:00:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617213646; cv=none; d=google.com; s=arc-20160816; b=gcGIaqLuF2eWBXoXNEGf/l2ewffEghFMC/Kn/h/QjV0KWmUquiNFvdapVquGpOrJ+h WSG0MNtsBJCNm3NVtNsLCxMmWXYI+d1WnMgks6GKUrsyW+lPGoKh0E/bG/2MpBPqOpGL WeZ1WjNReiOMrX+UNtpCVDX8QIANmlIQN8IqF/NXwkfFRK31MnNTf8FB/H+J9NXMCbKT cFZjbsp8RV+ESeOzSn2Z5mIdzVlq8/r2rWRuBkxIOjV5uney6V2HFut6VKwsi+zW6DwH /KREDXEYR7AdJflQCA5bjBfEzlhmJQxnFUyz+w+oRRIW29Ie1vz3OJuoJj9eZMFiJhyr J++g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version; bh=nefU5sI7KhDn/kKRuPyuDgjXIjI04zSiNdqB36IbtYQ=; b=TrKYZWfAi5g5bGpbvNyJzXB9aqGvBPE3hWdnH5aDweY2jHk0giehBNoQ/0jKIq7woU FxjLeG/nVW18fG/hoCimINOnI6GLg217JS5HB/4ZWxsGPeL87ihLzgNuF8wBoCFvEyXQ 52Sfmu9kX78UdoLDPgf1dYa7nGR+Z0yib+ajimIOZPxZEtnaqllmWfizNd/cYNOa7uyg qfK+enT3+ujWJ8f8rkooIaiWzUUjICF/cGIVyTvYSknDiHEVs7aRfNuFcUzalz+DFxig wfpHbMUuhB91cUvGHsRTx+xRT0iw1PxbQzeGEoy5Tz50ubZ+lB5bhk/xPOsdUIIBKXgU wNcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dn18si2207528ejc.590.2021.03.31.11.00.22; Wed, 31 Mar 2021 11:00:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234473AbhCaR7Z (ORCPT + 99 others); Wed, 31 Mar 2021 13:59:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233867AbhCaR7M (ORCPT ); Wed, 31 Mar 2021 13:59:12 -0400 Received: from hs01.dk-develop.de (hs01.dk-develop.de [IPv6:2a02:c207:3002:6234::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42C4FC061574; Wed, 31 Mar 2021 10:59:11 -0700 (PDT) Received: from mail.dk-develop.de (hs01.dk-develop.de [IPv6:::1]) by hs01.dk-develop.de (Postfix) with ESMTP id 7360A1DA396; Wed, 31 Mar 2021 19:58:33 +0200 (CEST) MIME-Version: 1.0 Date: Wed, 31 Mar 2021 19:58:33 +0200 From: danilokrummrich@dk-develop.de To: Andrew Lunn Cc: linux@armlinux.org.uk, davem@davemloft.net, hkallweit1@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jeremy.linton@arm.com Subject: Re: [PATCH 2/2] net: mdio: support c45 peripherals on c22 busses In-Reply-To: References: <20210331141755.126178-1-danilokrummrich@dk-develop.de> <20210331141755.126178-3-danilokrummrich@dk-develop.de> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <6f1dfc28368d098ace9564e53ed92041@dk-develop.de> X-Sender: danilokrummrich@dk-develop.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, On 2021-03-31 18:27, Andrew Lunn wrote: >> @@ -670,19 +670,21 @@ struct phy_device *mdiobus_scan(struct mii_bus >> *bus, int addr) >> struct phy_device *phydev = ERR_PTR(-ENODEV); >> int err; >> >> + /* In case of NO_CAP and C22 only, we still can try to scan for C45 >> + * devices, since indirect access will be used for busses that are >> not >> + * capable of C45 frame format. >> + */ >> switch (bus->capabilities) { >> case MDIOBUS_NO_CAP: >> case MDIOBUS_C22: >> - phydev = get_phy_device(bus, addr, false); >> - break; >> - case MDIOBUS_C45: >> - phydev = get_phy_device(bus, addr, true); >> - break; >> case MDIOBUS_C22_C45: >> phydev = get_phy_device(bus, addr, false); >> if (IS_ERR(phydev)) >> phydev = get_phy_device(bus, addr, true); >> break; >> + case MDIOBUS_C45: >> + phydev = get_phy_device(bus, addr, true); >> + break; >> } > > I think this is going to cause problems. Please note that this patch does not change already existing behaviour, it does only extend it with the option to drive C45 peripherals from a bus not being capable of C45 framing. For this cited change the only thing happening is that if get_phy_device() already failed for probing with is_c45==false (C22 devices) it tries to probe with is_c45==true (C45 devices) which then either results into actual C45 frame transfers or indirect accesses by calling mdiobus_c45_*() functions. This is a valid approach, since we made sure that even if the MDIO controller does not support C45 framing we can go with indirect accesses. > > commit 0231b1a074c672f8c00da00a57144072890d816b > Author: Kevin Hao > Date: Tue Mar 20 09:44:53 2018 +0800 > > net: phy: realtek: Use the dummy stubs for MMD register access for > rtl8211b > > The Ethernet on mpc8315erdb is broken since commit b6b5e8a69118 > ("gianfar: Disable EEE autoneg by default"). The reason is that > even though the rtl8211b doesn't support the MMD extended registers > access, it does return some random values if we trying to access > the MMD register via indirect method. This makes it seem that the > EEE is supported by this phy device. And the subsequent writing to > the MMD registers does cause the phy malfunction. So use the dummy > stubs for the MMD register access to fix this issue. This is something different, here the issue is that an indirect access does not work with a PHY being registered with is_c45==false. This is not related to this change. > > Indirect access to C45 via C22 is not a guaranteed part of C22. So > there are C22 only PHYs which return random junk when you try to use > this access method. For C22 only PHYs nothing will change. If there is not an indirect access to a C22 PHY already, then there will not be one by applying this patch either. > > I'm also a bit confused why this is actually needed. PHY drivers which > make use of C45 use the functions phy_read_mmd(), phy_write_mmd(). I'm looking on it from the perspective of the MDIO controller. If the controller is not capable of C45 framing this doesn't help. From only the PHY's capability point of view this is fine, indeed. > > int __phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum) > { > int val; > > if (regnum > (u16)~0 || devad > 32) > return -EINVAL; > > if (phydev->drv && phydev->drv->read_mmd) { > val = phydev->drv->read_mmd(phydev, devad, regnum); > } else if (phydev->is_c45) { > val = __mdiobus_c45_read(phydev->mdio.bus, phydev->mdio.addr, > devad, regnum); > } else { > struct mii_bus *bus = phydev->mdio.bus; > int phy_addr = phydev->mdio.addr; > > mmd_phy_indirect(bus, phy_addr, devad, regnum); > > /* Read the content of the MMD's selected register */ > val = __mdiobus_read(bus, phy_addr, MII_MMD_DATA); > } > return val; > } > > So if the device is a c45 device, C45 transfers are used, otherwise it That's the issue I'm addressing, if the device is a C45 device and the MDIO controller is not capable of C45 framing, currently, the device won't be probed as a C45 device, because mdiobus_c45_read() will fail. Instead with this patch mdiobus_c45_read() can check the bus's capabilities and perform indirect accesses in case the MDIO controller is not capable of C45 framing, and therefore be able to probe C45 PHYs from a MDIO controller not being capable of C45 framing. > falls back to mmd_phy_indirect(), which is C45 over C22. Only if is_c45==false, that's not what I'm addressing. I'm addressing the case that is_c45==true, but the MDIO controller does not support C45 framing. > > Why does this not work for you? As explained inline above. > > Andrew Kind regards, Danilo