Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp2608000rwb; Sun, 15 Jan 2023 18:59:53 -0800 (PST) X-Google-Smtp-Source: AMrXdXvbeqNchXy8w54z5W4EPE+VCqwbb5aXPCuSNQgzIr2Dd36uvfONavTUgB9rv2oXxYseKyik X-Received: by 2002:a05:6a00:2281:b0:581:a8dc:8f95 with SMTP id f1-20020a056a00228100b00581a8dc8f95mr79175675pfe.12.1673837993142; Sun, 15 Jan 2023 18:59:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673837993; cv=none; d=google.com; s=arc-20160816; b=ZQ+1rowrGAqAQeTQKqkPLugmmL8IfS9ddYPnuaUvbNEC2KCG6oPnke1gm5YhuFkFO+ 7AEA2Rxen8vaqK1ACPPodZ4pT4m/HBTGUTjfsCCDD+O0/Mycx7qc2ZOWdIYmPDMGv7nC /EStR8AyHJQrk1wQ8jsZVamGiutiBNzC6bcts9929tBhElLJ+BBu4TsVQzR4ifHMupBv FY+7K9yB3zAD83/JU4cDcILNmc8w9e9PF5SwmT+47q9KYGfkzCs5ZuIlRrIejPpm9rft w8GiGziTdAHfjyEuNQWiJxONPCg1yd45lvlZyiKomlea5YFyukCa5nVSSBQGBcKnjzjO wTDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=hCZxbNgzCUm7L6wl89cgCzaIwaOm944bt7U2/u6+A/s=; b=GJ4jS+qp3ZYTbGv/M50e2qwJnHAXiwYYoj8e4ajZcO2pKZfei9utRaDElE/8lwH8an U6lPN61IeaWnZM5SA+gi17poEhac495mcHapkP2sXpYz3+adVmeT1NLvyxjMV86vOBSW y9ZPFix1xRiLgBj1K7YVKi8hycyuxiAbcGQEpji/TVeFnQaTZKzl46oF+/plahXWvCl5 thNXz7k9EJPtSRr5ZC18UXnDrjuj1/iZieZzdL4jF+ujSURnh8SOE87UYKv//M93mCnC bTai4IOxOQ6zNNQCVYoj2Tu1NboddKj5E/NUfIryGmP4ck1W7wdz2sCyByALh8RL20XM 8B1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@metafoo.de header.s=default2002 header.b=F5Lxokx1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=metafoo.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y18-20020aa78f32000000b00587efd87345si23126503pfr.330.2023.01.15.18.59.46; Sun, 15 Jan 2023 18:59:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@metafoo.de header.s=default2002 header.b=F5Lxokx1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=metafoo.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231771AbjAPCmC (ORCPT + 54 others); Sun, 15 Jan 2023 21:42:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231672AbjAPCl7 (ORCPT ); Sun, 15 Jan 2023 21:41:59 -0500 Received: from www381.your-server.de (www381.your-server.de [78.46.137.84]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86ADE6E89; Sun, 15 Jan 2023 18:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metafoo.de; s=default2002; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=hCZxbNgzCUm7L6wl89cgCzaIwaOm944bt7U2/u6+A/s=; b=F5Lxokx1vKgOV3tLL77tJ2k8tj wvbKScP+A/iaNLF3TRDUQzWg79Fna6QajqMSbuPzF5lzZ1LVR70KTSllRtgjiS37NU7VfL05sZbyU WxF1D1psqtNFu4X9kKsLi7dS+iNBFO2c4w49VKm+G1FNtI/a7MqlNrBrvnslLbXADcKTcSM3dTLs/ gFCQrDppmL+DuMqHQqu4wuIyW9czCB6vGuWbG5wxnJKuvJ9ftbliXOyGj5w5TX5x9WnfxP0BxJ+UQ oi+rFo6S8fTrTx/u3K1vBPil8APTxM8NdUPNoF9DhkuOLCqrsWiIA3IDh9jwRglY4Ey1PEIOKfScg 32uyrz2w==; Received: from sslproxy05.your-server.de ([78.46.172.2]) by www381.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pHF84-000OdC-Qc; Mon, 16 Jan 2023 03:21:44 +0100 Received: from [2604:5500:c0e5:eb00:da5e:d3ff:feff:933b] by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHF84-000HTx-72; Mon, 16 Jan 2023 03:21:44 +0100 Message-ID: Date: Sun, 15 Jan 2023 18:21:40 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal Content-Language: en-US To: Andrew Lunn Cc: Pierluigi Passaro , hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, eran.m@variscite.com, nate.d@variscite.com, francesco.f@variscite.com, pierluigi.p@variscite.com References: <20230115161006.16431-1-pierluigi.p@variscite.com> From: Lars-Peter Clausen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.103.7/26782/Sun Jan 15 09:20:34 2023) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/15/23 15:55, Andrew Lunn wrote: >> Specifying the ID as part of the compatible string works for clause 22 PHYs, >> but for clause 45 PHYs it does not work. The code always wants to read the >> ID from the PHY itself. But I do not understand things well enough to tell >> whether that's a fundamental restriction of C45 or just our implementation >> and the implementation can be changed to fix it. >> >> Do you have some thoughts on this? > Do you have more details about what goes wrong? Which PHY driver is > it? What compatibles do you put into DT for the PHY? > > To some extent, the ID is only used to find the driver. A C45 device > has a lot of ID register, and all of them are used by phy_bus_match() > to see if a driver matches. So you need to be careful which ID you > pick, it needs to match the driver. > > It is the driver which decides to use C22 or C45 to talk to the PHY. > However, we do have: > > static int phy_probe(struct device *dev) > { > ... > else if (phydev->is_c45) > err = genphy_c45_pma_read_abilities(phydev); > else > err = genphy_read_abilities(phydev); > > so it could be a C45 PHY probed using an ID does not have > phydev->is_c45 set, and so it looks in the wrong place for the > capabilities. Make sure you also have the compatible > "ethernet-phy-ieee802.3-c45" which i think should cause is_c45 to be > set. > > There is no fundamental restriction that i know of here, it probably > just needs somebody to debug it and find where it goes wrong. > > Ah! > > int fwnode_mdiobus_register_phy(struct mii_bus *bus, > struct fwnode_handle *child, u32 addr) > { > ... > rc = fwnode_property_match_string(child, "compatible", > "ethernet-phy-ieee802.3-c45"); > if (rc >= 0) > is_c45 = true; > > if (is_c45 || fwnode_get_phy_id(child, &phy_id)) > phy = get_phy_device(bus, addr, is_c45); > else > phy = phy_device_create(bus, addr, phy_id, 0, NULL); > > > So compatible "ethernet-phy-ieee802.3-c45" results in is_c45 being set > true. The if (is_c45 || is then true, so it does not need to call > fwnode_get_phy_id(child, &phy_id) so ignores whatever ID is in DT and > asks the PHY. > > Try this, totally untested: > > diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c > index b782c35c4ac1..13be23f8ac97 100644 > --- a/drivers/net/mdio/fwnode_mdio.c > +++ b/drivers/net/mdio/fwnode_mdio.c > @@ -134,10 +134,10 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus, > if (rc >= 0) > is_c45 = true; > > - if (is_c45 || fwnode_get_phy_id(child, &phy_id)) > + if (fwnode_get_phy_id (child, &phy_id)) > phy = get_phy_device(bus, addr, is_c45); > else > - phy = phy_device_create(bus, addr, phy_id, 0, NULL); > + phy = phy_device_create(bus, addr, phy_id, is_c45, NULL); > if (IS_ERR(phy)) { > rc = PTR_ERR(phy); > goto clean_mii_ts; > I think part of the problem is that for C45 there are a few other fields that get populated by the ID detection, such as devices_in_package and mmds_present. Is this something we can do after running the PHY drivers probe function? Or is it too late at that point?