[U-Boot] [PATCH] tsec: report when there is no vendor specific PHY support.

Commit af1c2b84 added a generic phy support, with an ID of zero and a 32 bit mask; meaning that it will match on any PHY ID.
The problem is that there is a test that checked if a matching PHY was found, and if not, it printed the non-matching ID. But since there will always be a match (on the generic PHY, worst case), this test will never trip.
In the case of a misconfigured PHY address, or of a PHY that isn't explicitly supported outside of the generic support, you will never see the ID of 0xffffffff, or the ID of the real (but unsupported) chip. It will silently fall through onto the generic support.
This change makes that test useful again, and ensures that the selection of generic PHY support doesn't happen without some sort of notice. It also makes it explicitly clear that the generic PHY must be last in the PHY table.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com --- drivers/net/tsec.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index fbc9a6d..462987d 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -1589,7 +1589,7 @@ struct phy_info *phy_info[] = { &phy_info_VSC8601, &phy_info_dp83865, &phy_info_rtl8211b, - &phy_info_generic, + &phy_info_generic, /* must be last; has ID 0 and 32 bit mask */ NULL };
@@ -1621,9 +1621,8 @@ struct phy_info *get_phy_info(struct eth_device *dev) } }
- if (theInfo == NULL) { - printf("%s: PHY id %x is not supported!\n", dev->name, phy_ID); - return NULL; + if (theInfo == &phy_info_generic) { + printf("%s: No support for PHY id %x; assuming generic\n", dev->name, phy_ID); } else { debug("%s: PHY is %s (%x)\n", dev->name, theInfo->name, phy_ID); }

On Dec 11, 2008, at 2:29 PM, Paul Gortmaker wrote:
Commit af1c2b84 added a generic phy support, with an ID of zero and a 32 bit mask; meaning that it will match on any PHY ID.
The problem is that there is a test that checked if a matching PHY was found, and if not, it printed the non-matching ID. But since there will always be a match (on the generic PHY, worst case), this test will never trip.
In the case of a misconfigured PHY address, or of a PHY that isn't explicitly supported outside of the generic support, you will never see the ID of 0xffffffff, or the ID of the real (but unsupported) chip. It will silently fall through onto the generic support.
This change makes that test useful again, and ensures that the selection of generic PHY support doesn't happen without some sort of notice. It also makes it explicitly clear that the generic PHY must be last in the PHY table.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
Acked-by: Andy Fleming afleming@freescale.com

Dear Ben,
In message 29f2f2fe7e8a340b4bad9db14d2f6d3844cf8964.1228951215.git.paul.gortmaker@windriver.com Paul Gortmaker wrote:
Commit af1c2b84 added a generic phy support, with an ID of zero and a 32 bit mask; meaning that it will match on any PHY ID.
The problem is that there is a test that checked if a matching PHY was found, and if not, it printed the non-matching ID. But since there will always be a match (on the generic PHY, worst case), this test will never trip.
In the case of a misconfigured PHY address, or of a PHY that isn't explicitly supported outside of the generic support, you will never see the ID of 0xffffffff, or the ID of the real (but unsupported) chip. It will silently fall through onto the generic support.
This change makes that test useful again, and ensures that the selection of generic PHY support doesn't happen without some sort of notice. It also makes it explicitly clear that the generic PHY must be last in the PHY table.
Signed-off-by: Paul Gortmaker paul.gortmaker@windriver.com
drivers/net/tsec.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
This patch was ACKed by Andy, but I don't think it was applied.
Was this intentional or by accident?
Best regards,
Wolfgang Denk
participants (3)
-
Andy Fleming
-
Paul Gortmaker
-
Wolfgang Denk