* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 14:01 UTC (permalink / raw)
To: Corentin Labbe
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> Hello
>
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
>
> This driver is the continuation of the sun8i-emac driver.
> During the development, it appeared that in fact the hardware was a modified
> version of some dwmac.
> So the driver is now written as a glue driver for stmmac.
>
> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> It can use an internal PHY (MII 10/100) or an external PHY
> via RGMII/RMII.
Hi Corentin
Sorry if this has been asked before....
Does the internal PHY have a phy driver? It seems like
tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
should be in the phy driver, if it has one.
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
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: carl h @ 2017-05-01 14:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <CABM+yxkwQ1Oiw9p0tehLYyNgh6Qj=+1KKNk4hy35vz00DveyGA@mail.gmail.com>
I can't seem to get any response to this.
If there is a better place to get help for this question please let me know.
Note: I have already posted the same question in Linux&Users and
StackOverflow without luck either.
On Fri, Apr 28, 2017 at 9:46 AM, carl h <heyen2000@gmail.com> wrote:
> Desperately need info on this.
>
> I'm trying to implement vlans on a target programmatically.
>
> But first I wanted to set up vlans manually to help get a better
> understanding of vlan setup. So I setup a vlan manually on my
> development system (ubuntu) using the vconfig/ifconfig command
> combination, but using the same command combination on the intended
> target doesn't work.
>
> Both systems use the same 8021q driver so the method of informing the
> lower level Ethernet driver of the vlan info should be the same (I
> would think). After looking at the vlan driver source it appears that
> it collects the vlan info and adds the info the sk_buff structure
> which is eventually passed to the ethernet driver, but it's not
> obvious where the vlan magic is suppose to happen (ethernet driver or
> 8021q driver).
>
> I looked at the source for the target system’s ethernet driver and it
> supports an ioctl method of setting up a vlan. But this does not seem
> like the conventional way that Linux sets up a vlan in the ethernet
> driver.
>
> By what mechanism does the vlan driver (8021q.ko) tell the Ethernet
> hardware about a vlan?
>
> Is it a special api call to the ethernet driver to set up a vlan in
> hardware, or should the vlan driver be adding the vlan tags to the
> packet?
>
> Any info on vlan implementation would also be helpful too.
^ permalink raw reply
* RE: [PATCH v4 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: Woojung.Huh @ 2017-05-01 14:23 UTC (permalink / raw)
To: andrew, David.Cai; +Cc: netdev, davem, UNGLinuxDriver, steve.glendinning
In-Reply-To: <20170429015855.GA32471@lunn.ch>
> Isn't this now pointless? If it is not used anywhere, you should not
> add it.
>
Andrew,
David is going to submit another patch.
(He already sent discard request email right after v4 patch.)
- Woojung
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Chen-Yu Tsai @ 2017-05-01 14:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Corentin Labbe, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20170501140133.GD31281@lunn.ch>
On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
>> Hello
>>
>> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> present on Allwinner H3/H5/A83T/A64 SoCs.
>>
>> This driver is the continuation of the sun8i-emac driver.
>> During the development, it appeared that in fact the hardware was a modified
>> version of some dwmac.
>> So the driver is now written as a glue driver for stmmac.
>>
>> It supports 10/100/1000 Mbit/s speed with half/full duplex.
>> It can use an internal PHY (MII 10/100) or an external PHY
>> via RGMII/RMII.
>
> Hi Corentin
>
> Sorry if this has been asked before....
>
> Does the internal PHY have a phy driver? It seems like
> tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> should be in the phy driver, if it has one.
Nope. These affect the delay lines for the external PHY interface.
These have existed since the A20, when the GMAC hardware block and
glue layer controls were introduced.
ChenYu
^ permalink raw reply
* Re: [PATCH net-next 4/4] virtio_net: make use of extended ack message reporting
From: David Miller @ 2017-05-01 14:34 UTC (permalink / raw)
To: daniel
Cc: jakub.kicinski, netdev, johannes, dsa, alexei.starovoitov,
bblanco, john.fastabend, kubakici, oss-drivers, brouer, jhs
In-Reply-To: <5907130F.7070807@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 01 May 2017 12:50:55 +0200
> On 05/01/2017 06:46 AM, Jakub Kicinski wrote:
>> Try to carry error messages to the user via the netlink extended
>> ack message attribute.
>>
>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> [...]
>> @@ -1890,16 +1891,17 @@ static int virtnet_xdp_set(struct net_device
>> *dev, struct bpf_prog *prog)
>> virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6) ||
>> virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_ECN) ||
>> virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_UFO)) {
>> - netdev_warn(dev, "can't set XDP while host is implementing LRO, disable
>> - LRO first\n");
>> + NL_SET_ERR_MSG(extack, "can't set XDP while host is implementing
>> LRO, disable LRO first");
>
> Should this be NL_MOD_TRY_SET_ERR_MSG() as well like in nfp case
> (otherwise the 'if (_extack)' check might be missing from the
> macro)?
I don't see a path in the doit callchain for setlink/newlink where the
extack pointer can be null.
I'm going to apply this series and we should either:
1) Guarantee the extack object is always available.
or
2) Make all macros including NL_SET_ERR_MSG() check the
pointer.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] xdp: use netlink extended ACK reporting
From: David Miller @ 2017-05-01 14:36 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, johannes, dsa, daniel, alexei.starovoitov, bblanco,
john.fastabend, kubakici, oss-drivers, brouer, jhs
In-Reply-To: <20170501044648.13022-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Sun, 30 Apr 2017 21:46:44 -0700
> This series is an attempt to make XDP more user friendly by
> enabling exploiting the recently added netlink extended ACK
> reporting to carry messages to user space.
>
> David Ahern's iproute2 ext ack patches for ip link are sufficient
> to show the errors like this:
>
> # ip link set dev p4p1 xdp obj ipip_prepend.o sec ".text"
> Error: nfp: MTU too large w/ XDP enabled
>
> Where the message is coming directly from the driver. There could
> still be a bit of a leap for a complete novice from the message
> above to the right settings, but it's a big improvement over the
> standard "Invalid argument" message.
>
> v1/non-rfc:
> - add a separate macro in patch 1;
> - add KBUILD_MODNAME as part of the message (Daniel);
> - don't print the error to logs in patch 1.
Series applied.
^ permalink raw reply
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: Andrew Lunn @ 2017-05-01 14:37 UTC (permalink / raw)
To: carl h; +Cc: netdev
In-Reply-To: <CABM+yxkiOpOs5b5MM6MD4woz5R2-4_gf=t=8THXb3p=wuwTtXg@mail.gmail.com>
> > By what mechanism does the vlan driver (8021q.ko) tell the Ethernet
> > hardware about a vlan?
Why would the Ethernet hardware need to know?
An Ethernet Switch might need to know. If so, then switchdev would be
used, include/net/switchdev.h
Andrew
^ permalink raw reply
* Re: [net-next PATCH 0/2] samples/bpf: two bug fixes to XDP_FLAGS_SKB_MODE attaching
From: David Miller @ 2017-05-01 14:42 UTC (permalink / raw)
To: brouer; +Cc: dsa, netdev, borkmann, alexei.starovoitov
In-Reply-To: <149363073213.17600.4480290736818479957.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 01 May 2017 11:26:10 +0200
> Two small bugfixes for:
> commit 3993f2cb983b ("samples/bpf: Add support for SKB_MODE to xdp1 and xdp_tx_iptunnel")
Series applied.
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 14:45 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Corentin Labbe, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <CAGb2v67qGqswdz_JcDaD5jTkcvtBuzqqP8KZh=S_5pkp=o6cUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> >> Hello
> >>
> >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> >> present on Allwinner H3/H5/A83T/A64 SoCs.
> >>
> >> This driver is the continuation of the sun8i-emac driver.
> >> During the development, it appeared that in fact the hardware was a modified
> >> version of some dwmac.
> >> So the driver is now written as a glue driver for stmmac.
> >>
> >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> >> It can use an internal PHY (MII 10/100) or an external PHY
> >> via RGMII/RMII.
> >
> > Hi Corentin
> >
> > Sorry if this has been asked before....
> >
> > Does the internal PHY have a phy driver? It seems like
> > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > should be in the phy driver, if it has one.
>
> Nope. These affect the delay lines for the external PHY interface.
Oh, yes. I understood the patch wrong.
None of the patches actually use these properties. Are they actually
needed? We should avoid adding vendor specific properties, if they are
not used.
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
* Re: [PATCH 00/53] Netfilter/IPVS updates for net-next
From: David Miller @ 2017-05-01 14:47 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1493635640-24325-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 1 May 2017 12:46:27 +0200
> The following patchset contains Netfilter updates for your net-next
> tree. A large bunch of code cleanups, XXX they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH 00/53] Netfilter/IPVS updates for net-next
From: David Miller @ 2017-05-01 14:48 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20170501105353.GA24620@salvia>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 1 May 2017 12:53:53 +0200
> On Mon, May 01, 2017 at 12:46:27PM +0200, Pablo Neira Ayuso wrote:
>> Hi David,
>>
>> The following patchset contains Netfilter updates for your net-next
>> tree. A large bunch of code cleanups, XXX they are:
>
> Oh well, it case you can amend XXX thing there, David. This should be
> instead...
Fixed.
^ permalink raw reply
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: carl h @ 2017-05-01 14:52 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20170501143703.GA1285@lunn.ch>
The Ethernet hardware *is* a 2 port switch in a phone which does support
vlan tag insertion in the switch and driver. The driver is third party which
I'm trying to get working with vlans.
But i can't see how the vlan info propagates down to the switch driver.
On Mon, May 1, 2017 at 10:37 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > By what mechanism does the vlan driver (8021q.ko) tell the Ethernet
>> > hardware about a vlan?
>
> Why would the Ethernet hardware need to know?
>
> An Ethernet Switch might need to know. If so, then switchdev would be
> used, include/net/switchdev.h
>
> Andrew
^ permalink raw reply
* [PATCH] net: dsa: mv88e6xxx: fix mdio bus name when using devicetree
From: Sylvain Lemieux @ 2017-05-01 14:54 UTC (permalink / raw)
To: andrew, vivien.didelot; +Cc: netdev
From: Liam Beguin <lbeguin@tycoint.com>
mv88e6xxx_mdio_register automatically generates mdio buses for each switch
discovered in the devicetree. When switch nodes are embedded in other nodes,
this can cause sysfs naming collisions since full_name may be truncated.
Only use devicetree node name instead of the full devicetree path
as the mdio bus name.
Signed-off-by: Liam Beguin <lbeguin@tycoint.com>
Signed-off-by: Alexandre Messier <amessier@tycoint.com>
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 3354f99df378..80b4387d573e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2688,8 +2688,8 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip *chip,
mdio_bus->external = external;
if (np) {
- bus->name = np->full_name;
- snprintf(bus->id, MII_BUS_ID_SIZE, "%s", np->full_name);
+ bus->name = np->name;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", np->name);
} else {
bus->name = "mv88e6xxx SMI";
snprintf(bus->id, MII_BUS_ID_SIZE, "mv88e6xxx-%d", index++);
--
2.11.0
^ permalink raw reply related
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: David Miller @ 2017-05-01 14:57 UTC (permalink / raw)
To: heyen2000; +Cc: andrew, netdev
In-Reply-To: <CABM+yxmdJD2k1kA+fY9Yva24oB8BuDDhS-FQdY2EJM1ghf6xWw@mail.gmail.com>
From: carl h <heyen2000@gmail.com>
Date: Mon, 1 May 2017 10:52:17 -0400
> But i can't see how the vlan info propagates down to the switch driver.
Which "VLAN info" are you talking about?
The VLANs configured onto the device itself or the per-packet VLAN
info.
Per-device VLAN configuration is communicated to the netdev driver
via netdev_ops->ndo_vlan_{add,kill}_vid().
Per-packet VLAN information is stored in skb->vlan_{proto,tci}.
^ permalink raw reply
* Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-05-01 15:15 UTC (permalink / raw)
To: David Miller
Cc: mark.rutland, andrew, f.fainelli, sbranden, vivien.didelot,
jonmason, netdev, linux-kernel, devicetree, robh+dt,
bcm-kernel-feedback-list, rjui, linux-arm-kernel
In-Reply-To: <20170430.224852.172293736555378453.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 850 bytes --]
David Miller <davem@davemloft.net> writes:
> From: Eric Anholt <eric@anholt.net>
> Date: Fri, 28 Apr 2017 15:22:03 -0700
>
>> Cygnus is a small family of SoCs, of which we currently have
>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>> same as 58xx, just requiring a tiny bit of setup that was previously
>> missing.
>>
>> v2: Reorder the entry in the docs (suggestion by Scott Branden), add
>> missing '"'
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> The second patch with the DTS file update doesn't apply cleanly
> at all to net-next.
>
> So I'm dropping this series.
DTS updates go through arm-soc branches through Florian. The first
patch is the one I would like you to apply.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum_router: Simplify VRF enslavement
From: Ido Schimmel @ 2017-05-01 15:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jiri, mlxsw
In-Reply-To: <20170430.230448.383130211524258207.davem@davemloft.net>
On Sun, Apr 30, 2017 at 11:04:48PM -0400, David Miller wrote:
> Applied, thanks.
I see net-next was updated ~25 minutes ago, yet I don't see the patch
there. Can you please check it's actually applied?
Thanks
^ permalink raw reply
* Re: How does vlan driver pass vlan info to the h/w ethernet driver
From: Andrew Lunn @ 2017-05-01 15:02 UTC (permalink / raw)
To: carl h; +Cc: netdev
In-Reply-To: <CABM+yxmdJD2k1kA+fY9Yva24oB8BuDDhS-FQdY2EJM1ghf6xWw@mail.gmail.com>
On Mon, May 01, 2017 at 10:52:17AM -0400, carl h wrote:
> The Ethernet hardware *is* a 2 port switch in a phone which does support
> vlan tag insertion in the switch and driver. The driver is third party which
> I'm trying to get working with vlans.
> But i can't see how the vlan info propagates down to the switch driver.
How are you adding the vlan?
bridge vlan add dev port0 vid 42 self
That should call __vlan_add(), which calls __vlan_vid_add() which uses
switchdev to push the VLAN down into the hardware.
Andrew
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: fix mdio bus name when using devicetree
From: Andrew Lunn @ 2017-05-01 15:20 UTC (permalink / raw)
To: Sylvain Lemieux; +Cc: vivien.didelot, netdev
In-Reply-To: <20170501145404.18581-1-slemieux.tyco@gmail.com>
On Mon, May 01, 2017 at 10:54:04AM -0400, Sylvain Lemieux wrote:
> From: Liam Beguin <lbeguin@tycoint.com>
>
> mv88e6xxx_mdio_register automatically generates mdio buses for each switch
> discovered in the devicetree. When switch nodes are embedded in other nodes,
> this can cause sysfs naming collisions since full_name may be truncated.
>
> Only use devicetree node name instead of the full devicetree path
> as the mdio bus name.
Hi Sylvain
I'm not sure this is a good idea. It probably breaks my boards:
:/sys/class/mdio_bus# ls
!mdio-mux!mdio@1!switch@0!mdio 0.1 0.4 400d0000.ethernet-1 fixed-0
!mdio-mux!mdio@2!switch@0!mdio 0.2 0.8 400d1000.ethernet-2 mv88e6xxx-0
np->name is not unique, where as np->full_name is unique.
However, i can understand your problem with truncation. Maybe a better
solution is to detect if truncation is going to happen. If so, use a
concatenation of a hash of np->full_name, and the right hand part of
np->full_name?
Andrew
^ permalink raw reply
* [PATCH v5 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: David.Cai @ 2017-05-01 15:46 UTC (permalink / raw)
To: netdev, davem; +Cc: UNGLinuxDriver, steve.glendinning
From: David Cai <david.cai@microchip.com>
Adding support for Microchip LAN9250 Ethernet controller.
Signed-off-by: David Cai <david.cai@microchip.com>
---
Changes
V2
- email format changed
- remove unnecessary text in commit log Changes
V3
- defined all supported Ethernet controller chip ID.
V4
- changed 'if (pdata->generation == 4 && pdata->sub_generation)' to
'if ((pdata->idrev & 0xFFFF0000) == LAN9250)' for more readable
V5
- removed the variable 'sub_generation'.
drivers/net/ethernet/smsc/smsc911x.c | 49 ++++++++++++++++++++++--------------
drivers/net/ethernet/smsc/smsc911x.h | 19 ++++++++++++++
2 files changed, 49 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index fa5ca09..ea1bbc3 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -25,7 +25,7 @@
* LAN9215, LAN9216, LAN9217, LAN9218
* LAN9210, LAN9211
* LAN9220, LAN9221
- * LAN89218
+ * LAN89218,LAN9250
*
*/
@@ -1450,6 +1450,8 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
unsigned int timeout;
unsigned int temp;
int ret;
+ unsigned int reset_offset = HW_CFG;
+ unsigned int reset_mask = HW_CFG_SRST_;
/*
* Make sure to power-up the PHY chip before doing a reset, otherwise @@ -1476,15 +1478,23 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
}
}
+ if ((pdata->idrev & 0xFFFF0000) == LAN9250) {
+ /* special reset for LAN9250 */
+ reset_offset = RESET_CTL;
+ reset_mask = RESET_CTL_DIGITAL_RST_;
+ }
+
/* Reset the LAN911x */
- smsc911x_reg_write(pdata, HW_CFG, HW_CFG_SRST_);
+ smsc911x_reg_write(pdata, reset_offset, reset_mask);
+
+ /* verify reset bit is cleared */
timeout = 10;
do {
udelay(10);
- temp = smsc911x_reg_read(pdata, HW_CFG);
- } while ((--timeout) && (temp & HW_CFG_SRST_));
+ temp = smsc911x_reg_read(pdata, reset_offset);
+ } while ((--timeout) && (temp & reset_mask));
- if (unlikely(temp & HW_CFG_SRST_)) {
+ if (unlikely(temp & reset_mask)) {
SMSC_WARN(pdata, drv, "Failed to complete reset");
return -EIO;
}
@@ -2253,28 +2263,29 @@ static int smsc911x_init(struct net_device *dev)
pdata->idrev = smsc911x_reg_read(pdata, ID_REV);
switch (pdata->idrev & 0xFFFF0000) {
- case 0x01180000:
- case 0x01170000:
- case 0x01160000:
- case 0x01150000:
- case 0x218A0000:
+ case LAN9118:
+ case LAN9117:
+ case LAN9116:
+ case LAN9115:
+ case LAN89218:
/* LAN911[5678] family */
pdata->generation = pdata->idrev & 0x0000FFFF;
break;
- case 0x118A0000:
- case 0x117A0000:
- case 0x116A0000:
- case 0x115A0000:
+ case LAN9218:
+ case LAN9217:
+ case LAN9216:
+ case LAN9215:
/* LAN921[5678] family */
pdata->generation = 3;
break;
- case 0x92100000:
- case 0x92110000:
- case 0x92200000:
- case 0x92210000:
- /* LAN9210/LAN9211/LAN9220/LAN9221 */
+ case LAN9210:
+ case LAN9211:
+ case LAN9220:
+ case LAN9221:
+ case LAN9250:
+ /* LAN9210/LAN9211/LAN9220/LAN9221/LAN9250 */
pdata->generation = 4;
break;
diff --git a/drivers/net/ethernet/smsc/smsc911x.h b/drivers/net/ethernet/smsc/smsc911x.h
index 54d6489..8d75508 100644
--- a/drivers/net/ethernet/smsc/smsc911x.h
+++ b/drivers/net/ethernet/smsc/smsc911x.h
@@ -20,6 +20,22 @@
#ifndef __SMSC911X_H__
#define __SMSC911X_H__
+/*Chip ID*/
+#define LAN9115 0x01150000
+#define LAN9116 0x01160000
+#define LAN9117 0x01170000
+#define LAN9118 0x01180000
+#define LAN9215 0x115A0000
+#define LAN9216 0x116A0000
+#define LAN9217 0x117A0000
+#define LAN9218 0x118A0000
+#define LAN9210 0x92100000
+#define LAN9211 0x92110000
+#define LAN9220 0x92200000
+#define LAN9221 0x92210000
+#define LAN9250 0x92500000
+#define LAN89218 0x218A0000
+
#define TX_FIFO_LOW_THRESHOLD ((u32)1600)
#define SMSC911X_EEPROM_SIZE ((u32)128)
#define USE_DEBUG 0
@@ -303,6 +319,9 @@
#define E2P_DATA_EEPROM_DATA_ 0x000000FF
#define LAN_REGISTER_EXTENT 0x00000100
+#define RESET_CTL 0x1F8
+#define RESET_CTL_DIGITAL_RST_ 0x00000001
+
/*
* MAC Control and Status Register (Indirect Address)
* Offset (through the MAC_CSR CMD and DATA port)
^ permalink raw reply related
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: Vivien Didelot @ 2017-05-01 15:51 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn
In-Reply-To: <20170426155336.5937-1-vivien.didelot@savoirfairelinux.com>
Hi David,
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> Vivien Didelot (18):
> net: dsa: mv88e6xxx: add max VID to info
> net: dsa: mv88e6xxx: split VTU entry data member
> net: dsa: mv88e6xxx: move VTU Operation accessors
> net: dsa: mv88e6xxx: move VTU flush
> net: dsa: mv88e6xxx: move VTU FID accessors
> net: dsa: mv88e6xxx: move VTU SID accessors
> net: dsa: mv88e6xxx: move VTU VID accessors
> net: dsa: mv88e6xxx: move generic VTU GetNext
> net: dsa: mv88e6xxx: move VTU Data accessors
> net: dsa: mv88e6xxx: move STU GetNext operation
> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
> net: dsa: mv88e6xxx: load STU entry with VTU entry
> net: dsa: mv88e6xxx: add VTU GetNext operation
> net: dsa: mv88e6xxx: add VTU Load/Purge operation
> net: dsa: mv88e6xxx: make VTU helpers static
> net: dsa: mv88e6xxx: simplify VTU entry getter
> net: dsa: mv88e6xxx: support the VTU Page bit
> net: dsa: mv88e6xxx: add VTU support for 88E6390
>
> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
> 5 files changed, 684 insertions(+), 435 deletions(-)
> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
I don't see the patchset in net-next. Can you pick it?
Thanks,
Vivien
^ permalink raw reply
* [PATCH] switchdev: documentation: fix whitespace issues
From: Sylvain Lemieux @ 2017-05-01 15:02 UTC (permalink / raw)
To: jiri, ivecera; +Cc: netdev
From: Liam Beguin <lbeguin@tycoint.com>
Figure 1 is full of whitespaces; fix it
Signed-off-by: Liam Beguin <lbeguin@tycoint.com>
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Documentation/networking/switchdev.txt | 70 +++++++++++++++++-----------------
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
index 2bbac05ab9e2..3e7b946dea27 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -13,43 +13,43 @@ an example setup using a data-center-class switch ASIC chip. Other setups
with SR-IOV or soft switches, such as OVS, are possible.
- User-space tools
-
- user space |
- +-------------------------------------------------------------------+
- kernel | Netlink
- |
- +--------------+-------------------------------+
- | Network stack |
- | (Linux) |
- | |
- +----------------------------------------------+
-
+ User-space tools
+
+ user space |
+ +-------------------------------------------------------------------+
+ kernel | Netlink
+ |
+ +--------------+-------------------------------+
+ | Network stack |
+ | (Linux) |
+ | |
+ +----------------------------------------------+
+
sw1p2 sw1p4 sw1p6
- sw1p1 + sw1p3 + sw1p5 + eth1
- + | + | + | +
- | | | | | | |
- +--+----+----+----+-+--+----+---+ +-----+-----+
- | Switch driver | | mgmt |
- | (this document) | | driver |
- | | | |
- +--------------+----------------+ +-----------+
- |
- kernel | HW bus (eg PCI)
- +-------------------------------------------------------------------+
- hardware |
- +--------------+---+------------+
- | Switch device (sw1) |
- | +----+ +--------+
- | | v offloaded data path | mgmt port
- | | | |
- +--|----|----+----+----+----+---+
- | | | | | |
- + + + + + +
+ sw1p1 + sw1p3 + sw1p5 + eth1
+ + | + | + | +
+ | | | | | | |
+ +--+----+----+----+-+--+----+---+ +-----+-----+
+ | Switch driver | | mgmt |
+ | (this document) | | driver |
+ | | | |
+ +--------------+----------------+ +-----------+
+ |
+ kernel | HW bus (eg PCI)
+ +-------------------------------------------------------------------+
+ hardware |
+ +--------------+---+------------+
+ | Switch device (sw1) |
+ | +----+ +--------+
+ | | v offloaded data path | mgmt port
+ | | | |
+ +--|----|----+----+----+----+---+
+ | | | | | |
+ + + + + + +
p1 p2 p3 p4 p5 p6
-
- front-panel ports
-
+
+ front-panel ports
+
Fig 1.
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-05-01 15:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20170501144541.GB1285@lunn.ch>
On Mon, May 01, 2017 at 04:45:41PM +0200, Andrew Lunn wrote:
> On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> > On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> > >> Hello
> > >>
> > >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> present on Allwinner H3/H5/A83T/A64 SoCs.
> > >>
> > >> This driver is the continuation of the sun8i-emac driver.
> > >> During the development, it appeared that in fact the hardware was a modified
> > >> version of some dwmac.
> > >> So the driver is now written as a glue driver for stmmac.
> > >>
> > >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> > >> It can use an internal PHY (MII 10/100) or an external PHY
> > >> via RGMII/RMII.
> > >
> > > Hi Corentin
> > >
> > > Sorry if this has been asked before....
> > >
> > > Does the internal PHY have a phy driver? It seems like
> > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > should be in the phy driver, if it has one.
> >
> > Nope. These affect the delay lines for the external PHY interface.
I will add some sentences in the documentation to be more clear about that.
>
> Oh, yes. I understood the patch wrong.
>
> None of the patches actually use these properties. Are they actually
> needed? We should avoid adding vendor specific properties, if they are
> not used.
>
The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
So theses properties is already used out of tree, and will be used in tree soon.
Regards
^ permalink raw reply
* Re: [PATCH net-next 00/18] net: dsa: mv88e6xxx: 802.1s and 88E6390 VTU
From: David Miller @ 2017-05-01 16:08 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <871ss8bmom.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 01 May 2017 11:51:05 -0400
> Hi David,
>
> Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
>
>> Vivien Didelot (18):
>> net: dsa: mv88e6xxx: add max VID to info
>> net: dsa: mv88e6xxx: split VTU entry data member
>> net: dsa: mv88e6xxx: move VTU Operation accessors
>> net: dsa: mv88e6xxx: move VTU flush
>> net: dsa: mv88e6xxx: move VTU FID accessors
>> net: dsa: mv88e6xxx: move VTU SID accessors
>> net: dsa: mv88e6xxx: move VTU VID accessors
>> net: dsa: mv88e6xxx: move generic VTU GetNext
>> net: dsa: mv88e6xxx: move VTU Data accessors
>> net: dsa: mv88e6xxx: move STU GetNext operation
>> net: dsa: mv88e6xxx: get STU entry on VTU GetNext
>> net: dsa: mv88e6xxx: load STU entry with VTU entry
>> net: dsa: mv88e6xxx: add VTU GetNext operation
>> net: dsa: mv88e6xxx: add VTU Load/Purge operation
>> net: dsa: mv88e6xxx: make VTU helpers static
>> net: dsa: mv88e6xxx: simplify VTU entry getter
>> net: dsa: mv88e6xxx: support the VTU Page bit
>> net: dsa: mv88e6xxx: add VTU support for 88E6390
>>
>> drivers/net/dsa/mv88e6xxx/Makefile | 1 +
>> drivers/net/dsa/mv88e6xxx/chip.c | 568 +++++++++-----------------------
>> drivers/net/dsa/mv88e6xxx/global1.h | 14 +
>> drivers/net/dsa/mv88e6xxx/global1_vtu.c | 505 ++++++++++++++++++++++++++++
>> drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 31 +-
>> 5 files changed, 684 insertions(+), 435 deletions(-)
>> create mode 100644 drivers/net/dsa/mv88e6xxx/global1_vtu.c
>
> I don't see the patchset in net-next. Can you pick it?
This had feedback which you must address, therefore the state in
patchwork is "changes requested" which you could have checked before
asking me this.
If the patch set is fine and you got ACKs for all of your patches
then please resubmit.
Otherwise, make the changes you were asked to make or explain to
the person who asked for them why they are not appropriate.
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 16:10 UTC (permalink / raw)
To: Corentin Labbe
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20170501155856.GA1957@Red>
> > > > Does the internal PHY have a phy driver? It seems like
> > > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > > should be in the phy driver, if it has one.
> > >
> > > Nope. These affect the delay lines for the external PHY interface.
>
> I will add some sentences in the documentation to be more clear about that.
Thanks
>
> >
> > Oh, yes. I understood the patch wrong.
> >
> > None of the patches actually use these properties. Are they actually
> > needed? We should avoid adding vendor specific properties, if they are
> > not used.
> >
>
> The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
> So theses properties is already used out of tree, and will be used in tree soon.
Fair enough.
Thanks
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
* Re: [PATCH net v3] driver: veth: Fix one possbile memleak when fail to register_netdevice
From: David Ahern @ 2017-05-01 15:08 UTC (permalink / raw)
To: gfree.wind, davem, jarod, lucien.xin, stephen, netdev
In-Reply-To: <1493437911-27167-1-git-send-email-gfree.wind@foxmail.com>
On 4/28/17 9:51 PM, gfree.wind@foxmail.com wrote:
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 8c39d6d..418376a 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -224,9 +224,21 @@ static int veth_dev_init(struct net_device *dev)
> return 0;
> }
>
> -static void veth_dev_free(struct net_device *dev)
> +static void veth_destructor_free(struct net_device *dev)
_destructor in the name is confusing since veth_dev_free is the
dev->destructor. Perhaps that should be veth_free_stats.
> {
> free_percpu(dev->vstats);
> +}
> +
> +static void veth_dev_uninit(struct net_device *dev)
> +{
> + /* dev is not registered, perform the free instead of destructor */
> + if (dev->reg_state == NETREG_UNINITIALIZED)
> + veth_destructor_free(dev);
> +}
> +
> +static void veth_dev_free(struct net_device *dev)
> +{
> + veth_destructor_free(dev);
> free_netdev(dev);
> }
>
> @@ -284,6 +296,7 @@ static void veth_set_rx_headroom(struct net_device *dev, int new_hr)
>
> static const struct net_device_ops veth_netdev_ops = {
> .ndo_init = veth_dev_init,
> + .ndo_uninit = veth_dev_uninit,
> .ndo_open = veth_open,
> .ndo_stop = veth_close,
> .ndo_start_xmit = veth_xmit,
>
Functionally, it looks good to me.
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
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