From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C36271D8E01 for ; Sun, 1 Mar 2026 17:24:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772385859; cv=none; b=fIBMlno6mD6ML2h2exq1gfOr7amqHHjTGxhcCN2LBEAraoCrE90TJYfs4B4PpHXCzMmJbJWsSd3Jp8YYnck+mrCIrcsenAj7xOaCr/37ErC5a6xizgVMwEg4MU2nkJh7hTh0E/BgBnsYl0i0kisfzBW/qG93a7bFyORi2lT4CXg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772385859; c=relaxed/simple; bh=OpQNspzThVXFBYLAhmiU3FFkWbIeijCa27H9TPxDfpw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sjnJbwnPkKpv1yglEF+DV5cY9j7R31xCVtwFHg0xFH/Td8LLQhr0Ido2qejw3sqkvEsj1GqE8ffiwlA+HCa+ua8uKplNNB27YtaSCej9R4g4QgSRTsbeV3CCQrhEp85C0bFVOaQ5BuxAD9oU/snBqjK3MVTr90/38ItyJiBVLJA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Yk5fWI+Y; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Yk5fWI+Y" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-48372efa020so29988615e9.2 for ; Sun, 01 Mar 2026 09:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772385856; x=1772990656; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=eMEfvLnIcHCLj6kvqTL40Dsk5YrJgXj7C+hdkrACjMw=; b=Yk5fWI+YKm2Ydr6ArQwUW/+uFZPZ4WwwapJqbqnPnjBFm45YO2RVKW5GJYdwVmQbR4 YHst3tBxNWNUybn7+Qy79pTuoC0ZCMKhfnHoAnJJI9cl+ly7NFPOEpkR4AKuPCGgGuFT W/2ya31wRWAqGqTCt9jPo1ShDfYHu3GahUMgRGGE3krkhT2Z/sTo66wk2ZYhkQIobTBo AC34E9pXmdoIyfIoGUy+gx21T9UOWMG9VxE7B0dyRD92wW6MWseORByIpLkH+azvZ8cl ApUc84LgSqNfTDyT8ECdc6udvl2DyVvEaZXk9AOl4oBImBscE60Vg1MfLZVhdsxZZp03 1pBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772385856; x=1772990656; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eMEfvLnIcHCLj6kvqTL40Dsk5YrJgXj7C+hdkrACjMw=; b=qxjuofC3fXaHKsb9z/ty28YN/JSvnLDv0TqI3K/NDpstPPWFeOS+nNWCuSMIdrg073 EfJQIYyw5G9eE0iWbF2x+IROY6R6Xi4HNA5uyh1oY+OXI65/IB31HZxI924CEQlYeZlP Lc503jkhADuH5FI1JPWFblZBLj+QDd86t18eAge9gLQbO6Zof5HNRewVQmIBODoDif1H LMQ5MgaKp2CIb7DGvqI9H8umqUdudUV3FVgdFP6TI6ZADJVtoZVOMZ+lqpP0OMUXXBzR XXWNaFKPZh9sTHCfF8GFjNIjE3f4GAMijCZ/2DSg1HvHuyx1/gVLJxr+OOP2FHnXR8vT AhRA== X-Gm-Message-State: AOJu0Ywu9OOtcGCh9jmqCBMWpxujnmxAh2U/YLnAwFC+Yw6n8nJULJ0r 7QNjq2mwxnWkhIaTZWt42m0YJWvk19YMGFuT1FHYi1UUVgN/Q+wO8maL X-Gm-Gg: ATEYQzwX/p4r8qREq3DJeJM6hSzh1wQluR2YxDR/5z4hJosi/RQnGUWlAGTiPcHU3Qa /qJluCHE4h+ctrVgs138eAlTZVCS1+Go+6zvqa+NZ9HBl1psHCVzRkUJIe9UqDF7WazwquotYzS Mes/8/gcxCakIeJL6PkPx0NxSxB2UqKYG0K6FSSOtCtlnaw05OsOf3ZvQhuFJgog1bH34GbXDve 17pDionKWhr0RVl2zkLtH+j3+IMJs7oKcR41I05uUKBdp7l7c7+GfygolW4euO9MKKuQVVxBQ5n 7Lbb9z7IjYSZ7M9kQvHiXfypTMqdMsOZWm8c9kpLU2Hn5whHcYUoTUgNUTjy+K9T0/iCfa3Pt3W hnWSLE8vOxewZNZC1MIfgQZdkuzobcuy7WTWaCu/U/nW+XjwzvE0i47RS7xlWOppQswPkGeS3+m SOEs4VTOKIJ5HGKevagIpT6kkGTvGfcHwESTEhBUbm71/Hq4e9tVXixZn3Pa95YcyUhVr1lcNqw NgR X-Received: by 2002:a05:600c:46c4:b0:483:7783:5373 with SMTP id 5b1f17b1804b1-483c9c0f20dmr164527665e9.23.1772385855922; Sun, 01 Mar 2026 09:24:15 -0800 (PST) Received: from [10.0.0.98] (snat-2.cgn.sat-an.net. [176.222.226.2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483bfcbf673sm137894315e9.19.2026.03.01.09.24.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Mar 2026 09:24:15 -0800 (PST) Message-ID: <37e855bc-cac9-48c7-863e-714abe866ae6@gmail.com> Date: Sun, 1 Mar 2026 18:24:13 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v2 1/5] net: mdiobus: Scan buses in reverse order (31 -> 0) To: "Russell King (Oracle)" Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Andrew Lunn , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Frank , Sai Krishna , Daniel Golle References: <20260228232241.1274236-1-linuxtardis@gmail.com> <20260228232241.1274236-2-linuxtardis@gmail.com> Content-Language: en-US From: =?UTF-8?Q?Jakub_Van=C4=9Bk?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/1/26 18:03, Russell King (Oracle) wrote: > On Sun, Mar 01, 2026 at 12:22:37AM +0100, Jakub Vaněk wrote: >> Some PHY devices incorrectly treat address 0 as a broadcast address. >> As a result, accesses to address 0 may cause multiple PHYs to respond, >> making one or both PHYs work unreliably. In other cases, the PHY may be >> detected twice by Linux: once at address 0 and once at its actual >> address). >> >> On several PHYs (e.g. Motorcomm YT8821 and Realtek RTL8221B), this >> behavior can be disabled via a vendor-specific internal register. >> However, for that to be useful, that register would have to be >> programmed before address 0 is accessed for the first time. >> >> On non-Device Tree systems, MDIO buses are typically scanned in >> mdiobus_register(). Change the address scan order from 0->31 to 31->0 >> so that PHY fixups are applied to addresses 1-31 before address 0 >> is probed. This way the address collision can be avoided. > > I've said no to this before. > > The order of scanning may affect the order in which devices are added. > However, that doesn't really have that much bearing in the order in > which devices are bound to their drivers. > > If the drivers are already registered, then as each device is > registered with the driver model, it will be offered to drivers. So > in this case, the order in which devices are proed will be the order > in which they are scanned. > > However, if a driver is loaded after scanning is complete, then the > order in which devices are presented to the driver is not under the > control of phylib, but is down to the driver model code. The driver > model scans the bus_type's devices in some order, and attempts to > match each with the new driver. > > If the driver is not present, then even if you scan in reverse order, > the "ghost" at address 0 will be found, because the driver hasn't had > the opportunity to reprogram the PHY to disable that. > > In both cases, things get worse if -EPROBE_DEFER happens. > > So, you can't definitively control the order in which devices are > probed, which means that anything that depends on that will be fragile. > I have observed something similar -- when the YT8821 driver was built as a module, the .probe callback was indeed not called early enough. This is why I rewrote the patch to use a PHY fixup -- the fixups are called synchronously from phy_device_register() and don't depend on the driver in any way. I thus agree that it is not feasible to handle this inside the YT8821 kernel driver. Jakub