Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp605844ybr; Fri, 22 May 2020 14:33:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0KxxC24BHXSehKLyGagLeYpsFD/dQ5VLdh5Vci/YGe86O73XNnJ7dq6TDvQmcTC0mIiU4 X-Received: by 2002:a50:fc0c:: with SMTP id i12mr4884377edr.174.1590183235898; Fri, 22 May 2020 14:33:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590183235; cv=none; d=google.com; s=arc-20160816; b=gwwG6AFMGg8/Kch9pzv9JUTRYODJw7E3IqcmaT/6doC1rveQhAevSH8fk9Z53Jw7e1 TRDkK/1Rq7ncZNiQpBbs1O5JwUIeRT9/CN57T2DRg/mmPEL08YAGDHZ44CsXjkRlO92Z Lvf71XIgrXer1OhnpA/3hi1kNTU5AlZJiBnauDLPob8g+iWoKDqc7t23cfKrbArEDvqR xcPoPjqV/UVp/EiEnuQxXhNzo2I6VQqvJgILd63Srppt5uYoKaPa9meqApYC0JQoENzy HuwiBQu6bt4s4VgZvdA9vBYyd9UXV2NPdIdu7k+PfYJhwPuJNYwPMsLTpsAFAIjsrp1o BQtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=8eEx2vu4JPddrFMzLXG5o25Qm6QcWnW8ecm8oyEJtqA=; b=a5OP4LQGh/sm6ntdEY5ZNHLU/7P+sr26fPGKeH2iFVTCRJUCpXcsAPtzQWm6B2ekBY AqO1KT5xDzhlBWM/X8v/FT4naoHBSYUyBQcu1sX0LlSNyZddE33UQkINGmZy6gTgRPA2 YjY0zNDjxC0TEqpwCmbOBnc3edCBtBj2CVQzR23d0E4MdAEVQWLxH5vTyPYgu+ILSf8r wzefPdk04QPpJRnpv/d+RHmXgSNbRHUMNnhePbJXn8xvj8LD4s3up6WpNEGUnJGipYbB mmFO0SfhbvmU9L8lNEnkiSZ1Z0JvxIfdkGtCjgX4FFW7vdWZVIVlYYtLSXwRi8e0viHb vWxA== 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 g15si5845341ejh.346.2020.05.22.14.33.33; Fri, 22 May 2020 14:33:55 -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 S1731254AbgEVVbq (ORCPT + 99 others); Fri, 22 May 2020 17:31:46 -0400 Received: from foss.arm.com ([217.140.110.172]:42348 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731162AbgEVVbN (ORCPT ); Fri, 22 May 2020 17:31:13 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 524831063; Fri, 22 May 2020 14:31:13 -0700 (PDT) Received: from mammon-tx2.austin.arm.com (mammon-tx2.austin.arm.com [10.118.28.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4B3183F68F; Fri, 22 May 2020 14:31:13 -0700 (PDT) From: Jeremy Linton To: netdev@vger.kernel.org Cc: davem@davemloft.net, andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com, linux@armlinux.org.uk, madalin.bucur@oss.nxp.com, calvin.johnson@oss.nxp.com, linux-kernel@vger.kernel.org, Jeremy Linton Subject: [RFC 07/11] net: phy: reset invalid phy reads of 0 back to 0xffffffff Date: Fri, 22 May 2020 16:30:55 -0500 Message-Id: <20200522213059.1535892-8-jeremy.linton@arm.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200522213059.1535892-1-jeremy.linton@arm.com> References: <20200522213059.1535892-1-jeremy.linton@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org MMD's in the device list sometimes return 0 for their id. When that happens lets reset the id back to 0xfffffff so that we don't get a stub device created for it. This is a questionable commit, but i'm tossing it out there along with the comment that reading the spec seems to indicate that maybe there are further registers that could be probed in an attempt to resolve some futher "bad" phys. It sort of comes down to do we want unused phy devices floating around (potentially unmatched in dt) or do we want to cut them off early and let DT create them directly. For the ACPI case, we don't really have a good way to match them, and since it hasn't been working I think its perfectly reasonable at this point to expect phy's to implement enough of the standard that we can detect them and attach a phy specific driver. Signed-off-by: Jeremy Linton --- drivers/net/phy/phy_device.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index b2cd22d6315c..acdada865864 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -780,6 +780,10 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id, return ret; if (valid_phy_id(c45_ids->device_ids[i])) valid_id = true; + else + c45_ids->device_ids[i] = 0xffffffff; + + /* consider probing PKGID per 45.2.12.2.1? */ } if (!valid_id && c22_present) -- 2.26.2