* [ISSUE: mv88e6xxx]: Down/Up link and not forwarding
From: Jose Antonio Delgado Alfonso @ 2016-10-04 15:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <8e5e36d7-7618-2a4e-6aba-e65e41662d47@aoifes.com>
We are working in an ARMv7 embedded system running kernel 4.1 but
including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
should not return a boolean."
This is the schema of the system.
+-------------------+ eth0
| +--+
| | |
| Embedded system +--+
| |
| ARMv7 |
| | Marvell 88E8057(sky2) +-------------+
| +--+ +--+ +--+ eth1
| | +---------------------+ | | +------+
| +--+ CPU port +--+ mv88e6176 +--+
+------+--+---------+ | |
emulated| | | |
GPIO +--+ +--+ +--+ eth2
MDIO +-----------------------------------+ | | +------+
MDIO +--+ +--+
+-------------+
There is a bridge (br-lan) which includes eth0/eth1/eth2
>From time to time, We are seeing a link down and up of about 1s.
Following the message that kernel sends.
[ 312.769399] dsa dsa@0 eth2: Link is Down
[ 312.773372] br-lan: port 3(eth2) entered disabled state
[ 312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
control disabled
[ 312.963807] br-lan: port 3(eth2) entered forwarding state
[ 312.969276] br-lan: port 3(eth2) entered forwarding state
[ 313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
rx/tx
[ 314.966277] br-lan: port 3(eth2) entered forwarding state
Moreover, under a reboot loop test which consists in booting the system,
ping the unit and, if it responds, reboot again, we found that the
bridge does not forward packages after many reboots.
Looking into 88e6176 registers we saw the following
GLOBAL GLOBAL2 0 1 2 3 4 5 6
0: c820 0 de0f 5d0f 500f 500f 500f 4e07 4007
1: 3 0 3e 3 3 3 3 3 3
2: 0 ffff 0 0 0 0 0 0 0
3: 0 ffff 1761 1761 1761 1761 1761 1761 1761
4: 6000 258 373f 433 430 433 433 433 433
5: 1000 c12f 0 0 0 0 0 0 0
6: c000 1f0f 101e 3005 3003 4001 5001 6001 7001
7: 0 707f 0 0 0 0 0 0 0
8: 0 7800 2480 2480 2480 2480 2480 2480 2480
9: 0 1600 1 1 1 1 1 1 1
a: 148 0 0 0 0 0 0 0 0
b: 6000 1000 1 2 4 8 10 20 40
c: 0 22 0 0 0 0 0 0 0
d: ffff 507 0 0 0 0 0 0 0
e: ffff 36 0 0 0 0 0 0 0
f: ffff f00 dada dada dada dada dada dada dada
10: 0 0 0 0 0 0 0 0 0
11: 0 0 0 0 0 0 0 0 0
12: 5555 0 0 0 0 0 0 0 0
13: 5555 0 34d 8b18 54d 0 0 0 0
14: aaaa 400 0 0 0 0 0 0 0
15: aaaa 0 0 0 0 0 0 0 0
16: ffff 0 33 33 33 33 33 33 0
17: ffff 0 0 0 0 0 0 0 0
18: fa41 1884 3210 3210 3210 3210 3210 3210 3210
19: 0 5e1 7654 7654 7654 7654 7654 7654 7654
1a: 0 0 0 0 0 0 0 0 0
1b: 1fc f869 8000 8000 8000 8000 8000 8000 8000
1c: 0 4c00 0 0 0 0 0 0 0
1d: 5ce0 0 0 0 0 0 0 0 0
1e: 0 0 0 0 0 0 0 0 0
1f: 0 0 0 0 0 0 0 0 0
The main difference is GLOBAL2 5th register. When the unit is just
initialized, the driver sets this register to 00ff, however, when the
issue happens, its value is c12f.
We got a patch which allows us to set registers values. If we change
c12f to 00ff the ping works, otherwise, ping does not work. We do not
know who is changing the register value. Apparently, driver does not.
Weirderif possible, sometimes even global2 5th register is set to 00ff
and bridge does not forward packages either. We have not sorted out
which other register is affecting.
Finally, The weirdest behaviour we are seeing is that the unit does not
detect a link change, register 0 of ports 1 and 2 do not update their
status.
Have you experienced a similar issue in your side?
Is it possible that those micro-outage could be the reason of bad
settings in Global2 5th register?
Have you fixed this issues in a newer Linux kernel version?
Thanks in advance.
^ permalink raw reply
* [ISSUE: mv88e6xxx]: Down/Up link and not forwarding
From: Jose Antonio Delgado Alfonso @ 2016-10-04 15:13 UTC (permalink / raw)
To: netdev
We are working in an ARMv7 embedded system running kernel 4.1 but
including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
should not return a boolean."
This is the schema of the system.
+---------------------+ eth0
| +--+
| | |
| Embedded system +--+
| |
| ARMv7 |
| | Marvell 88E8057(sky2)
+------------------+
| +--+
+--+ +--+ eth1@marvell
| | +---------------------------+
| | +-------+
| +--+ CPU port +--+
mv88e6176 +--+
+------+--+-----------+
| |
emulated | |
| |
GPIO-MDIO +--+
+--+ +--+ eth2@marvell
+-------------------------------------------+
| | +-------+
MDIO
+--+ +--+
+------------------+
There is a bridge (br-lan) which includes eth0/eth1/eth2
>From time to time, We are seeing a link down and up of about 1s.
Following the message that kernel sends.
[ 312.769399] dsa dsa@0 eth2: Link is Down
[ 312.773372] br-lan: port 3(eth2) entered disabled state
[ 312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
control disabled
[ 312.963807] br-lan: port 3(eth2) entered forwarding state
[ 312.969276] br-lan: port 3(eth2) entered forwarding state
[ 313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
rx/tx
[ 314.966277] br-lan: port 3(eth2) entered forwarding state
Moreover, under a reboot loop test which consists in booting the system,
ping the unit and, if it responds, reboot again, we found that the
bridge does not forward packages after many reboots.
Looking into 88e6176 registers we saw the following
GLOBAL GLOBAL2 0 1 2 3 4 5 6
0: c820 0 de0f 5d0f 500f 500f 500f 4e07 4007
1: 3 0 3e 3 3 3 3 3 3
2: 0 ffff 0 0 0 0 0 0 0
3: 0 ffff 1761 1761 1761 1761 1761 1761 1761
4: 6000 258 373f 433 430 433 433 433 433
5: 1000 c12f 0 0 0 0 0 0 0
6: c000 1f0f 101e 3005 3003 4001 5001 6001 7001
7: 0 707f 0 0 0 0 0 0 0
8: 0 7800 2480 2480 2480 2480 2480 2480 2480
9: 0 1600 1 1 1 1 1 1 1
a: 148 0 0 0 0 0 0 0 0
b: 6000 1000 1 2 4 8 10 20 40
c: 0 22 0 0 0 0 0 0 0
d: ffff 507 0 0 0 0 0 0 0
e: ffff 36 0 0 0 0 0 0 0
f: ffff f00 dada dada dada dada dada dada dada
10: 0 0 0 0 0 0 0 0 0
11: 0 0 0 0 0 0 0 0 0
12: 5555 0 0 0 0 0 0 0 0
13: 5555 0 34d 8b18 54d 0 0 0 0
14: aaaa 400 0 0 0 0 0 0 0
15: aaaa 0 0 0 0 0 0 0 0
16: ffff 0 33 33 33 33 33 33 0
17: ffff 0 0 0 0 0 0 0 0
18: fa41 1884 3210 3210 3210 3210 3210 3210 3210
19: 0 5e1 7654 7654 7654 7654 7654 7654 7654
1a: 0 0 0 0 0 0 0 0 0
1b: 1fc f869 8000 8000 8000 8000 8000 8000 8000
1c: 0 4c00 0 0 0 0 0 0 0
1d: 5ce0 0 0 0 0 0 0 0 0
1e: 0 0 0 0 0 0 0 0 0
1f: 0 0 0 0 0 0 0 0 0
The main difference is GLOBAL2 5th register. When the unit is just
initialized, the driver sets this register to 00ff, however, when the
issue happens, its value is c12f.
We got a patch which allows us to set registers values. If we change
c12f to 00ff the ping works, otherwise, ping does not work. We do not
know who is changing the register value. Apparently, driver does not.
Weirderif possible, sometimes even global2 5th register is set to 00ff
and bridge does not forward packages either. We have not sorted out
which other register is affecting.
Finally, The weirdest behaviour we are seeing is that the unit does not
detect a link change, register 0 of ports 1 and 2 do not update their
status.
Have you experienced a similar issue in your side?
Is it possible that those micro-outage could be the reason of bad
settings in Global2 5th register?
Have you fixed this issues in a newer Linux kernel version?
Thanks in advance.
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches
From: David Vrabel @ 2016-10-04 14:51 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Paul Durrant
Cc: netdev, Wei Liu, David Vrabel, xen-devel
In-Reply-To: <20161004124744.GC30836@localhost.localdomain>
On 04/10/16 13:47, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 04, 2016 at 10:29:16AM +0100, Paul Durrant wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> Instead of only placing one skb on the guest rx ring at a time, process
>> a batch of up-to 64. This improves performance by ~10% in some tests.
>
> And does it regress latency workloads?
No. Because the loop outside of these batches is only checking for a
fatal error condition or a disconnection.
> What are those 'some tests' you speak off?
I think it was aggregate intrahost, but I don't remember exactly.
David
^ permalink raw reply
* RE: [net-next 08/13] fsl/fman: check pcsphy pointer before use
From: David Laight @ 2016-10-04 14:44 UTC (permalink / raw)
To: 'madalin.bucur@nxp.com', netdev@vger.kernel.org
Cc: linuxdev.baldrick@gmail.com, linuxppc-dev@lists.ozlabs.org,
davem@davemloft.net, linux-kernel@vger.kernel.org
In-Reply-To: <1475566379-5078-9-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur
> Sent: 04 October 2016 08:33
> Subject: [net-next 08/13] fsl/fman: check pcsphy pointer before use
..
> --- a/drivers/net/ethernet/freescale/fman/fman_memac.c
> +++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
> @@ -507,6 +507,9 @@ static void setup_sgmii_internal_phy(struct fman_mac *memac,
> {
> u16 tmp_reg16;
>
> + if (WARN_ON(!memac->pcsphy))
> + return;
> +
Why?
Either it can validly be NULL in which case you don't want the message.
Or it shouldn't be NULL in which case you need to find and fix the bug.
The later kernel OOPS will make the bug much easier to find.
David
^ permalink raw reply
* Re: [PATCH v7 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Andrew Lunn @ 2016-10-04 14:34 UTC (permalink / raw)
To: Raju Lakkaraju; +Cc: netdev, devicetree, f.fainelli, Allan.Nielsen
In-Reply-To: <1475589845-29182-1-git-send-email-Raju.Lakkaraju@microsemi.com>
> v7:
> - As per review comment, Removed '-'s (minus) sign in Edge rate table.
Still no exact match on the table.
So if i specify a voltage of 3301, 53% slowdown it looks i will
actually get 0% slowdown and no error message. That is not very
helpful.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: Add PHY Auto/Mdi/Mdix set driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 14:31 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, f.fainelli, Allan.Nielsen
In-Reply-To: <20160928202451.GC30728@lunn.ch>
Hi Andrew,
Thank you for code review and valuable comments.
On Wed, Sep 28, 2016 at 10:24:51PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
>
>
> > + reg_val = phy_read(phydev, MSCC_PHY_BYPASS_CONTROL);
> > + if ((mdix == ETH_TP_MDI) || (mdix == ETH_TP_MDI_X)) {
> > + reg_val |= (DISABLE_PAIR_SWAP_CORR_MASK |
> > + DISABLE_POLARITY_CORR_MASK |
> > + DISABLE_HP_AUTO_MDIX_MASK);
> > + } else {
> > + reg_val &= ~(DISABLE_PAIR_SWAP_CORR_MASK |
> > + DISABLE_POLARITY_CORR_MASK |
> > + DISABLE_HP_AUTO_MDIX_MASK);
> > + }
> > + rc = phy_write(phydev, MSCC_PHY_BYPASS_CONTROL, reg_val);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + reg_val = phy_read(phydev, MSCC_PHY_EXT_MODE_CNTL);
> > + reg_val &= ~(FORCE_MDI_CROSSOVER_MASK);
> > + if (mdix == ETH_TP_MDI)
> > + reg_val |= FORCE_MDI_CROSSOVER_MDI;
> > + else if (mdix == ETH_TP_MDI_X)
> > + reg_val |= FORCE_MDI_CROSSOVER_MDIX;
> > + rc = phy_write(phydev, MSCC_PHY_EXT_MODE_CNTL, reg_val);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
> > +
> > +out_unlock:
>
> out_unlock seems a bit of an odd name, since you are not unlocking
> anything.
>
It's my mistake. Mutex should be there. I will add mutex.
> I also wonder if you should try to reset to MSCC_PHY_PAGE_STANDARD in
> the error condition?
>
> > +
> > + return rc;
> > +}
> > +
> > static int vsc85xx_wol_set(struct phy_device *phydev,
> > struct ethtool_wolinfo *wol)
> > {
> > @@ -227,6 +281,7 @@ static int vsc85xx_default_config(struct phy_device *phydev)
> > int rc;
> > u16 reg_val;
> >
> > + phydev->mdix = ETH_TP_MDI_AUTO;
>
> Humm, interesting. The only other driver supporting mdix is the
> Marvell one. It does not do this, it leaves it to its default value of
> ETH_TP_MDI_INVALID. It does however interpret ETH_TP_MDI_INVALID as
> meaning as ETH_TP_MDI_AUTO.
>
> There needs to be consistency here. You either need to do the same as
> the Marvell driver, or you need to modify the Marvell driver to also
> set phydev->mdix to ETH_TP_MDI_AUTO.
>
In Ethtool two variable i.e. eth_tp_mdix_ctrl, eth_tp_mdix use to update
the status. But, driver header is having one variable i.e. mdix.
Driver header should also have another variabl like mdix_ctrl.
Then, Ethtool can get/set the Auto MDIX/MDI.
In case, mdix is not configure with ETH_TP_MDI_AUTO, Ethtool shows error as
"setting MDI not supported"
Please suggest me if you have any better method to fix this issue.
> I don't yet know which of these two is the right thing to do.
>
> Florian?
>
> Andrew
---
Thanks,
Raju.
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature
From: Konrad Rzeszutek Wilk @ 2016-10-04 14:24 UTC (permalink / raw)
To: Paul Durrant, bouyer, roger.pau
Cc: annie.li@oracle.com, joao.m.martins@oracle.com,
netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Wei Liu
In-Reply-To: <6af51a0a84cf41d5a31168b3e8626fcd@AMSPEX02CL03.citrite.net>
On Tue, Oct 04, 2016 at 01:35:41PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: 04 October 2016 13:52
> > To: Paul Durrant <Paul.Durrant@citrix.com>; annie.li@oracle.com;
> > joao.m.martins@oracle.com
> > Cc: netdev@vger.kernel.org; xen-devel@lists.xenproject.org; Wei Liu
> > <wei.liu2@citrix.com>
> > Subject: Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest
> > rx side prefix GSO feature
> >
> > On Tue, Oct 04, 2016 at 10:29:13AM +0100, Paul Durrant wrote:
> > > As far as I am aware only very old Windows network frontends make use
> > > of this style of passing GSO packets from backend to frontend. These
> > > frontends can easily be replaced by the freely available Xen Project
> > > Windows PV network frontend, which uses the 'default' mechanism for
> > > passing GSO packets, which is also used by all Linux frontends.
> >
> > It is not that simple. Some companies have extra juice in their Windows
> > frontends so can't easily swap over to the Xen Project one.
>
> Ok, then those frontends will continue to work, but they won't get GSO packets any more. Prefix GSO has never been specified in the canonical netif header and so has been in a limbo state forever so such frontends have always been on borrowed time and only just happened to work against a linux backend. If someone wants to actually specify prefix GSO properly then it could be added back in, but it should not be necessary now that the RX side req<->rsp identity relation is documented (http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=HEAD#l729).
>
> >
> > Either way CC-ing Annie
> >
> > Also would it make sense to CC the FreeBSD and NetBSD maintainers of their
> > PV drivers just to make sure? (Or has that been confirmed)
> >
>
> I could do that, but I'd hope that they would be subscribed to xen-devel and will chime in if there's likely to be a problem.
Usually one CCs those folks. I think you are asking me to do
the legwork and find them and CC them here?
CC-ing Roger and Manuel Bouyer.
>
> > >
> > > NOTE: Removal of this feature will not cause breakage in old Windows
> > > frontends. They simply will no longer receive GSO packets - the
> > > packets instead being fragmented in the backend.
> >
> > Did you also test this with SuSE/Novell Windows PV drivers?
> >
>
> No, I don't have copies of these. Internal XenServer testing has not shown up any issues with 'legacy' PV drivers though (which do still have the prefix GSO code in).
You can download these drivers and install on your guests.
>
> Paul
>
> > Thanks.
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > ---
> > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > ---
> > > drivers/net/xen-netback/common.h | 1 -
> > > drivers/net/xen-netback/interface.c | 4 ++--
> > > drivers/net/xen-netback/rx.c | 26 --------------------------
> > > drivers/net/xen-netback/xenbus.c | 21 ---------------------
> > > 4 files changed, 2 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/net/xen-netback/common.h
> > > b/drivers/net/xen-netback/common.h
> > > index b38fb2c..0ba5910 100644
> > > --- a/drivers/net/xen-netback/common.h
> > > +++ b/drivers/net/xen-netback/common.h
> > > @@ -260,7 +260,6 @@ struct xenvif {
> > >
> > > /* Frontend feature information. */
> > > int gso_mask;
> > > - int gso_prefix_mask;
> > >
> > > u8 can_sg:1;
> > > u8 ip_csum:1;
> > > diff --git a/drivers/net/xen-netback/interface.c
> > > b/drivers/net/xen-netback/interface.c
> > > index fb50c6d..211d542 100644
> > > --- a/drivers/net/xen-netback/interface.c
> > > +++ b/drivers/net/xen-netback/interface.c
> > > @@ -319,9 +319,9 @@ static netdev_features_t
> > > xenvif_fix_features(struct net_device *dev,
> > >
> > > if (!vif->can_sg)
> > > features &= ~NETIF_F_SG;
> > > - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
> > > + if (~(vif->gso_mask) & GSO_BIT(TCPV4))
> > > features &= ~NETIF_F_TSO;
> > > - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
> > > + if (~(vif->gso_mask) & GSO_BIT(TCPV6))
> > > features &= ~NETIF_F_TSO6;
> > > if (!vif->ip_csum)
> > > features &= ~NETIF_F_IP_CSUM;
> > > diff --git a/drivers/net/xen-netback/rx.c
> > > b/drivers/net/xen-netback/rx.c index 03836aa..6bd7d6e 100644
> > > --- a/drivers/net/xen-netback/rx.c
> > > +++ b/drivers/net/xen-netback/rx.c
> > > @@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> > > gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> > > }
> > >
> > > - /* Set up a GSO prefix descriptor, if necessary */
> > > - if ((1 << gso_type) & vif->gso_prefix_mask) {
> > > - RING_COPY_REQUEST(&queue->rx, queue->rx.req_cons++,
> > &req);
> > > - meta = npo->meta + npo->meta_prod++;
> > > - meta->gso_type = gso_type;
> > > - meta->gso_size = skb_shinfo(skb)->gso_size;
> > > - meta->size = 0;
> > > - meta->id = req.id;
> > > - }
> > > -
> > > RING_COPY_REQUEST(&queue->rx, queue->rx.req_cons++, &req);
> > > meta = npo->meta + npo->meta_prod++;
> > >
> > > @@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue
> > *queue)
> > > while ((skb = __skb_dequeue(&rxq)) != NULL) {
> > > struct xen_netif_extra_info *extra = NULL;
> > >
> > > - if ((1 << queue->meta[npo.meta_cons].gso_type) &
> > > - vif->gso_prefix_mask) {
> > > - resp = RING_GET_RESPONSE(&queue->rx,
> > > - queue->rx.rsp_prod_pvt++);
> > > -
> > > - resp->flags = XEN_NETRXF_gso_prefix |
> > > - XEN_NETRXF_more_data;
> > > -
> > > - resp->offset = queue-
> > >meta[npo.meta_cons].gso_size;
> > > - resp->id = queue->meta[npo.meta_cons].id;
> > > - resp->status = XENVIF_RX_CB(skb)-
> > >meta_slots_used;
> > > -
> > > - npo.meta_cons++;
> > > - XENVIF_RX_CB(skb)->meta_slots_used--;
> > > - }
> > > -
> > > queue->stats.tx_bytes += skb->len;
> > > queue->stats.tx_packets++;
> > >
> > > diff --git a/drivers/net/xen-netback/xenbus.c
> > > b/drivers/net/xen-netback/xenbus.c
> > > index daf4c78..7056404 100644
> > > --- a/drivers/net/xen-netback/xenbus.c
> > > +++ b/drivers/net/xen-netback/xenbus.c
> > > @@ -1135,7 +1135,6 @@ static int read_xenbus_vif_flags(struct
> > backend_info *be)
> > > vif->can_sg = !!val;
> > >
> > > vif->gso_mask = 0;
> > > - vif->gso_prefix_mask = 0;
> > >
> > > if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
> > > "%d", &val) < 0)
> > > @@ -1143,32 +1142,12 @@ static int read_xenbus_vif_flags(struct
> > backend_info *be)
> > > if (val)
> > > vif->gso_mask |= GSO_BIT(TCPV4);
> > >
> > > - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4-
> > prefix",
> > > - "%d", &val) < 0)
> > > - val = 0;
> > > - if (val)
> > > - vif->gso_prefix_mask |= GSO_BIT(TCPV4);
> > > -
> > > if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6",
> > > "%d", &val) < 0)
> > > val = 0;
> > > if (val)
> > > vif->gso_mask |= GSO_BIT(TCPV6);
> > >
> > > - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6-
> > prefix",
> > > - "%d", &val) < 0)
> > > - val = 0;
> > > - if (val)
> > > - vif->gso_prefix_mask |= GSO_BIT(TCPV6);
> > > -
> > > - if (vif->gso_mask & vif->gso_prefix_mask) {
> > > - xenbus_dev_fatal(dev, err,
> > > - "%s: gso and gso prefix flags are not "
> > > - "mutually exclusive",
> > > - dev->otherend);
> > > - return -EOPNOTSUPP;
> > > - }
> > > -
> > > if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-no-csum-
> > offload",
> > > "%d", &val) < 0)
> > > val = 0;
> > > --
> > > 2.1.4
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: Add Wake-on-LAN driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 14:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Allan.Nielsen, andrew
In-Reply-To: <74356bf4-9567-f948-65c1-54fad381423d@gmail.com>
Hi Florian,
Thank you for code review and valuable comments.
On Wed, Sep 28, 2016 at 10:37:07AM -0700, Florian Fainelli wrote:
> EXTERNAL EMAIL
>
>
> On 09/28/2016 05:01 AM, Raju Lakkaraju wrote:
> > From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> >
> > Wake-on-LAN (WoL) is an Ethernet networking standard that allows
> > a computer/device to be turned on or awakened by a network message.
> > VSC8531 PHY can support this feature configure by driver set function.
> > WoL status get by driver get function.
> >
> > Tested on Beaglebone Black with VSC 8531 PHY.
> >
> > Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> > ---
> > drivers/net/phy/mscc.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 132 insertions(+)
> >
> > diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> > index d350deb..ca6ea23 100644
> > --- a/drivers/net/phy/mscc.c
> > +++ b/drivers/net/phy/mscc.c
> > @@ -11,6 +11,7 @@
> > #include <linux/mdio.h>
> > #include <linux/mii.h>
> > #include <linux/phy.h>
> > +#include <linux/netdevice.h>
> >
> > enum rgmii_rx_clock_delay {
> > RGMII_RX_CLK_DELAY_0_2_NS = 0,
> > @@ -35,6 +36,7 @@ enum rgmii_rx_clock_delay {
> >
> > #define MII_VSC85XX_INT_MASK 25
> > #define MII_VSC85XX_INT_MASK_MASK 0xa000
> > +#define MII_VSC85XX_INT_MASK_WOL 0x0040
> > #define MII_VSC85XX_INT_STATUS 26
> >
> > #define MSCC_EXT_PAGE_ACCESS 31
> > @@ -46,6 +48,19 @@ enum rgmii_rx_clock_delay {
> > #define RGMII_RX_CLK_DELAY_MASK 0x0070
> > #define RGMII_RX_CLK_DELAY_POS 4
> >
> > +#define MSCC_PHY_WOL_LOWER_MAC_ADDR 21
> > +#define MSCC_PHY_WOL_MID_MAC_ADDR 22
> > +#define MSCC_PHY_WOL_UPPER_MAC_ADDR 23
> > +#define MSCC_PHY_WOL_LOWER_PASSWD 24
> > +#define MSCC_PHY_WOL_MID_PASSWD 25
> > +#define MSCC_PHY_WOL_UPPER_PASSWD 26
> > +
> > +#define MSCC_PHY_WOL_MAC_CONTROL 27
> > +#define EDGE_RATE_CNTL_POS 5
> > +#define EDGE_RATE_CNTL_MASK 0x00E0
> > +#define SECURE_ON_ENABLE 0x8000
> > +#define SECURE_ON_PASSWD_LEN_4 0x4000
> > +
> > /* Microsemi PHY ID's */
> > #define PHY_ID_VSC8531 0x00070570
> > #define PHY_ID_VSC8541 0x00070770
> > @@ -58,6 +73,119 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
> > return rc;
> > }
> >
> > +static int vsc85xx_wol_set(struct phy_device *phydev,
> > + struct ethtool_wolinfo *wol)
> > +{
> > + int rc;
> > + u16 reg_val;
> > + struct ethtool_wolinfo *wol_conf = wol;
> > +
> > + mutex_lock(&phydev->lock);
>
> This mutex is used here because you are using an indirect page access,
> right? This is not to protect against multiple calls of wol_set from
> different executing threads?
>
Correct. mutex is used for indirect page access.
I did find any protect against multiple calls of wol_set in other vendors.
Do you have any suggestions?
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + if (wol->wolopts & WAKE_MAGIC) {
> > + /* Store the device address for the magic packet */
> > + reg_val = phydev->attached_dev->dev_addr[4] << 8;
> > + reg_val |= phydev->attached_dev->dev_addr[5];
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_MAC_ADDR, reg_val);
> > + reg_val = phydev->attached_dev->dev_addr[2] << 8;
> > + reg_val |= phydev->attached_dev->dev_addr[3];
> > + phy_write(phydev, MSCC_PHY_WOL_MID_MAC_ADDR, reg_val);
> > + reg_val = phydev->attached_dev->dev_addr[0] << 8;
> > + reg_val |= phydev->attached_dev->dev_addr[1];
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_MAC_ADDR, reg_val);
> > + } else {
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_MAC_ADDR, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_MID_MAC_ADDR, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_MAC_ADDR, 0);
> > + }
> > +
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE)
> > + reg_val |= SECURE_ON_ENABLE;
> > + else
> > + reg_val &= ~SECURE_ON_ENABLE;
> > + phy_write(phydev, MSCC_PHY_WOL_MAC_CONTROL, reg_val);
> > +
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE) {
> > + reg_val = wol_conf->sopass[4] << 8;
> > + reg_val |= wol_conf->sopass[5];
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[2] << 8;
> > + reg_val |= wol_conf->sopass[3];
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[0] << 8;
> > + reg_val |= wol_conf->sopass[1];
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, reg_val);
> > + } else {
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, 0);
> > + }
>
> How about making the code a little simpler in both cases with something
> like this the following:
>
> u16 pwd = { };
> unsigned int i;
>
> if (wol_conf->wolopts & WAKE_MAGICECURE)
> for (i = 0; i < ARRAY_SIZE(pwd); i++)
> pwd[i] = wol_conf->so_pass[5 - (i * 2 + 1)] << 8|
> wol_conf->so_pass[5 - i * 2 ]
>
> phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, pwd[0]);
> phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, pwd[1]);
> phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, pwd[2]);
>
Accepted. I will change.
> > +
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + if (wol->wolopts & WAKE_MAGIC) {
>
> Don't you also need to check WAKE_MAGICSECURE here as well? Or is the
> interrupt going to be generated only if there is no password defined?
>
Interrupt is going to be generated when WAKE_MAGIC.
WAKE_MAGICSECURE is extra protection.
> > + /* Enable the WOL interrupt */
> > + reg_val = phy_read(phydev, MII_VSC85XX_INT_MASK);
> > + reg_val |= MII_VSC85XX_INT_MASK_WOL;
> > + rc = phy_write(phydev, MII_VSC85XX_INT_MASK, reg_val);
> > + if (rc != 0)
> > + goto out_unlock;
> > + } else {
> > + /* Disable the WOL interrupt */
> > + reg_val = phy_read(phydev, MII_VSC85XX_INT_MASK);
> > + reg_val &= (~MII_VSC85XX_INT_MASK_WOL);
> > + rc = phy_write(phydev, MII_VSC85XX_INT_MASK, reg_val);
> > + if (rc != 0)
> > + goto out_unlock;
> > + }
> > + /* Clear WOL iterrupt status */
> > + reg_val = phy_read(phydev, MII_VSC85XX_INT_STATUS);
> > +
> > +out_unlock:
> > + mutex_unlock(&phydev->lock);
> > +
> > + return rc;
> > +}
> > +
> > +static void vsc85xx_wol_get(struct phy_device *phydev,
> > + struct ethtool_wolinfo *wol)
> > +{
> > + int rc;
> > + u16 reg_val;
> > + struct ethtool_wolinfo *wol_conf = wol;
> > +
> > + mutex_lock(&phydev->lock);
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
> > + if (reg_val & SECURE_ON_ENABLE)
> > + wol_conf->wolopts |= WAKE_MAGICSECURE;
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE) {
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_LOWER_PASSWD);
> > + wol_conf->sopass[5] = reg_val & 0x00ff;
> > + wol_conf->sopass[4] = (reg_val & 0xff00) >> 8;
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_MID_PASSWD);
> > + wol_conf->sopass[3] = reg_val & 0x00ff;
> > + wol_conf->sopass[2] = (reg_val & 0xff00) >> 8;
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_UPPER_PASSWD);
> > + wol_conf->sopass[1] = reg_val & 0x00ff;
> > + wol_conf->sopass[0] = (reg_val & 0xff00) >> 8;
> > + }
> > +
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
> > +
> > +out_unlock:
> > + mutex_unlock(&phydev->lock);
> > +}
> > +
> > static int vsc85xx_mac_if_set(struct phy_device *phydev,
> > phy_interface_t interface)
> > {
> > @@ -177,6 +305,8 @@ static struct phy_driver vsc85xx_driver[] = {
> > .config_intr = &vsc85xx_config_intr,
> > .suspend = &genphy_suspend,
> > .resume = &genphy_resume,
> > + .set_wol = &vsc85xx_wol_set,
> > + .get_wol = &vsc85xx_wol_get,
> > },
> > {
> > .phy_id = PHY_ID_VSC8541,
> > @@ -193,6 +323,8 @@ static struct phy_driver vsc85xx_driver[] = {
> > .config_intr = &vsc85xx_config_intr,
> > .suspend = &genphy_suspend,
> > .resume = &genphy_resume,
> > + .set_wol = &vsc85xx_wol_set,
> > + .get_wol = &vsc85xx_wol_get,
> > }
> >
> > };
> >
>
>
> --
> Florian
---
Thanks,
Raju.
^ permalink raw reply
* Re: [PATCH 2/7] ethtool: avoid resource leak of strings in do_gprivflags
From: John W. Linville @ 2016-10-04 14:02 UTC (permalink / raw)
To: Jarod Wilson; +Cc: netdev
In-Reply-To: <20161003175426.GC43474@redhat.com>
On Mon, Oct 03, 2016 at 01:54:26PM -0400, Jarod Wilson wrote:
> On Fri, Sep 30, 2016 at 03:56:16PM -0400, John W. Linville wrote:
> > Coverity issue: 1363119
> > Fixes: e1ee596326ae ("Add support for querying and setting private flags")
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > ethtool.c | 18 +++++++++++++-----
> > 1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/ethtool.c b/ethtool.c
> > index aa3ef5ed2f75..0885a61097ad 100644
> > --- a/ethtool.c
> > +++ b/ethtool.c
> > @@ -4205,7 +4205,7 @@ static int do_gprivflags(struct cmd_context *ctx)
> > struct ethtool_gstrings *strings;
> > struct ethtool_value flags;
> > unsigned int i;
> > - int max_len = 0, cur_len;
> > + int max_len = 0, cur_len, rc;
> >
> > if (ctx->argc != 0)
> > exit_bad_args();
> > @@ -4215,11 +4215,13 @@ static int do_gprivflags(struct cmd_context *ctx)
> > 1);
> > if (!strings) {
> > perror("Cannot get private flag names");
> > - return 1;
> > + rc = 1;
> > + goto err;
>
> This goto looks redundant, since all you're doing at err is re-checking if
> strings is non-null to free it.
True, the original return is just as good there. And since strings
is non-NULL for everything after that, the NULL check at error can
be eliminated as well...
Thanks!
John
> > if (strings->len == 0) {
> > fprintf(stderr, "No private flags defined\n");
> > - return 1;
> > + rc = 1;
> > + goto err;
> > }
> > if (strings->len > 32) {
> > /* ETHTOOL_GPFLAGS can only cover 32 flags */
> > @@ -4230,7 +4232,8 @@ static int do_gprivflags(struct cmd_context *ctx)
> > flags.cmd = ETHTOOL_GPFLAGS;
> > if (send_ioctl(ctx, &flags)) {
> > perror("Cannot get private flags");
> > - return 1;
> > + rc = 1;
> > + goto err;
> > }
> >
> > /* Find longest string and align all strings accordingly */
> > @@ -4248,7 +4251,12 @@ static int do_gprivflags(struct cmd_context *ctx)
> > (const char *)strings->data + i * ETH_GSTRING_LEN,
> > (flags.data & (1U << i)) ? "on" : "off");
> >
> > - return 0;
> > + rc = 0;
> > +
> > +err:
> > + if (strings)
> > + free(strings);
> > + return rc;
> > }
> >
> > static int do_sprivflags(struct cmd_context *ctx)
> > --
> > 2.7.4
> >
>
> --
> Jarod Wilson
> jarod@redhat.com
>
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH v2 2/7] ethtool: avoid resource leak of strings in do_gprivflags
From: John W. Linville @ 2016-10-04 14:05 UTC (permalink / raw)
To: netdev; +Cc: Jarod Wilson, John W. Linville
In-Reply-To: <1475265381-28937-3-git-send-email-linville@tuxdriver.com>
Coverity issue: 1363119
Fixes: e1ee596326ae ("Add support for querying and setting private flags")
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewed-by: Greg Rose <grose@lightfleet.com>
---
ethtool.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index aa3ef5ed2f75..7ce5667fcdd7 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4205,7 +4205,7 @@ static int do_gprivflags(struct cmd_context *ctx)
struct ethtool_gstrings *strings;
struct ethtool_value flags;
unsigned int i;
- int max_len = 0, cur_len;
+ int max_len = 0, cur_len, rc;
if (ctx->argc != 0)
exit_bad_args();
@@ -4219,7 +4219,8 @@ static int do_gprivflags(struct cmd_context *ctx)
}
if (strings->len == 0) {
fprintf(stderr, "No private flags defined\n");
- return 1;
+ rc = 1;
+ goto err;
}
if (strings->len > 32) {
/* ETHTOOL_GPFLAGS can only cover 32 flags */
@@ -4230,7 +4231,8 @@ static int do_gprivflags(struct cmd_context *ctx)
flags.cmd = ETHTOOL_GPFLAGS;
if (send_ioctl(ctx, &flags)) {
perror("Cannot get private flags");
- return 1;
+ rc = 1;
+ goto err;
}
/* Find longest string and align all strings accordingly */
@@ -4248,7 +4250,11 @@ static int do_gprivflags(struct cmd_context *ctx)
(const char *)strings->data + i * ETH_GSTRING_LEN,
(flags.data & (1U << i)) ? "on" : "off");
- return 0;
+ rc = 0;
+
+err:
+ free(strings);
+ return rc;
}
static int do_sprivflags(struct cmd_context *ctx)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: phy: Add Wake-on-LAN driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 14:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, f.fainelli, Allan.Nielsen
In-Reply-To: <20160928162705.GB25553@lunn.ch>
Hi Andrew,
Thank you for code review and valuable comments.
On Wed, Sep 28, 2016 at 06:27:05PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
>
>
> > +#define MSCC_PHY_WOL_MAC_CONTROL 27
> > +#define EDGE_RATE_CNTL_POS 5
> > +#define EDGE_RATE_CNTL_MASK 0x00E0
>
> This patch does not require these two #defines.
>
> Please indicate in the cover note if the patches depends on other
> patches in order to cleanly apply. Or if these patches are going to
> conflict with some other patches.
>
Accepted. I will remove those 2 defines.
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE)
> > + reg_val |= SECURE_ON_ENABLE;
> > + else
> > + reg_val &= ~SECURE_ON_ENABLE;
> > + phy_write(phydev, MSCC_PHY_WOL_MAC_CONTROL, reg_val);
> > +
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE) {
> > + reg_val = wol_conf->sopass[4] << 8;
> > + reg_val |= wol_conf->sopass[5];
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[2] << 8;
> > + reg_val |= wol_conf->sopass[3];
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[0] << 8;
> > + reg_val |= wol_conf->sopass[1];
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, reg_val);
> > + } else {
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, 0);
> > + }
>
> Wouldn't it be better to set the password, and then enable the
> password feature?
>
Accepted. I will change.
> I don't know much about WOL. Hopefully Florian will add further
> comments.
>
> Andrew
---
Thanks,
Raju.
^ permalink raw reply
* RE: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches
From: Paul Durrant @ 2016-10-04 14:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Wei Liu,
David Vrabel
In-Reply-To: <20161004124744.GC30836@localhost.localdomain>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: 04 October 2016 13:48
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: netdev@vger.kernel.org; xen-devel@lists.xenproject.org; Wei Liu
> <wei.liu2@citrix.com>; David Vrabel <david.vrabel@citrix.com>
> Subject: Re: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process
> guest rx packets in batches
>
> On Tue, Oct 04, 2016 at 10:29:16AM +0100, Paul Durrant wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> >
> > Instead of only placing one skb on the guest rx ring at a time,
> > process a batch of up-to 64. This improves performance by ~10% in some
> tests.
I believe the tests are mainly throughput tests, but David would know the specifics.
>
> And does it regress latency workloads?
>
It shouldn't, although I have not run ping-pong tests to verify. If packets are only placed on the vif queue singly though then the batching should have no effect, since rx_action will complete and do the push as before.
Paul
> What are those 'some tests' you speak off?
>
> Thanks.
> >
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com> [re-based]
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > ---
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> > drivers/net/xen-netback/rx.c | 15 ++++++++++++++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/xen-netback/rx.c
> > b/drivers/net/xen-netback/rx.c index 9548709..ae822b8 100644
> > --- a/drivers/net/xen-netback/rx.c
> > +++ b/drivers/net/xen-netback/rx.c
> > @@ -399,7 +399,7 @@ static void xenvif_rx_extra_slot(struct
> xenvif_queue *queue,
> > BUG();
> > }
> >
> > -void xenvif_rx_action(struct xenvif_queue *queue)
> > +void xenvif_rx_skb(struct xenvif_queue *queue)
> > {
> > struct xenvif_pkt_state pkt;
> >
> > @@ -425,6 +425,19 @@ void xenvif_rx_action(struct xenvif_queue
> *queue)
> > xenvif_rx_complete(queue, &pkt);
> > }
> >
> > +#define RX_BATCH_SIZE 64
> > +
> > +void xenvif_rx_action(struct xenvif_queue *queue) {
> > + unsigned int work_done = 0;
> > +
> > + while (xenvif_rx_ring_slots_available(queue) &&
> > + work_done < RX_BATCH_SIZE) {
> > + xenvif_rx_skb(queue);
> > + work_done++;
> > + }
> > +}
> > +
> > static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue) {
> > RING_IDX prod, cons;
> > --
> > 2.1.4
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
^ permalink raw reply
* RE: [Xen-devel] [PATCH v2 net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space
From: Paul Durrant @ 2016-10-04 13:56 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Wei Liu,
David Vrabel
In-Reply-To: <20161004124854.GD30836@localhost.localdomain>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: 04 October 2016 13:49
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: netdev@vger.kernel.org; xen-devel@lists.xenproject.org; Wei Liu
> <wei.liu2@citrix.com>; David Vrabel <david.vrabel@citrix.com>
> Subject: Re: [Xen-devel] [PATCH v2 net-next 4/7] xen-netback: immediately
> wake tx queue when guest rx queue has space
>
> On Tue, Oct 04, 2016 at 02:29:15AM -0700, Paul Durrant wrote:
> > From: David Vrabel <david.vrabel@citrix.com>
> >
> > When an skb is removed from the guest rx queue, immediately wake the
> > tx queue, instead of after processing them.
>
> Please, could the description explain why?
>
Is it not reasonably obvious that it improves parallelism between filling and draining the queue? I could add a comment if you think it needs spelling out.
Paul
> >
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com> [re-based]
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > ---
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> > drivers/net/xen-netback/rx.c | 24 ++++++++----------------
> > 1 file changed, 8 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/rx.c
> > b/drivers/net/xen-netback/rx.c index b0ce4c6..9548709 100644
> > --- a/drivers/net/xen-netback/rx.c
> > +++ b/drivers/net/xen-netback/rx.c
> > @@ -92,27 +92,21 @@ static struct sk_buff *xenvif_rx_dequeue(struct
> xenvif_queue *queue)
> > spin_lock_irq(&queue->rx_queue.lock);
> >
> > skb = __skb_dequeue(&queue->rx_queue);
> > - if (skb)
> > + if (skb) {
> > queue->rx_queue_len -= skb->len;
> > + if (queue->rx_queue_len < queue->rx_queue_max) {
> > + struct netdev_queue *txq;
> > +
> > + txq = netdev_get_tx_queue(queue->vif->dev,
> queue->id);
> > + netif_tx_wake_queue(txq);
> > + }
> > + }
> >
> > spin_unlock_irq(&queue->rx_queue.lock);
> >
> > return skb;
> > }
> >
> > -static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue) -
> {
> > - spin_lock_irq(&queue->rx_queue.lock);
> > -
> > - if (queue->rx_queue_len < queue->rx_queue_max) {
> > - struct net_device *dev = queue->vif->dev;
> > -
> > - netif_tx_wake_queue(netdev_get_tx_queue(dev, queue-
> >id));
> > - }
> > -
> > - spin_unlock_irq(&queue->rx_queue.lock);
> > -}
> > -
> > static void xenvif_rx_queue_purge(struct xenvif_queue *queue) {
> > struct sk_buff *skb;
> > @@ -585,8 +579,6 @@ int xenvif_kthread_guest_rx(void *data)
> > */
> > xenvif_rx_queue_drop_expired(queue);
> >
> > - xenvif_rx_queue_maybe_wake(queue);
> > -
> > cond_resched();
> > }
> >
> > --
> > 2.1.4
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 14:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
Allan.Nielsen-dzo6w/eZyo2tG0bUXCXiUA
In-Reply-To: <20161004125319.GK11677-g2DYL2Zd6BY@public.gmane.org>
Hi Andrew,
Thank you for review comments.
I accepted your review comment and change the code.
I resent for code review.
Thanks,
Raju.
On Tue, Oct 04, 2016 at 02:53:19PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
>
>
> > Regarding remove the -'s in table, PHY data sheet descript the
> > concept of edge rate with table. I would like to keep the same table
> > in driver.
>
> The double negative makes the code ugly. Plus a negative slowdown is a
> speed up! The kernel maintainability and sanity comes first, and if
> the data sheet is crazy, because it uses negative slows downs, it
> should be ignored. Get the data sheet fixed....
>
> Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 14:04 UTC (permalink / raw)
To: netdev, devicetree; +Cc: f.fainelli, Allan.Nielsen, andrew, Raju Lakkaraju
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Edge-rate:
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission
line reflections, false signal detection by the receiving device and
electromagnetic interference (EMI) -- all of which can negate the potential
gains designers are seeking when they try to increase system speeds through
the use of higher performance logic devices. The fact is, faster signaling
edge rates can cause a higher level of electrical noise or other type of
interference that can actually lead to slower line speeds and lower maximum
system frequencies. This parameter allow the board designers to change the
driving strange, and thereby change the EMI behavioral.
Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
Tested on Beaglebone Black with VSC 8531 PHY.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
---
All the review comments updated and resending for review.
Change set:
v1:
- Initial version of Edge-rate driver add by using IOCTL.
v2:
- Changed edge-rate parameter to Device Tree with magic number.
v3:
- Added Device Tree documentati0n and edge-rate parameter table.
Added probe function initialize the vsc8531 private data structure.
v4:
- As per review comment, Device Tree parameters (vddmac, edge-slowdown)
added.
v5:
- As per review comment, Device Tree Document parameters (vddmac,
edge-slowdown) real numbers added. Table number changed from 5 to 1.
v6:
- As per review comment, Removed Device Tree header file. Removed MACROs
and add ARRAYSIZE
v7:
- As per review comment, Removed '-'s (minus) sign in Edge rate table.
---
.../devicetree/bindings/net/mscc-phy-vsc8531.txt | 3 +-
drivers/net/phy/mscc.c | 43 ++++++++++++----------
include/dt-bindings/net/mscc-phy-vsc8531.h | 21 -----------
3 files changed, 26 insertions(+), 41 deletions(-)
delete mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 99c7eb0..241841c 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -18,7 +18,8 @@ Optional properties:
to reprogram drive strength and in effect slow
down the edge rate if desired. Table 1 shows the
impact to the edge rate per VDDMAC supply for each
- drive strength setting.
+ drive strength setting. VDDMAC supply voltage
+ should be one of the value in Table-1 first row.
Ref: Table:1 - Edge rate change below.
Note: see dt-bindings/net/mscc-phy-vsc8531.h for applicable values
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index a17573e..b40cf18c 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -12,7 +12,6 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/of.h>
-#include <dt-bindings/net/mscc-phy-vsc8531.h>
enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -56,16 +55,18 @@ enum rgmii_rx_clock_delay {
#define PHY_ID_VSC8531 0x00070570
#define PHY_ID_VSC8541 0x00070770
+#define MSCC_SLOWDOWN_MAX 8
+
struct edge_rate_table {
u16 vddmac;
- int slowdown[MSCC_SLOWDOWN_MAX];
+ u8 slowdown[MSCC_SLOWDOWN_MAX];
};
-struct edge_rate_table edge_table[MSCC_VDDMAC_MAX] = {
- {3300, { 0, -2, -4, -7, -10, -17, -29, -53} },
- {2500, { 0, -3, -6, -10, -14, -23, -37, -63} },
- {1800, { 0, -5, -9, -16, -23, -35, -52, -76} },
- {1500, { 0, -6, -14, -21, -29, -42, -58, -77} },
+static const struct edge_rate_table edge_table[] = {
+ {3300, { 0, 2, 4, 7, 10, 17, 29, 53} },
+ {2500, { 0, 3, 6, 10, 14, 23, 37, 63} },
+ {1800, { 0, 5, 9, 16, 23, 35, 52, 76} },
+ {1500, { 0, 6, 14, 21, 29, 42, 58, 77} },
};
struct vsc8531_private {
@@ -81,21 +82,26 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
return rc;
}
-static u8 edge_rate_magic_get(u16 vddmac,
- int slowdown)
+static u8 vsc85xx_edge_rate_magic_get(u16 vddmac,
+ u8 slowdown)
{
- int rc = (MSCC_SLOWDOWN_MAX - 1);
+ int rc = (ARRAY_SIZE(edge_table[0].slowdown) - 1);
u8 vdd;
u8 sd;
- for (vdd = 0; vdd < MSCC_VDDMAC_MAX; vdd++) {
+ for (vdd = 0; vdd < ARRAY_SIZE(edge_table); vdd++) {
if (edge_table[vdd].vddmac == vddmac) {
- for (sd = 0; sd < MSCC_SLOWDOWN_MAX; sd++) {
- if (edge_table[vdd].slowdown[sd] <= slowdown) {
- rc = (MSCC_SLOWDOWN_MAX - sd - 1);
+ for (sd = 0;
+ sd < ARRAY_SIZE(edge_table[0].slowdown);
+ sd++) {
+ if (edge_table[vdd].slowdown[sd] >= slowdown) {
+ rc = (ARRAY_SIZE(edge_table[0].slowdown)
+ - sd - 1);
break;
}
}
+ /* Max Slowdown Magic number should be zero */
+ rc = 0;
}
}
@@ -198,14 +204,13 @@ static int vsc8531_of_init(struct phy_device *phydev)
rc = of_property_read_u16(of_node, "vsc8531,vddmac",
&vsc8531->vddmac);
if (rc == -EINVAL)
- vsc8531->vddmac = MSCC_VDDMAC_3300;
+ vsc8531->vddmac = 3300;
rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown",
&vsc8531->edge_slowdown);
if (rc == -EINVAL)
vsc8531->edge_slowdown = 0;
- rc = 0;
- return rc;
+ return 0;
}
#else
static int vsc8531_of_init(struct phy_device *phydev)
@@ -232,8 +237,8 @@ static int vsc85xx_config_init(struct phy_device *phydev)
if (rc)
return rc;
- edge_rate = edge_rate_magic_get(vsc8531->vddmac,
- -(int)vsc8531->edge_slowdown);
+ edge_rate = vsc85xx_edge_rate_magic_get(vsc8531->vddmac,
+ vsc8531->edge_slowdown);
rc = vsc85xx_edge_rate_cntl_set(phydev, edge_rate);
if (rc)
return rc;
diff --git a/include/dt-bindings/net/mscc-phy-vsc8531.h b/include/dt-bindings/net/mscc-phy-vsc8531.h
deleted file mode 100644
index 2383dd2..0000000
--- a/include/dt-bindings/net/mscc-phy-vsc8531.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Device Tree constants for Microsemi VSC8531 PHY
- *
- * Author: Nagaraju Lakkaraju
- *
- * License: Dual MIT/GPL
- * Copyright (c) 2016 Microsemi Corporation
- */
-
-#ifndef _DT_BINDINGS_MSCC_VSC8531_H
-#define _DT_BINDINGS_MSCC_VSC8531_H
-
-/* MAC interface Edge rate control VDDMAC in milli Volts */
-#define MSCC_VDDMAC_3300 3300
-#define MSCC_VDDMAC_2500 2500
-#define MSCC_VDDMAC_1800 1800
-#define MSCC_VDDMAC_1500 1500
-#define MSCC_VDDMAC_MAX 4
-#define MSCC_SLOWDOWN_MAX 8
-
-#endif
--
2.7.4
^ permalink raw reply related
* RE: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature
From: Paul Durrant @ 2016-10-04 13:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, annie.li@oracle.com,
joao.m.martins@oracle.com
Cc: netdev@vger.kernel.org, xen-devel@lists.xenproject.org, Wei Liu
In-Reply-To: <20161004125205.GE30836@localhost.localdomain>
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: 04 October 2016 13:52
> To: Paul Durrant <Paul.Durrant@citrix.com>; annie.li@oracle.com;
> joao.m.martins@oracle.com
> Cc: netdev@vger.kernel.org; xen-devel@lists.xenproject.org; Wei Liu
> <wei.liu2@citrix.com>
> Subject: Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest
> rx side prefix GSO feature
>
> On Tue, Oct 04, 2016 at 10:29:13AM +0100, Paul Durrant wrote:
> > As far as I am aware only very old Windows network frontends make use
> > of this style of passing GSO packets from backend to frontend. These
> > frontends can easily be replaced by the freely available Xen Project
> > Windows PV network frontend, which uses the 'default' mechanism for
> > passing GSO packets, which is also used by all Linux frontends.
>
> It is not that simple. Some companies have extra juice in their Windows
> frontends so can't easily swap over to the Xen Project one.
Ok, then those frontends will continue to work, but they won't get GSO packets any more. Prefix GSO has never been specified in the canonical netif header and so has been in a limbo state forever so such frontends have always been on borrowed time and only just happened to work against a linux backend. If someone wants to actually specify prefix GSO properly then it could be added back in, but it should not be necessary now that the RX side req<->rsp identity relation is documented (http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=HEAD#l729).
>
> Either way CC-ing Annie
>
> Also would it make sense to CC the FreeBSD and NetBSD maintainers of their
> PV drivers just to make sure? (Or has that been confirmed)
>
I could do that, but I'd hope that they would be subscribed to xen-devel and will chime in if there's likely to be a problem.
> >
> > NOTE: Removal of this feature will not cause breakage in old Windows
> > frontends. They simply will no longer receive GSO packets - the
> > packets instead being fragmented in the backend.
>
> Did you also test this with SuSE/Novell Windows PV drivers?
>
No, I don't have copies of these. Internal XenServer testing has not shown up any issues with 'legacy' PV drivers though (which do still have the prefix GSO code in).
Paul
> Thanks.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > ---
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > ---
> > drivers/net/xen-netback/common.h | 1 -
> > drivers/net/xen-netback/interface.c | 4 ++--
> > drivers/net/xen-netback/rx.c | 26 --------------------------
> > drivers/net/xen-netback/xenbus.c | 21 ---------------------
> > 4 files changed, 2 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/common.h
> > b/drivers/net/xen-netback/common.h
> > index b38fb2c..0ba5910 100644
> > --- a/drivers/net/xen-netback/common.h
> > +++ b/drivers/net/xen-netback/common.h
> > @@ -260,7 +260,6 @@ struct xenvif {
> >
> > /* Frontend feature information. */
> > int gso_mask;
> > - int gso_prefix_mask;
> >
> > u8 can_sg:1;
> > u8 ip_csum:1;
> > diff --git a/drivers/net/xen-netback/interface.c
> > b/drivers/net/xen-netback/interface.c
> > index fb50c6d..211d542 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -319,9 +319,9 @@ static netdev_features_t
> > xenvif_fix_features(struct net_device *dev,
> >
> > if (!vif->can_sg)
> > features &= ~NETIF_F_SG;
> > - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
> > + if (~(vif->gso_mask) & GSO_BIT(TCPV4))
> > features &= ~NETIF_F_TSO;
> > - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
> > + if (~(vif->gso_mask) & GSO_BIT(TCPV6))
> > features &= ~NETIF_F_TSO6;
> > if (!vif->ip_csum)
> > features &= ~NETIF_F_IP_CSUM;
> > diff --git a/drivers/net/xen-netback/rx.c
> > b/drivers/net/xen-netback/rx.c index 03836aa..6bd7d6e 100644
> > --- a/drivers/net/xen-netback/rx.c
> > +++ b/drivers/net/xen-netback/rx.c
> > @@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> > gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> > }
> >
> > - /* Set up a GSO prefix descriptor, if necessary */
> > - if ((1 << gso_type) & vif->gso_prefix_mask) {
> > - RING_COPY_REQUEST(&queue->rx, queue->rx.req_cons++,
> &req);
> > - meta = npo->meta + npo->meta_prod++;
> > - meta->gso_type = gso_type;
> > - meta->gso_size = skb_shinfo(skb)->gso_size;
> > - meta->size = 0;
> > - meta->id = req.id;
> > - }
> > -
> > RING_COPY_REQUEST(&queue->rx, queue->rx.req_cons++, &req);
> > meta = npo->meta + npo->meta_prod++;
> >
> > @@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue
> *queue)
> > while ((skb = __skb_dequeue(&rxq)) != NULL) {
> > struct xen_netif_extra_info *extra = NULL;
> >
> > - if ((1 << queue->meta[npo.meta_cons].gso_type) &
> > - vif->gso_prefix_mask) {
> > - resp = RING_GET_RESPONSE(&queue->rx,
> > - queue->rx.rsp_prod_pvt++);
> > -
> > - resp->flags = XEN_NETRXF_gso_prefix |
> > - XEN_NETRXF_more_data;
> > -
> > - resp->offset = queue-
> >meta[npo.meta_cons].gso_size;
> > - resp->id = queue->meta[npo.meta_cons].id;
> > - resp->status = XENVIF_RX_CB(skb)-
> >meta_slots_used;
> > -
> > - npo.meta_cons++;
> > - XENVIF_RX_CB(skb)->meta_slots_used--;
> > - }
> > -
> > queue->stats.tx_bytes += skb->len;
> > queue->stats.tx_packets++;
> >
> > diff --git a/drivers/net/xen-netback/xenbus.c
> > b/drivers/net/xen-netback/xenbus.c
> > index daf4c78..7056404 100644
> > --- a/drivers/net/xen-netback/xenbus.c
> > +++ b/drivers/net/xen-netback/xenbus.c
> > @@ -1135,7 +1135,6 @@ static int read_xenbus_vif_flags(struct
> backend_info *be)
> > vif->can_sg = !!val;
> >
> > vif->gso_mask = 0;
> > - vif->gso_prefix_mask = 0;
> >
> > if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
> > "%d", &val) < 0)
> > @@ -1143,32 +1142,12 @@ static int read_xenbus_vif_flags(struct
> backend_info *be)
> > if (val)
> > vif->gso_mask |= GSO_BIT(TCPV4);
> >
> > - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4-
> prefix",
> > - "%d", &val) < 0)
> > - val = 0;
> > - if (val)
> > - vif->gso_prefix_mask |= GSO_BIT(TCPV4);
> > -
> > if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6",
> > "%d", &val) < 0)
> > val = 0;
> > if (val)
> > vif->gso_mask |= GSO_BIT(TCPV6);
> >
> > - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6-
> prefix",
> > - "%d", &val) < 0)
> > - val = 0;
> > - if (val)
> > - vif->gso_prefix_mask |= GSO_BIT(TCPV6);
> > -
> > - if (vif->gso_mask & vif->gso_prefix_mask) {
> > - xenbus_dev_fatal(dev, err,
> > - "%s: gso and gso prefix flags are not "
> > - "mutually exclusive",
> > - dev->otherend);
> > - return -EOPNOTSUPP;
> > - }
> > -
> > if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-no-csum-
> offload",
> > "%d", &val) < 0)
> > val = 0;
> > --
> > 2.1.4
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
^ permalink raw reply
* [net-next PATCH] drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay
From: Mugunthan V N @ 2016-10-04 13:37 UTC (permalink / raw)
To: netdev
Cc: Grygorii Strashko, linux-omap, Sekhar Nori, David S . Miller,
Mugunthan V N
Add support to enable CPSW RGMII internal delay (id mode) bits
when rgmii internal delay is configured in phy.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw-phy-sel.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index c3e85ac..054a8dd 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -30,6 +30,8 @@
#define AM33XX_GMII_SEL_RMII2_IO_CLK_EN BIT(7)
#define AM33XX_GMII_SEL_RMII1_IO_CLK_EN BIT(6)
+#define AM33XX_GMII_SEL_RGMII2_IDMODE BIT(5)
+#define AM33XX_GMII_SEL_RGMII1_IDMODE BIT(4)
#define GMII_SEL_MODE_MASK 0x3
@@ -48,6 +50,7 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv *priv,
u32 reg;
u32 mask;
u32 mode = 0;
+ bool rgmii_id = false;
reg = readl(priv->gmii_sel);
@@ -57,10 +60,14 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv *priv,
break;
case PHY_INTERFACE_MODE_RGMII:
+ mode = AM33XX_GMII_SEL_MODE_RGMII;
+ break;
+
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM33XX_GMII_SEL_MODE_RGMII;
+ rgmii_id = true;
break;
default:
@@ -83,6 +90,13 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv *priv,
mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
}
+ if (rgmii_id) {
+ if (slave == 0)
+ mode |= AM33XX_GMII_SEL_RGMII1_IDMODE;
+ else
+ mode |= AM33XX_GMII_SEL_RGMII2_IDMODE;
+ }
+
reg &= ~mask;
reg |= mode;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* Re: [PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Andrew Lunn @ 2016-10-04 13:14 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Tony Lindgren, Russell King, Florian Fainelli,
David Miller, Sekhar Nori
In-Reply-To: <20161004125607.10569-5-mugunthanvnm-l0cyMroinI0@public.gmane.org>
On Tue, Oct 04, 2016 at 06:26:07PM +0530, Mugunthan V N wrote:
> The current delay settings of the phy are not the optimal value,
> fix it with correct values.
This should be a separate patch, since it has nothing to do with impedance.
Andrew
>
> Signed-off-by: Mugunthan V N <mugunthanvnm-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index d626cd7..8472a8c 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -59,16 +59,16 @@
> &davinci_mdio {
> dp83867_0: ethernet-phy@2 {
> reg = <2>;
> - ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> - ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> ti,min-output-imepdance;
> };
>
> dp83867_1: ethernet-phy@3 {
> reg = <3>;
> - ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> - ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> ti,min-output-imepdance;
> };
> --
> 2.10.0.372.g6fe1b14
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Andrew Lunn @ 2016-10-04 13:11 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori
In-Reply-To: <20161004125607.10569-4-mugunthanvnm@ti.com>
On Tue, Oct 04, 2016 at 06:26:06PM +0530, Mugunthan V N wrote:
> The default impedance settings of the phy is not the optimal
> value, due to this the second ethernet is not working. Fix it
> with correct values which makes the second ethernet port to work.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index f9cfd3b..d626cd7 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -62,6 +62,7 @@
> ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> + ti,min-output-imepdance;
And there is my answer :-(
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Lokesh Vutla @ 2016-10-04 13:11 UTC (permalink / raw)
To: Mugunthan V N, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Tony Lindgren, Russell King, Florian Fainelli,
David Miller, Sekhar Nori
In-Reply-To: <20161004125607.10569-4-mugunthanvnm-l0cyMroinI0@public.gmane.org>
On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
> The default impedance settings of the phy is not the optimal
> value, due to this the second ethernet is not working. Fix it
> with correct values which makes the second ethernet port to work.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm-l0cyMroinI0@public.gmane.org>
> ---
> arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index f9cfd3b..d626cd7 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -62,6 +62,7 @@
> ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> + ti,min-output-imepdance;
s/imepdance/impedance
> };
>
> dp83867_1: ethernet-phy@3 {
> @@ -69,5 +70,6 @@
> ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
> ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
> + ti,min-output-imepdance;
same here.
Thanks and regards,
Lokesh
> };
> };
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Andrew Lunn @ 2016-10-04 13:10 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori
In-Reply-To: <20161004125607.10569-3-mugunthanvnm@ti.com>
> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
Did you really test this? Or did you make the same typos in your device
tree file?
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Lokesh Vutla @ 2016-10-04 13:10 UTC (permalink / raw)
To: Mugunthan V N, netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori
In-Reply-To: <20161004125607.10569-3-mugunthanvnm@ti.com>
On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
> Add support for programmable MAC impedance configuration
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 91177a4..795ae17 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -33,6 +33,7 @@
> /* Extended Registers */
> #define DP83867_RGMIICTL 0x0032
> #define DP83867_RGMIIDCTL 0x0086
> +#define DP83867_IO_MUX_CFG 0x0170
>
> #define DP83867_SW_RESET BIT(15)
> #define DP83867_SW_RESTART BIT(14)
> @@ -62,10 +63,17 @@
> /* RGMIIDCTL bits */
> #define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
>
> +/* IO_MUX_CFG bits */
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
> +
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
> +
> struct dp83867_private {
> int rx_id_delay;
> int tx_id_delay;
> int fifo_depth;
> + int io_impedance;
> };
>
> static int dp83867_ack_interrupt(struct phy_device *phydev)
> @@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
> if (!of_node)
> return -ENODEV;
>
> + dp83867->io_impedance = -EINVAL;
> +
> + /* Optional configuration */
> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
s/imepdance/impedance
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
s/imepdance/impedance
Thanks and regards,
Lokesh
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
> +
> ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
> &dp83867->rx_id_delay);
> if (ret)
> @@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
>
> phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
> DP83867_DEVADDR, delay);
> +
> + if (dp83867->io_impedance >= 0) {
> + val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR);
> +
> + val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
> + val |= dp83867->io_impedance &
> + DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
> +
> + phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR, val);
> + }
> }
>
> return 0;
>
^ permalink raw reply
* [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..795ae17 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH][V2] net: hns: Add missing \n to end of dev_err messages, tidy up text
From: Colin King @ 2016-10-04 12:57 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta, David S . Miller, Kejian Yan,
Daode Huang, lipeng, Lisheng, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trival fix, dev_err messages are missing a \n, so add it. Also
fix grammer, spelling mistake and add white spaces to various
error messages.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..751c126 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -126,7 +126,7 @@ void hns_mac_adjust_link(struct hns_mac_cb *mac_cb, int speed, int duplex)
(enum mac_speed)speed, duplex);
if (ret) {
dev_err(mac_cb->dev,
- "adjust_link failed,%s mac%d ret = %#x!\n",
+ "adjust_link failed, %s mac%d ret = %#x!\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, ret);
return;
@@ -149,7 +149,7 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb *mac_cb,
if (mac_cb->dsaf_dev->dsaf_mode <= DSAF_MODE_ENABLE) {
if (mac_cb->mac_id != DSAF_MAX_PORT_NUM) {
dev_err(mac_cb->dev,
- "input invalid,%s mac%d vmid%d !\n",
+ "input invalid, %s mac%d vmid%d !\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, vmid);
return -EINVAL;
@@ -157,19 +157,19 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb *mac_cb,
} else if (mac_cb->dsaf_dev->dsaf_mode < DSAF_MODE_MAX) {
if (mac_cb->mac_id >= DSAF_MAX_PORT_NUM) {
dev_err(mac_cb->dev,
- "input invalid,%s mac%d vmid%d!\n",
+ "input invalid, %s mac%d vmid%d!\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, vmid);
return -EINVAL;
}
} else {
- dev_err(mac_cb->dev, "dsaf mode invalid,%s mac%d!\n",
+ dev_err(mac_cb->dev, "dsaf mode invalid, %s mac%d!\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id);
return -EINVAL;
}
if (vmid >= mac_cb->dsaf_dev->rcb_common[0]->max_vfn) {
- dev_err(mac_cb->dev, "input invalid,%s mac%d vmid%d !\n",
+ dev_err(mac_cb->dev, "input invalid, %s mac%d vmid%d !\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id, vmid);
return -EINVAL;
}
@@ -196,7 +196,7 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb *mac_cb,
tmp_port = vmid;
break;
default:
- dev_err(mac_cb->dev, "dsaf mode invalid,%s mac%d!\n",
+ dev_err(mac_cb->dev, "dsaf mode invalid, %s mac%d!\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id);
return -EINVAL;
}
@@ -275,7 +275,7 @@ int hns_mac_set_multi(struct hns_mac_cb *mac_cb,
ret = hns_dsaf_add_mac_mc_port(dsaf_dev, &mac_entry);
if (ret) {
dev_err(dsaf_dev->dev,
- "set mac mc port failed,%s mac%d ret = %#x!\n",
+ "set mac mc port failed, %s mac%d ret = %#x!\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, ret);
return ret;
@@ -305,7 +305,7 @@ int hns_mac_del_mac(struct hns_mac_cb *mac_cb, u32 vfn, char *mac)
old_mac = &mac_cb->addr_entry_idx[vfn];
} else {
dev_err(mac_cb->dev,
- "vf queue is too large,%s mac%d queue = %#x!\n",
+ "vf queue is too large, %s mac%d queue = %#x!\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id, vfn);
return -EINVAL;
}
@@ -547,7 +547,7 @@ int hns_mac_set_autoneg(struct hns_mac_cb *mac_cb, u8 enable)
struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
if (mac_cb->phy_if == PHY_INTERFACE_MODE_XGMII && enable) {
- dev_err(mac_cb->dev, "enable autoneg is not allowed!");
+ dev_err(mac_cb->dev, "enabling autoneg is not allowed!\n");
return -ENOTSUPP;
}
@@ -571,7 +571,7 @@ int hns_mac_set_pauseparam(struct hns_mac_cb *mac_cb, u32 rx_en, u32 tx_en)
if (mac_cb->mac_type == HNAE_PORT_DEBUG) {
if (is_ver1 && (tx_en || rx_en)) {
- dev_err(mac_cb->dev, "macv1 cann't enable tx/rx_pause!");
+ dev_err(mac_cb->dev, "macv1 can't enable tx/rx_pause!\n");
return -EINVAL;
}
}
@@ -941,7 +941,7 @@ int hns_mac_get_cfg(struct dsaf_device *dsaf_dev, struct hns_mac_cb *mac_cb)
ret = hns_mac_get_mode(mac_cb->phy_if);
if (ret < 0) {
dev_err(dsaf_dev->dev,
- "hns_mac_get_mode failed,mac%d ret = %#x!\n",
+ "hns_mac_get_mode failed, mac%d ret = %#x!\n",
mac_cb->mac_id, ret);
return ret;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index d626cd7..8472a8c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
dp83867_1: ethernet-phy@3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox