Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/11/2016 02:51 PM, Florian Fainelli wrote:
> On 11/03/16 10:31, Murali Karicheri wrote:
>> On 03/10/2016 02:38 PM, Murali Karicheri wrote:
>>> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
On 10/03/16 08:48, Murali Karicheri wrote:
> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
>> On 03/03/16 14:18, Murali Karicheri wrote:
>>> Hi,
>>>
>>> We are using Micrel Phy in one of our board and wondering if we can
>>> force the
>>> Phy to disable flow control at start. I have a 1G ethernet switch
>>> connected
>>> to Phy and the phy always enable flow control. I would like to
>>> configure the
>>> phy not to flow control. Is that possible and if yes, what should I do
>>> in the
>>> my Ethernet driver to tell the Phy not to enable flow control?
>>
>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
>> the switch is doing, along with the link partner advertising support for
>> it. You would want to make sure that your PHY device interface (provided
>> that you are using the PHY library) is not starting with Pause
>> advertised, but it could be supported.
>
> Understood that Phy is just advertise FC. The Micrel phy for 9031
> advertise
> by default FC supported. After negotiation, I see that Phylib provide the
> link status with parameter pause = 1, asym_pause = 1. How do I tell the
> Phy not
> to advertise?
>
> I call following sequence in the Ethernet driver.
>
> of_phy_connect(x,y,hndlr,a,z);
Here you should be able to change phydev->advertising and
phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
bits and have phy_start() restart with that which should disable pause
and asym_pause as seen by your adjust_link handler.
>>> Ok. Good point. I will try this. Thanks for your suggestion.
>>>
>> I had to make following changes to the phy_device.c to allow the phy device
>> report maximum common flow control capability to Ethernet driver through
>> handler. My driver code looks like this.
>>
>> slave->phy = of_phy_connect(gbe_intf->ndev,
>> slave->phy_node,
>> hndlr, 0,
>> phy_mode);
>> if (!slave->phy) {
>> dev_err(priv->dev, "phy not found on slave %d\n",
>> slave->slave_num);
>> return -ENODEV;
>> }
>> dev_dbg(priv->dev, "phy found: id is: 0x%s\n",
>> dev_name(>phy->dev));
>>
>> slave->phy->supported &=
>> ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
>> slave->phy->advertising = slave->phy->supported;
>> phy_start(slave->phy);
>> phy_read_status(slave->phy);
>>
>> And then in the phy_device.c, I did to get flow control off reported in
>> handler for link status update.
>
>
>
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index d551df6..55412ad 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1021,8 +1021,8 @@ int genphy_read_status(struct phy_device *phydev)
>> phydev->duplex = DUPLEX_FULL;
>>
>> if (phydev->duplex == DUPLEX_FULL) {
>> - phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
>> - phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
>> + phydev->pause = adv & lpa & LPA_PAUSE_CAP ? 1 : 0;
>> + phydev->asym_pause = adv & lpa & LPA_PAUSE_ASYM ? 1
>> : 0;
>
> What it means before your patch is that flow control is reported to the
> PHY device if the link partner advertises that, with your patch applied,
> it is reported only if the link partner and yourself advertise flow control.
>
> You seem to be willing to have phydev->pause and phydev->asym_pause
> reflect the resolved pause capability, as opposed to the link partner's
> pause capability, which I am not convinced is correct here, because we
> need to take into account the user-configured pause configuration as
> well. Your adjust_link function should be the one deciding whether pause
> frame advertising and enabling is appropriate based on: locally
> configured pause settings (enabled, disabled, autoneg) and the link
> partner's pause capability.
>
> I do agree that the two fields are confusing and poorly documented, and
> we should probably be consolidating the pause frame behavior in PHYLIB
> as opposed to letting drivers deal with like e.g: gianfar, bcm63xx_enet,
> tg3 etc.
>
>>
>> Could you explain, why the common maximum capability is not reported to the
>> driver as per standard?? Or Am I understood it wrong?
>
> I do not understand the
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On March 16, 2016 8:08:14 AM PDT, Murali Karicheri >> What it means before your patch is that flow control is reported to >the >> PHY device if the link partner advertises that, with your patch >applied, >> it is reported only if the link partner and yourself advertise flow >control. >> >> You seem to be willing to have phydev->pause and phydev->asym_pause >> reflect the resolved pause capability, as opposed to the link >partner's >> pause capability, which I am not convinced is correct here, because >we >> need to take into account the user-configured pause configuration as >> well. Your adjust_link function should be the one deciding whether >pause >> frame advertising and enabling is appropriate based on: locally >> configured pause settings (enabled, disabled, autoneg) and the link >> partner's pause capability. >> >> I do agree that the two fields are confusing and poorly documented, >and >> we should probably be consolidating the pause frame behavior in >PHYLIB >> as opposed to letting drivers deal with like e.g: gianfar, >bcm63xx_enet, >> tg3 etc. >> >>> >>> Could you explain, why the common maximum capability is not reported >to the >>> driver as per standard?? Or Am I understood it wrong? >> >> I do not understand the question, what is "maximum capability" in >that >> context and what standard are you refering to? >> >I assume the Phylib is responsible for deciding what is the flow >control pause and asym pause status to the driver through adjust_link. Not exclusively, the Ethernet MAC driver is responsible for getting the full picture: whether pause frames need to be advertised, enabled locally and supported by the link partner. PHYLIB helps with the later since the former may come from ethtool:: get_pauseparam and need to program MAC specific registers within the adjust_link callback. >When driver starts the phy, it also tells its capabilities (for example >it can reset some of the capabilities available in the Phy driver. In >this >particular case, Pause is a feature supported by Micrel phy. I have >reset >this feature in my driver by resetting this feature bit in the >phy_device >as suggested earlier in this discussion). So phylib has all knowledge >available to disable flow control in this scenario even if LP is >capable >of flow control. Wondering why every driver has to take this decision >again to enable or disable flow control instead of telling the driver >what to do. PHYLIB still misses the MAC driver decisions like whether pause frames are to be enabled by default through autoneg or manually enforced via an user, which is why it reports what the link partner's pause capability so as to get your driver to be able to make the right decisions here. > >Looks like Marvel driver (reproduced below) does this logic. I think >the >802.3x flow control states, but I don't have access to the standard >documentation. >However I find the documentation at >http://www.studioreti.it/slide/08_SwFlowContr_E_A.pdf. > >Page 17 states the behavior based on Local device & Link partner's >capabilities. Probably adjust_link() should tell the outcome in pause >and asym_pause so that driver can enable/disable fc. Also user's action >to be taken into account as well so that fc can be disabled if desired. > >Code from drivers/net/phy/marvel.c Well, thanks for poing that piece of code, that seems to be duplicating a bit of what genphy_read_status() is already doing. -- Florian
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/16/2016 11:08 AM, Murali Karicheri wrote:
> On 03/11/2016 02:51 PM, Florian Fainelli wrote:
>> On 11/03/16 10:31, Murali Karicheri wrote:
>>> On 03/10/2016 02:38 PM, Murali Karicheri wrote:
On 03/10/2016 01:05 PM, Florian Fainelli wrote:
> On 10/03/16 08:48, Murali Karicheri wrote:
>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
>>> On 03/03/16 14:18, Murali Karicheri wrote:
Hi,
We are using Micrel Phy in one of our board and wondering if we can
force the
Phy to disable flow control at start. I have a 1G ethernet switch
connected
to Phy and the phy always enable flow control. I would like to
configure the
phy not to flow control. Is that possible and if yes, what should I do
in the
my Ethernet driver to tell the Phy not to enable flow control?
>>>
>>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
>>> the switch is doing, along with the link partner advertising support for
>>> it. You would want to make sure that your PHY device interface (provided
>>> that you are using the PHY library) is not starting with Pause
>>> advertised, but it could be supported.
>>
>> Understood that Phy is just advertise FC. The Micrel phy for 9031
>> advertise
>> by default FC supported. After negotiation, I see that Phylib provide
>> the
>> link status with parameter pause = 1, asym_pause = 1. How do I tell the
>> Phy not
>> to advertise?
>>
>> I call following sequence in the Ethernet driver.
>>
>> of_phy_connect(x,y,hndlr,a,z);
>
> Here you should be able to change phydev->advertising and
> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
> bits and have phy_start() restart with that which should disable pause
> and asym_pause as seen by your adjust_link handler.
>
Ok. Good point. I will try this. Thanks for your suggestion.
>>> I had to make following changes to the phy_device.c to allow the phy device
>>> report maximum common flow control capability to Ethernet driver through
>>> handler. My driver code looks like this.
>>>
>>> slave->phy = of_phy_connect(gbe_intf->ndev,
>>> slave->phy_node,
>>> hndlr, 0,
>>> phy_mode);
>>> if (!slave->phy) {
>>> dev_err(priv->dev, "phy not found on slave %d\n",
>>> slave->slave_num);
>>> return -ENODEV;
>>> }
>>> dev_dbg(priv->dev, "phy found: id is: 0x%s\n",
>>> dev_name(>phy->dev));
>>>
>>> slave->phy->supported &=
>>> ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
>>> slave->phy->advertising = slave->phy->supported;
>>> phy_start(slave->phy);
>>> phy_read_status(slave->phy);
>>>
>>> And then in the phy_device.c, I did to get flow control off reported in
>>> handler for link status update.
>>
>>
>>
>>>
>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>> index d551df6..55412ad 100644
>>> --- a/drivers/net/phy/phy_device.c
>>> +++ b/drivers/net/phy/phy_device.c
>>> @@ -1021,8 +1021,8 @@ int genphy_read_status(struct phy_device *phydev)
>>> phydev->duplex = DUPLEX_FULL;
>>>
>>> if (phydev->duplex == DUPLEX_FULL) {
>>> - phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
>>> - phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
>>> + phydev->pause = adv & lpa & LPA_PAUSE_CAP ? 1 : 0;
>>> + phydev->asym_pause = adv & lpa & LPA_PAUSE_ASYM ? 1
>>> : 0;
>>
>> What it means before your patch is that flow control is reported to the
>> PHY device if the link partner advertises that, with your patch applied,
>> it is reported only if the link partner and yourself advertise flow control.
>>
>> You seem to be willing to have phydev->pause and phydev->asym_pause
>> reflect the resolved pause capability, as opposed to the link partner's
>> pause capability, which I am not convinced is correct here, because we
>> need to take into account the user-configured pause configuration as
>> well. Your adjust_link function should be the one deciding whether pause
>> frame advertising and enabling is appropriate based on: locally
>> configured pause settings (enabled, disabled, autoneg) and the link
>> partner's pause capability.
>>
>> I do agree that the two fields are confusing and poorly documented, and
>> we should probably be consolidating the pause frame behavior in PHYLIB
>> as opposed to letting drivers deal with like e.g: gianfar, bcm63xx_enet,
>> tg3 etc.
>>
>>>
>>> Could you
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 11/03/16 10:31, Murali Karicheri wrote:
> On 03/10/2016 02:38 PM, Murali Karicheri wrote:
>> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>>> On 10/03/16 08:48, Murali Karicheri wrote:
On 03/03/2016 07:16 PM, Florian Fainelli wrote:
> On 03/03/16 14:18, Murali Karicheri wrote:
>> Hi,
>>
>> We are using Micrel Phy in one of our board and wondering if we can
>> force the
>> Phy to disable flow control at start. I have a 1G ethernet switch
>> connected
>> to Phy and the phy always enable flow control. I would like to configure
>> the
>> phy not to flow control. Is that possible and if yes, what should I do
>> in the
>> my Ethernet driver to tell the Phy not to enable flow control?
>
> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
> the switch is doing, along with the link partner advertising support for
> it. You would want to make sure that your PHY device interface (provided
> that you are using the PHY library) is not starting with Pause
> advertised, but it could be supported.
Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
by default FC supported. After negotiation, I see that Phylib provide the
link status with parameter pause = 1, asym_pause = 1. How do I tell the
Phy not
to advertise?
I call following sequence in the Ethernet driver.
of_phy_connect(x,y,hndlr,a,z);
>>>
>>> Here you should be able to change phydev->advertising and
>>> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
>>> bits and have phy_start() restart with that which should disable pause
>>> and asym_pause as seen by your adjust_link handler.
>>>
>> Ok. Good point. I will try this. Thanks for your suggestion.
>>
> I had to make following changes to the phy_device.c to allow the phy device
> report maximum common flow control capability to Ethernet driver through
> handler. My driver code looks like this.
>
> slave->phy = of_phy_connect(gbe_intf->ndev,
> slave->phy_node,
> hndlr, 0,
> phy_mode);
> if (!slave->phy) {
> dev_err(priv->dev, "phy not found on slave %d\n",
> slave->slave_num);
> return -ENODEV;
> }
> dev_dbg(priv->dev, "phy found: id is: 0x%s\n",
> dev_name(>phy->dev));
>
> slave->phy->supported &=
> ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
> slave->phy->advertising = slave->phy->supported;
> phy_start(slave->phy);
> phy_read_status(slave->phy);
>
> And then in the phy_device.c, I did to get flow control off reported in
> handler for link status update.
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index d551df6..55412ad 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1021,8 +1021,8 @@ int genphy_read_status(struct phy_device *phydev)
> phydev->duplex = DUPLEX_FULL;
>
> if (phydev->duplex == DUPLEX_FULL) {
> - phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
> - phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
> + phydev->pause = adv & lpa & LPA_PAUSE_CAP ? 1 : 0;
> + phydev->asym_pause = adv & lpa & LPA_PAUSE_ASYM ? 1 :
> 0;
What it means before your patch is that flow control is reported to the
PHY device if the link partner advertises that, with your patch applied,
it is reported only if the link partner and yourself advertise flow control.
You seem to be willing to have phydev->pause and phydev->asym_pause
reflect the resolved pause capability, as opposed to the link partner's
pause capability, which I am not convinced is correct here, because we
need to take into account the user-configured pause configuration as
well. Your adjust_link function should be the one deciding whether pause
frame advertising and enabling is appropriate based on: locally
configured pause settings (enabled, disabled, autoneg) and the link
partner's pause capability.
I do agree that the two fields are confusing and poorly documented, and
we should probably be consolidating the pause frame behavior in PHYLIB
as opposed to letting drivers deal with like e.g: gianfar, bcm63xx_enet,
tg3 etc.
>
> Could you explain, why the common maximum capability is not reported to the
> driver as per standard?? Or Am I understood it wrong?
I do not understand the question, what is "maximum capability" in that
context and what standard are you refering to?
--
Florian
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/10/2016 02:38 PM, Murali Karicheri wrote:
> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>> On 10/03/16 08:48, Murali Karicheri wrote:
>>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
On 03/03/16 14:18, Murali Karicheri wrote:
> Hi,
>
> We are using Micrel Phy in one of our board and wondering if we can force
> the
> Phy to disable flow control at start. I have a 1G ethernet switch
> connected
> to Phy and the phy always enable flow control. I would like to configure
> the
> phy not to flow control. Is that possible and if yes, what should I do in
> the
> my Ethernet driver to tell the Phy not to enable flow control?
The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
the switch is doing, along with the link partner advertising support for
it. You would want to make sure that your PHY device interface (provided
that you are using the PHY library) is not starting with Pause
advertised, but it could be supported.
>>>
>>> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
>>> by default FC supported. After negotiation, I see that Phylib provide the
>>> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy
>>> not
>>> to advertise?
>>>
>>> I call following sequence in the Ethernet driver.
>>>
>>> of_phy_connect(x,y,hndlr,a,z);
>>
>> Here you should be able to change phydev->advertising and
>> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
>> bits and have phy_start() restart with that which should disable pause
>> and asym_pause as seen by your adjust_link handler.
>>
> Ok. Good point. I will try this. Thanks for your suggestion.
>
I had to make following changes to the phy_device.c to allow the phy device
report maximum common flow control capability to Ethernet driver through
handler. My driver code looks like this.
slave->phy = of_phy_connect(gbe_intf->ndev,
slave->phy_node,
hndlr, 0,
phy_mode);
if (!slave->phy) {
dev_err(priv->dev, "phy not found on slave %d\n",
slave->slave_num);
return -ENODEV;
}
dev_dbg(priv->dev, "phy found: id is: 0x%s\n",
dev_name(>phy->dev));
slave->phy->supported &=
~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
slave->phy->advertising = slave->phy->supported;
phy_start(slave->phy);
phy_read_status(slave->phy);
And then in the phy_device.c, I did to get flow control off reported in
handler for link status update.
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d551df6..55412ad 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1021,8 +1021,8 @@ int genphy_read_status(struct phy_device *phydev)
phydev->duplex = DUPLEX_FULL;
if (phydev->duplex == DUPLEX_FULL) {
- phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
- phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
+ phydev->pause = adv & lpa & LPA_PAUSE_CAP ? 1 : 0;
+ phydev->asym_pause = adv & lpa & LPA_PAUSE_ASYM ? 1 : 0;
Could you explain, why the common maximum capability is not reported to the
driver as per standard?? Or Am I understood it wrong?
Murali
> Murali
>>> phy_start()
>>>
>>> Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can
>>> I tell the phy not to advertise initially?
>
>
--
Murali Karicheri
Linux Kernel, Keystone
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/10/2016 02:38 PM, Murali Karicheri wrote:
> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>> On 10/03/16 08:48, Murali Karicheri wrote:
>>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
On 03/03/16 14:18, Murali Karicheri wrote:
> Hi,
>
> We are using Micrel Phy in one of our board and wondering if we can force
> the
> Phy to disable flow control at start. I have a 1G ethernet switch
> connected
> to Phy and the phy always enable flow control. I would like to configure
> the
> phy not to flow control. Is that possible and if yes, what should I do in
> the
> my Ethernet driver to tell the Phy not to enable flow control?
The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
the switch is doing, along with the link partner advertising support for
it. You would want to make sure that your PHY device interface (provided
that you are using the PHY library) is not starting with Pause
advertised, but it could be supported.
>>>
>>> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
>>> by default FC supported. After negotiation, I see that Phylib provide the
>>> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy
>>> not
>>> to advertise?
>>>
>>> I call following sequence in the Ethernet driver.
>>>
>>> of_phy_connect(x,y,hndlr,a,z);
>>
>> Here you should be able to change phydev->advertising and
>> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
>> bits and have phy_start() restart with that which should disable pause
>> and asym_pause as seen by your adjust_link handler.
>>
> Ok. Good point. I will try this. Thanks for your suggestion.
>
I made following changes. The phylib still report flow control enabled to
the driver. Some bug in the phylib/phydev?
+
+ printk("slave->phy->supported %x, slave->phy->advertising %x\n",
+ slave->phy->supported, slave->phy->advertising);
+ slave->phy->supported &=
+ ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
+ slave->phy->advertising = slave->phy->supported;
+ printk("slave->phy->supported %x, slave->phy->advertising %x\n",
+ slave->phy->supported, slave->phy->advertising);
phy_start(slave->phy);
+ printk("slave->phy->supported %x, slave->phy->advertising %x\n",
+ slave->phy->supported, slave->phy->advertising);
phy_read_status(slave->phy);
[ 10.757001] slave->phy->supported 22ff, slave->phy->advertising 22ff
[ 10.763354] slave->phy->supported 2ff, slave->phy->advertising 2ff
[ 10.769552] slave->phy->supported 2ff, slave->phy->advertising 2ff
[ 10.776045] netcp-1.0 2620110.netcp eth0: Link is Down
udhcpc (v1.23.1) started
Sending discover...
Sending discover...
[ 14.757280] netcp-1.0 2620110.netcp eth0: Link is Up - 1Gbps/Full - flow
control rx/tx
Sending discover...
Sending select for 158.218.103.170...
Lease of 158.218.103.170 obtained, lease time 28800
/etc/udhcpc.d/50default: Adding DNS 192.0.2.2
/etc/udhcpc.d/50default: Adding DNS 192.0.2.3
> Murali
>>> phy_start()
>>>
>>> Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can
>>> I tell the phy not to advertise initially?
>
>
--
Murali Karicheri
Linux Kernel, Keystone
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/10/2016 01:05 PM, Florian Fainelli wrote: > On 10/03/16 08:48, Murali Karicheri wrote: >> On 03/03/2016 07:16 PM, Florian Fainelli wrote: >>> On 03/03/16 14:18, Murali Karicheri wrote: Hi, We are using Micrel Phy in one of our board and wondering if we can force the Phy to disable flow control at start. I have a 1G ethernet switch connected to Phy and the phy always enable flow control. I would like to configure the phy not to flow control. Is that possible and if yes, what should I do in the my Ethernet driver to tell the Phy not to enable flow control? >>> >>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in >>> the switch is doing, along with the link partner advertising support for >>> it. You would want to make sure that your PHY device interface (provided >>> that you are using the PHY library) is not starting with Pause >>> advertised, but it could be supported. >> >> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise >> by default FC supported. After negotiation, I see that Phylib provide the >> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy >> not >> to advertise? >> >> I call following sequence in the Ethernet driver. >> >> of_phy_connect(x,y,hndlr,a,z); > > Here you should be able to change phydev->advertising and > phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause > bits and have phy_start() restart with that which should disable pause > and asym_pause as seen by your adjust_link handler. > Ok. Good point. I will try this. Thanks for your suggestion. Murali >> phy_start() >> >> Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can >> I tell the phy not to advertise initially? -- Murali Karicheri Linux Kernel, Keystone
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 10/03/16 08:48, Murali Karicheri wrote: > On 03/03/2016 07:16 PM, Florian Fainelli wrote: >> On 03/03/16 14:18, Murali Karicheri wrote: >>> Hi, >>> >>> We are using Micrel Phy in one of our board and wondering if we can force >>> the >>> Phy to disable flow control at start. I have a 1G ethernet switch connected >>> to Phy and the phy always enable flow control. I would like to configure the >>> phy not to flow control. Is that possible and if yes, what should I do in >>> the >>> my Ethernet driver to tell the Phy not to enable flow control? >> >> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in >> the switch is doing, along with the link partner advertising support for >> it. You would want to make sure that your PHY device interface (provided >> that you are using the PHY library) is not starting with Pause >> advertised, but it could be supported. > > Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise > by default FC supported. After negotiation, I see that Phylib provide the > link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy > not > to advertise? > > I call following sequence in the Ethernet driver. > > of_phy_connect(x,y,hndlr,a,z); Here you should be able to change phydev->advertising and phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause bits and have phy_start() restart with that which should disable pause and asym_pause as seen by your adjust_link handler. > phy_start() > > Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can > I tell the phy not to advertise initially? -- Florian
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/03/2016 07:16 PM, Florian Fainelli wrote: > On 03/03/16 14:18, Murali Karicheri wrote: >> Hi, >> >> We are using Micrel Phy in one of our board and wondering if we can force the >> Phy to disable flow control at start. I have a 1G ethernet switch connected >> to Phy and the phy always enable flow control. I would like to configure the >> phy not to flow control. Is that possible and if yes, what should I do in the >> my Ethernet driver to tell the Phy not to enable flow control? > > The PHY is not doing flow control per-se, your pseudo Ethernet MAC in > the switch is doing, along with the link partner advertising support for > it. You would want to make sure that your PHY device interface (provided > that you are using the PHY library) is not starting with Pause > advertised, but it could be supported. Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise by default FC supported. After negotiation, I see that Phylib provide the link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy not to advertise? I call following sequence in the Ethernet driver. of_phy_connect(x,y,hndlr,a,z); phy_start() Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can I tell the phy not to advertise initially? Murali > > As Andrew indicated the proper way to do this is do to use ethtool if > you need to this dynamically. > -- Murali Karicheri Linux Kernel, Keystone
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
Andrew, Thanks for your response! On 03/03/2016 05:26 PM, Andrew Lunn wrote: > On Thu, Mar 03, 2016 at 05:18:38PM -0500, Murali Karicheri wrote: >> Hi, >> >> We are using Micrel Phy in one of our board and wondering if we can force the >> Phy to disable flow control at start. I have a 1G ethernet switch connected >> to Phy and the phy always enable flow control. I would like to configure the >> phy not to flow control. Is that possible and if yes, what should I do in the >> my Ethernet driver to tell the Phy not to enable flow control? > > Hi Murali > > Have you played with: > >ethtool -a|--show-pause devname > >ethtool -A|--pause devname [autoneg on|off] [rx on|off] [tx on|off] > > Andrew > I will try, but my question is for disabling flow control by default in the phy when Ethernet driver is initialized. How does the driver tells the phy to disable tx/rx flow control. Even if phy advertise flow control capability the Ethernet h/w MAC layer should be capable of doing a Pause. So the driver needs to have a way to disable tx/rx FC when it starts. How this can be achieved? We would like to disable this by default. User will be able to enable it through ethtool command if it desire to have FC for a specific use case. Isn't reasonable? -- Murali Karicheri Linux Kernel, Keystone
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On 03/03/16 14:18, Murali Karicheri wrote: > Hi, > > We are using Micrel Phy in one of our board and wondering if we can force the > Phy to disable flow control at start. I have a 1G ethernet switch connected > to Phy and the phy always enable flow control. I would like to configure the > phy not to flow control. Is that possible and if yes, what should I do in the > my Ethernet driver to tell the Phy not to enable flow control? The PHY is not doing flow control per-se, your pseudo Ethernet MAC in the switch is doing, along with the link partner advertising support for it. You would want to make sure that your PHY device interface (provided that you are using the PHY library) is not starting with Pause advertised, but it could be supported. As Andrew indicated the proper way to do this is do to use ethtool if you need to this dynamically. -- Florian
Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
On Thu, Mar 03, 2016 at 05:18:38PM -0500, Murali Karicheri wrote: > Hi, > > We are using Micrel Phy in one of our board and wondering if we can force the > Phy to disable flow control at start. I have a 1G ethernet switch connected > to Phy and the phy always enable flow control. I would like to configure the > phy not to flow control. Is that possible and if yes, what should I do in the > my Ethernet driver to tell the Phy not to enable flow control? Hi Murali Have you played with: ethtool -a|--show-pause devname ethtool -A|--pause devname [autoneg on|off] [rx on|off] [tx on|off] Andrew
Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
Hi, We are using Micrel Phy in one of our board and wondering if we can force the Phy to disable flow control at start. I have a 1G ethernet switch connected to Phy and the phy always enable flow control. I would like to configure the phy not to flow control. Is that possible and if yes, what should I do in the my Ethernet driver to tell the Phy not to enable flow control? -- Murali Karicheri Linux Kernel, Keystone
