From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 857DF3EBF1A for ; Sun, 22 Feb 2026 02:04:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771725887; cv=none; b=EXk/n3wR+tKXoqSzjdQQN/2mnQjD1YAyAkstXk9bbVBbldFnWklr6W37hxxIrMHen8HIUYcqn4SxTYKOU4NWywIdHEx2iC4soqtpMH9mtST96+W4heB/+L1O7X5n0Bcm6pZuy8zFKgrFj2YRtB+9r0V92fZusYVxfix/t3E4A4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771725887; c=relaxed/simple; bh=duhTr+UYCjJ+PiTP/OhBINAZDcKPVyrQDeSGofbEE98=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=PxsMqXnQb5lkhu1KBMNTlxhUN5/Vm3XL2StpWuqPjwD7lA2XtirG84L15g6sol4PcErf2dBNJzBiv9c2i9iQQbrAlC3rvd6DJxz9NAa/AHQTA6dF7jZx9H3p8JoueNISqIsktyPdXkE7NcK2/1cMePBUrjkgHb53jTo1M4YuYm8= 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=dvd8sjn+; arc=none smtp.client-ip=209.85.128.42 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="dvd8sjn+" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4806bf39419so30987215e9.1 for ; Sat, 21 Feb 2026 18:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771725885; x=1772330685; 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=Ytpaqle850lzDXvjY9BO31X2B2LdaqlrsmWEjqqLOeA=; b=dvd8sjn+A9Fm68Ke84idvAwhsOdUxb8QY+uJVFQSeIuwLfTqvbYnpoovVkIVM2XZhm QahHzPzLKoFR428rnkEnBLCLbPE7D/jNaJpiipV/f7S8XbANbKSy6fXVcyjXeugCJmZ2 7SvxoQSZJMLEMeU/ul+VlV9kJiIWY+4IsksnykcrLwT9YF/awWNF7V+W0bQheepVHrPm pGackgBTMUBtWJ4qDrpRJQ2f3d37jQxIFZBNb9+iTI/yvvQ3fGzhAlad4Q1gSlrzW2BA RNTuYg3Iu80GjGOxaMZ5tUllFF9JBU3jkLO1cmUGnvhqFpxsxkvpFsXjWgN7vRs6Em3x cdMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771725885; x=1772330685; 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=Ytpaqle850lzDXvjY9BO31X2B2LdaqlrsmWEjqqLOeA=; b=naN722zETbo9VoIiSDz9eZ8c3t20kN3y08RbIPIH4BCErkvsyZPEkfN+Nkd4S2xEi6 XgNWcCf9Ag6MECEL/doJBp+ynfIp9h+MudAFX6iAtVI+c8p5RxS5SQVAcU4diImuFIio 5018I38+gGOQfTQ7Slg1HqU1MCFyruaFssumT2rak0A/sV7FSIFiXbY1oYezA5fUY5YA 5Ss/VuV+B168Qpi6lRkT6k6eTHOhupjWKMISUil7YJ88/F7yVk+E7XrWuEyFTUyUjHBS 1CrVUlzSd0/znizMYdaFo9uItWXmPBnzFRj+GTylHa2KA+z4Ke4xGBvamjfyKdEtObA1 6GxQ== X-Forwarded-Encrypted: i=1; AJvYcCUKzGdZ6oIbFL1ZJY663ylhuI+B2i+VLpIrBpGqJOzQsZv3mNSHCzr3bj27fZozrPFGSMB55+tjBX/PBwI=@vger.kernel.org X-Gm-Message-State: AOJu0YwmS0qVymeHXG5L0uyFpo6nmwpvNcho7lO3OlGyTypwPQ4H9y81 /YfW6nTK/uAhxjLYN5sJkCQjYO7piDCQS1FpjXFc+K5Rp4Z1Xt8n8S6S X-Gm-Gg: AZuq6aKuj6i+szdwaiqXJP+dMKowdcgJ9UaTYWvjcWDVVxTV6fpKX/qPVjrJWno22e+ 3Y7ft5ayhshdVkeiu+WdfVBciVBfBfcFJ2gt4zE3Nx9FZbys3Wf0QCrr2YmVA8ugPtBnaPcOHE2 1YDZL9WAPjB+iSpRSVd0BHKjfmu4kYpEYaNGWMhLO759jKI2juygc+HCpy9OHgMU8QKkumeSq1V u3+S8+qsPoUHQ1UUAzqXdSZG6LdyEp3pUvLCeZ8kKXvZ/2xJ7wnnxGs48XXt/qYyT8sNqCIJP6B JHYAsAtX+HO2nPtr9fcaEODUCr/dFX7O6MujAkD0oNPLDPrlShAztSMTHQ4/snI7kGb8VCqDpng x0CAU3LWRvS1RvIPTyQbdnNsk3TgZpv24tgizUjOkI8PD+D/jMGljl3Vbo9i+imzt9hgKAzYDZ7 YSRmA9A1bAyxLz/31jOZwuabP3aBP9JwhEAEbbtReHHu5Q8D+0GWxiDUUaDBw9YHzo1dPvi/i40 IWTGSj0HrbCM98= X-Received: by 2002:a05:600c:3b18:b0:483:29f4:26b3 with SMTP id 5b1f17b1804b1-483a94923bamr82501265e9.1.1771725884609; Sat, 21 Feb 2026 18:04:44 -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-483a42ea5ccsm53644165e9.16.2026.02.21.18.04.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Feb 2026 18:04:44 -0800 (PST) Message-ID: <0c1c2c7d-73e9-4412-b68b-4f2e8a396211@gmail.com> Date: Sun, 22 Feb 2026 03:04:42 +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 v1] net: phy: motorcomm: yt8821: disable MDIO broadcast address 0 To: "Russell King (Oracle)" , Andrew Lunn Cc: Frank , Heiner Kallweit , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Sai Krishna , netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: 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: 7bit On 2/22/26 01:18, Russell King (Oracle) wrote: > This is too late (chicken and egg problem exists) - phylib will already > have scanned the bus, and found a PHY at address 0 (whether it read the > IDs correctly because of the conflict is a separate matter. If there's > a conflict between two devices, the PHY IDs read will be a mess.) > > However, if this PHY is the only PHY on the bus, and some driver uses > phy_find_first(), it will find the PHY at address 0, but it won't > respond anymore. > > Failing the probe for address 0 doesn't solve the problem either - there > will still be a struct phy_device created for address 0, and if this > driver doesn't bind to it, the generic PHY driver will be bound manually > by phylib. > > I can't see a simple way to handle this in the kernel. So, I'm going > to say this instead: boot loaders / board firmware need to sort this > mess out and program this PHY not to respond at address 0. > > To put it another way, this isn't a problem to be solved in the kernel. > It's a board design/firmware issue, and that's where it needs to be > solved. > > One of the responsibilities of board firmware is to ensure that the > devices on the board are configured sensibly for the operating system. > What you've said above, where two PHYs conflict on address zero is > a failure to configure the devices on the board sensibly. Hello Andrew, Russell, thank you for the explanations. I now agree that this is better solved in the bootloader rather than in the kernel. The affected Cudy router boots Linux via U-Boot and indeed supports TFTP booting. From what I can tell, the stock Cudy U-Boot avoids the MDIO conflict by only supporting the internal PHY for networking. I checked with a multimeter that the YT8821 is held in hardware reset when U-Boot is running and this likely prevents the YT8821 from responding on MDIO address 0. A while back I did some digging into how the stock Cudy Linux kernel handles this issue. It unfortunately involves hacks such as resetting the YT8821 through its reset pin from userspace and then calling yt8821_config_init() again by opening a debugfs file (ouch). On the positive side, these devices generally support replacing the vendor U-Boot with the OpenWrt U-Boot, which would allow fixing the MDIO addressing early. However, doing so makes reverting to the stock firmware more difficult, this is something I'll have to balance. Thanks again for the guidance and review. Best regards, Jakub