Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
From: Richard Cochran Date: Tue, 25 Sep 2012 09:47:36 +0200 > On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote: >> >> A2 chip has phy_id 0x00137a10 >> A3 chip has phy_id 0x00137a11 > > Okay then, thanks. > > Acked-by: Richard Cochran Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
From: Richard Cochran richardcoch...@gmail.com Date: Tue, 25 Sep 2012 09:47:36 +0200 On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote: A2 chip has phy_id 0x00137a10 A3 chip has phy_id 0x00137a11 Okay then, thanks. Acked-by: Richard Cochran richardcoch...@gmail.com Applied to net-next, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote: > > A2 chip has phy_id 0x00137a10 > A3 chip has phy_id 0x00137a11 Okay then, thanks. Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
Le 24/09/2012 20:30, Richard Cochran a écrit :
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
+++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
@@ -175,6 +292,16 @@
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = 0x00137a10,
+ .name = "LXT973-A2",
+ .phy_id_mask= 0x,
+ .features = PHY_BASIC_FEATURES,
+ .flags = 0,
+ .probe = lxt973_probe,
+ .config_aneg= lxt973_config_aneg,
+ .read_status= lxt973a2_read_status,
I like this way of matching the A2 chips much better than what you had
before. But are you sure this will work correctly?
Apparently it does.
What do A3 chips have in the last nibble of phy_id?
A2 chip has phy_id 0x00137a10
A3 chip has phy_id 0x00137a11
Christophe
+ .driver = { .owner = THIS_MODULE,},
+}, {
+ .phy_id = 0x00137a10,
.name = "LXT973",
.phy_id_mask= 0xfff0,
.features = PHY_BASIC_FEATURES,
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
Le 24/09/2012 20:30, Richard Cochran a écrit :
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
+++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
@@ -175,6 +292,16 @@
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = 0x00137a10,
+ .name = LXT973-A2,
+ .phy_id_mask= 0x,
+ .features = PHY_BASIC_FEATURES,
+ .flags = 0,
+ .probe = lxt973_probe,
+ .config_aneg= lxt973_config_aneg,
+ .read_status= lxt973a2_read_status,
I like this way of matching the A2 chips much better than what you had
before. But are you sure this will work correctly?
Apparently it does.
What do A3 chips have in the last nibble of phy_id?
A2 chip has phy_id 0x00137a10
A3 chip has phy_id 0x00137a11
Christophe
+ .driver = { .owner = THIS_MODULE,},
+}, {
+ .phy_id = 0x00137a10,
.name = LXT973,
.phy_id_mask= 0xfff0,
.features = PHY_BASIC_FEATURES,
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote: A2 chip has phy_id 0x00137a10 A3 chip has phy_id 0x00137a11 Okay then, thanks. Acked-by: Richard Cochran richardcoch...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
> diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
> --- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
> +++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
> @@ -175,6 +292,16 @@
> .driver = { .owner = THIS_MODULE,},
> }, {
> .phy_id = 0x00137a10,
> + .name = "LXT973-A2",
> + .phy_id_mask= 0x,
> + .features = PHY_BASIC_FEATURES,
> + .flags = 0,
> + .probe = lxt973_probe,
> + .config_aneg= lxt973_config_aneg,
> + .read_status= lxt973a2_read_status,
I like this way of matching the A2 chips much better than what you had
before. But are you sure this will work correctly?
What do A3 chips have in the last nibble of phy_id?
> + .driver = { .owner = THIS_MODULE,},
> +}, {
> + .phy_id = 0x00137a10,
> .name = "LXT973",
> .phy_id_mask= 0xfff0,
> .features = PHY_BASIC_FEATURES,
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
Le 24/09/2012 16:13, David Laight a écrit : This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding precautions linked to ERRATA Item 4: Revision A2 of LXT973 chip randomly returns the contents of the previous even register when you read a odd register regularly Does reading the PHY registers involve bit-banging an MII interface? If so this code is likely to stall the system for significant periods (ready phy registers at all can be a problem). I know some ethernet mac have hardware blocks for reading MII and even polling one MII register for changes. Maybe some of this code ought to be using async software bit-bang - especially when just polling for link status change. I'm sure it ought to be possible to do one bit-bang action per clock tick instead of spinning for the required delays. David Not sure I understand what you mean. We have been using this code without any problem for about 2 years on our Hardware. It does almost same as genphy_read_status() except that it also reads the BMCR register (which is the register preceeding the BMSR) in order to detect the unlikely happening of the bug reported by the ERRATA. In case it happens (which is really seldom), it does a re-read. We are not spinning on any delays here. Christophe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding > precautions linked to ERRATA Item 4: > > Revision A2 of LXT973 chip randomly returns the contents of the previous even > register when you read a odd register regularly Does reading the PHY registers involve bit-banging an MII interface? If so this code is likely to stall the system for significant periods (ready phy registers at all can be a problem). I know some ethernet mac have hardware blocks for reading MII and even polling one MII register for changes. Maybe some of this code ought to be using async software bit-bang - especially when just polling for link status change. I'm sure it ought to be possible to do one bit-bang action per clock tick instead of spinning for the required delays. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding precautions linked to ERRATA Item 4: Revision A2 of LXT973 chip randomly returns the contents of the previous even register when you read a odd register regularly Does reading the PHY registers involve bit-banging an MII interface? If so this code is likely to stall the system for significant periods (ready phy registers at all can be a problem). I know some ethernet mac have hardware blocks for reading MII and even polling one MII register for changes. Maybe some of this code ought to be using async software bit-bang - especially when just polling for link status change. I'm sure it ought to be possible to do one bit-bang action per clock tick instead of spinning for the required delays. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
Le 24/09/2012 16:13, David Laight a écrit : This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding precautions linked to ERRATA Item 4: Revision A2 of LXT973 chip randomly returns the contents of the previous even register when you read a odd register regularly Does reading the PHY registers involve bit-banging an MII interface? If so this code is likely to stall the system for significant periods (ready phy registers at all can be a problem). I know some ethernet mac have hardware blocks for reading MII and even polling one MII register for changes. Maybe some of this code ought to be using async software bit-bang - especially when just polling for link status change. I'm sure it ought to be possible to do one bit-bang action per clock tick instead of spinning for the required delays. David Not sure I understand what you mean. We have been using this code without any problem for about 2 years on our Hardware. It does almost same as genphy_read_status() except that it also reads the BMCR register (which is the register preceeding the BMSR) in order to detect the unlikely happening of the bug reported by the ERRATA. In case it happens (which is really seldom), it does a re-read. We are not spinning on any delays here. Christophe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
+++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
@@ -175,6 +292,16 @@
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = 0x00137a10,
+ .name = LXT973-A2,
+ .phy_id_mask= 0x,
+ .features = PHY_BASIC_FEATURES,
+ .flags = 0,
+ .probe = lxt973_probe,
+ .config_aneg= lxt973_config_aneg,
+ .read_status= lxt973a2_read_status,
I like this way of matching the A2 chips much better than what you had
before. But are you sure this will work correctly?
What do A3 chips have in the last nibble of phy_id?
+ .driver = { .owner = THIS_MODULE,},
+}, {
+ .phy_id = 0x00137a10,
.name = LXT973,
.phy_id_mask= 0xfff0,
.features = PHY_BASIC_FEATURES,
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
