From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Wed, 22 Aug 2012 13:56:06 -0700 Subject: [U-Boot] [PATCH V1 1/3] phy: add phy_connect_by_mask In-Reply-To: References: <1345502918-18305-1-git-send-email-troy.kisky@boundarydevices.com> <5032C349.3090507@boundarydevices.com> <50353CDE.90901@boundarydevices.com> Message-ID: <50354766.7030700@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 08/22/2012 01:50 PM, Andy Fleming wrote: > On Wed, Aug 22, 2012 at 3:11 PM, Eric Nelson > wrote: >> On 08/20/2012 05:35 PM, Andy Fleming wrote: >>> >>> On Monday, August 20, 2012, Troy Kisky wrote: >>> >>> It's best if the driver make the reasonable assumption that its PHY >>> address >>> is known when it comes up, and let the board code, which can be aware that >>> the PHY may exist in varying locations, search for the PHY. >> >> A mask with a single bit set is about as specific as you can get, right? >> >> Are you asking for something more extensible, like a callback into >> board-specific code? > > More like having the board code call into the driver, to tell it: > Here's where to find your PHY. > >> >>> With that approach, the driver won't have to change when some board >>> designer makes the PHY topology even stranger, and I would support >>> a PHYLIB function to do searching much as you've specified. >> >> The primary reason for this change is that it's not only the board >> designer, but also the purchasing manager or manufacturer who can >> change the address. >> >> Since the PHY addresses are often driven by the state of LEDs on >> an ethernet connector, swapping part numbers can result in different >> PHY addresses. We run into this on our Nitrogen6X boards where >> PoE-enabled jacks result in a different PHY address from a standard jack. > > Oh, I understand, fully. My argument is actually that it's even worse > than that. Imagine that there's a scenario where there's a valid PHY > at 4 AND 6, but under certain circumstances, your controller is hooked > up to 6. With the mask solution, the driver will always connect to 4 > (assuming your mask includes 4 and 6). So now, to solve that, you have > to add more logic, but because the knowledge of the PHY is entirely > encoded in the ethernet driver and the board config file, there's no > way to insert logic, except in the driver. > > I think that many people will find the need to search the bus, and a > mask like the one in this patch is a very good way. But the driver > shouldn't do the searching, IMO. > Thanks for the clarification Andy. I didn't understand where you were headed and it's now clear. Regards, Eric