* Re: [PATCH net-next 1/2] net: dsa: lan9303: Move struct lan9303 to include/linux/lan9303.h
From: Andrew Lunn @ 2017-10-24 16:31 UTC (permalink / raw)
To: Egil Hjelmeland; +Cc: vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20171024093515.6749-2-privat@egil-hjelmeland.no>
On Tue, Oct 24, 2017 at 11:35:14AM +0200, Egil Hjelmeland wrote:
> The next patch require net/dsa/tag_lan9303.c to access struct lan9303.
> Therefore move struct lan9303 definitions from drivers/net/dsa/lan9303.h
> to new file include/linux/lan9303.h.
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
O.K, so not too bad.
I am now however wondering if include/linux/dsa/lan9303.h would be
better?
Anyway,
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged
From: Andrew Lunn @ 2017-10-24 16:33 UTC (permalink / raw)
To: Egil Hjelmeland; +Cc: vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20171024093515.6749-3-privat@egil-hjelmeland.no>
On Tue, Oct 24, 2017 at 11:35:15AM +0200, Egil Hjelmeland wrote:
> When CPU transmit directly to port using tag, the LAN9303 does not
> learn MAC addresses received on the CPU port into the ALR.
> ALR learning is performed only when transmitting using ALR lookup.
>
> Solution:
> If the two external ports are bridged and the packet is not STP BPDU,
> then use ALR lookup to allow ALR learning on CPU port.
> Otherwise transmit directly to port with STP state override.
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
> ---
> net/dsa/tag_lan9303.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/net/dsa/tag_lan9303.c b/net/dsa/tag_lan9303.c
> index 57519597c6fc..174721293a34 100644
> --- a/net/dsa/tag_lan9303.c
> +++ b/net/dsa/tag_lan9303.c
> @@ -12,6 +12,7 @@
> *
> */
> #include <linux/etherdevice.h>
> +#include <linux/lan9303.h>
> #include <linux/list.h>
> #include <linux/slab.h>
>
> @@ -39,6 +40,23 @@
> */
>
> #define LAN9303_TAG_LEN 4
> +# define LAN9303_TAG_TX_USE_ALR BIT(3)
> +# define LAN9303_TAG_TX_STP_OVERRIDE BIT(4)
> +#define eth_stp_addr eth_reserved_addr_base
> +
> +/* Decide whether to transmit using ALR lookup, or transmit directly to
> + * port using tag. ALR learning is performed only when using ALR lookup.
> + * If the two external ports are bridged and the packet is not STP BPDU,
> + * then use ALR lookup to allow ALR learning on CPU port.
> + * Otherwise transmit directly to port with STP state override.
> + * See also: lan9303_separate_ports() and lan9303.pdf 6.4.10.1
> + */
> +static inline int lan9303_tx_use_arl(struct dsa_port *dp, u8 *dest_addr)
Hi Egil
There is no need for the inline. The compiler will do that anyway, for
a function like this.
Andrew
^ permalink raw reply
* Re: [PATCH] rds: Fix inaccurate accounting of unsignaled wrs
From: Santosh Shilimkar @ 2017-10-24 16:36 UTC (permalink / raw)
To: Håkon Bugge
Cc: David S . Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
OFED mailing list, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <663DF75A-36AC-4589-83B2-D664672CF374-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On 10/24/2017 9:15 AM, Håkon Bugge wrote:
>
>> On 24 Oct 2017, at 18:05, Santosh Shilimkar
>> <santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org <mailto:santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>>
>> wrote:
>>
[...]
>> Instead of partially doing changes inside/outside helper,
>> can also add inline helper for solicited state like
>> rds_ib_set_wr_solicited_state() and use that along
>> with this change.
>
> Why? There is no book-keeping associated with setting send-solicited.
> Its set on the last fragment of a message and on the last fragment sent
> before throttling due to flow-control.
>
> Creating a function to perform:
>
> FOO |= BAR;
>
> seems like an overkill to me.
>
Its just inline helper and keep code consistent for flag
manipulation. Compiler output will be like "FOO =| BAR;" :-)
> That being said, in my opinion the fragments of a (large) send should be
> scattered with send-solicited. But that is another commit. But with such
> a commit, I agree with you, a helper function is required.
>
We already talked about it so lets leave it there.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] nfp: convert nfp_eth_set_bit_config() into a macro
From: Matthias Kaehlcke @ 2017-10-24 16:56 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Manoj Gupta, David S . Miller, Simon Horman, Dirk van der Merwe,
oss-drivers, netdev, linux-kernel, Renato Golin, Guenter Roeck,
Doug Anderson
In-Reply-To: <20171004111724.29a4d7ff@cakuba.netronome.com>
Hi Jakub,
El Wed, Oct 04, 2017 at 11:17:24AM -0700 Jakub Kicinski ha dit:
> On Wed, 4 Oct 2017 10:42:42 -0700, Manoj Gupta wrote:
> > Hi Jakub,
> >
> > I had discussed about supporting this code with some clang developers.
> > However, the consensus was this code relies on a specific GCC optimizer
> > behavior and Clang does not share the same behavior by design.
>
> Hm. I find surprising that constant propagation to inlined functions
> is considered something GCC-specific rather than obvious/basic.
>
> > Note that even GCC can't compile this code at -O0.
>
> Yes, that makes me feel uncomfortable... Could you try this?
>
> -------8<-------
>
> diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp_eth.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp_eth.c
> index f6f7c085f8e0..47251396fcae 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp_eth.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp_eth.c
> @@ -469,10 +469,10 @@ int nfp_eth_set_configured(struct nfp_cpp *cpp, unsigned int idx, bool configed)
> return nfp_eth_config_commit_end(nsp);
> }
>
> -/* Force inline, FIELD_* macroes require masks to be compilation-time known */
> -static __always_inline int
> +static int
> nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
> - const u64 mask, unsigned int val, const u64 ctrl_bit)
> + const u64 mask, const unsigned int shift,
> + unsigned int val, const u64 ctrl_bit)
> {
> union eth_table_entry *entries = nfp_nsp_config_entries(nsp);
> unsigned int idx = nfp_nsp_config_idx(nsp);
> @@ -489,11 +489,11 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
>
> /* Check if we are already in requested state */
> reg = le64_to_cpu(entries[idx].raw[raw_idx]);
> - if (val == FIELD_GET(mask, reg))
> + if (val == (reg & mask) >> shift)
> return 0;
>
> reg &= ~mask;
> - reg |= FIELD_PREP(mask, val);
> + reg |= (val << shift) & mask;
> entries[idx].raw[raw_idx] = cpu_to_le64(reg);
>
> entries[idx].control |= cpu_to_le64(ctrl_bit);
> @@ -503,6 +503,13 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
> return 0;
> }
>
> +#define NFP_ETH_SET_BIT_CONFIG(nsp, raw_idx, mask, val, ctrl_bit) \
> + ({ \
> + __BF_FIELD_CHECK(mask, 0ULL, val, "NFP_ETH_SET_BIT_CONFIG: "); \
> + nfp_eth_set_bit_config(nsp, raw_idx, mask, __bf_shf(mask), \
> + val, ctrl_bit); \
> + })
> +
> /**
> * __nfp_eth_set_aneg() - set PHY autonegotiation control bit
> * @nsp: NFP NSP handle returned from nfp_eth_config_start()
> @@ -515,7 +522,7 @@ nfp_eth_set_bit_config(struct nfp_nsp *nsp, unsigned int raw_idx,
> */
> int __nfp_eth_set_aneg(struct nfp_nsp *nsp, enum nfp_eth_aneg mode)
> {
> - return nfp_eth_set_bit_config(nsp, NSP_ETH_RAW_STATE,
> + return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_STATE,
> NSP_ETH_STATE_ANEG, mode,
> NSP_ETH_CTRL_SET_ANEG);
> }
> @@ -544,7 +551,7 @@ int __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
> return -EINVAL;
> }
>
> - return nfp_eth_set_bit_config(nsp, NSP_ETH_RAW_STATE,
> + return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_STATE,
> NSP_ETH_STATE_RATE, rate,
> NSP_ETH_CTRL_SET_RATE);
> }
> @@ -561,6 +568,6 @@ int __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
> */
> int __nfp_eth_set_split(struct nfp_nsp *nsp, unsigned int lanes)
> {
> - return nfp_eth_set_bit_config(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> + return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> lanes, NSP_ETH_CTRL_SET_LANES);
> }
Do you plan to send this as an official patch?
Thanks
Matthias
^ permalink raw reply
* Re: [PATCH net] xfrm: Clear sk_dst_cache when applying per-socket policy.
From: Jonathan Basseri 😶 @ 2017-10-24 16:58 UTC (permalink / raw)
To: Steffen Klassert
Cc: netdev, Jakub Sitnicki, David Miller, Lorenzo Colitti,
Eric Dumazet
In-Reply-To: <20171024070414.GJ3323@secunet.com>
On Tue, Oct 24, 2017 at 12:04 AM, Steffen Klassert
<steffen.klassert@secunet.com> wrote:
>
> On Mon, Oct 23, 2017 at 06:18:55PM -0700, Jonathan Basseri wrote:
> > If a socket has a valid dst cache, then xfrm_lookup_route will get
> > skipped. However, the cache is not invalidated when applying policy to a
> > socket (i.e. IPV6_XFRM_POLICY). The result is that new policies are
> > sometimes ignored on those sockets. (Note: This was broken for IPv4 and
> > IPv6 at different times.)
> >
> > This can be demonstrated like so,
> > 1. Create UDP socket.
> > 2. connect() the socket.
> > 3. Apply an outbound XFRM policy to the socket.
> > 4. send() data on the socket.
> >
> > Packets will continue to be sent in the clear instead of matching an
> > xfrm or returning a no-match error (EAGAIN). This affects calls to
> > send() and not sendto().
> >
> > Invalidating the sk_dst_cache is necessary to correctly apply xfrm
> > policies. Since we do this in xfrm_user_policy(), the sk_lock was
> > already acquired in either do_ip_setsockopt() or do_ipv6_setsockopt(),
> > and we may call __sk_dst_reset().
> >
> > Performance impact should be negligible, since this code is only called
> > when changing xfrm policy, and only affects the socket in question.
> >
> > Note: Creating normal XFRM policies should have a similar effect on
> > sk_dst_cache entries that match the policy, but that is not fixed in
> > this patch.
>
> I think we don't have this problem with 'normal' policies. When
> inserting such a policy, we bump the IPv4/IPv6 genid. This should
> invalidate all cached dst entries, no?
>
That sounds reasonable to me. I had not confirmed the behavior for
normal policies, so I was trying to point out that this fix is only
for socket policies. Should I modify the commit message?
^ permalink raw reply
* Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro
From: Jakub Kicinski @ 2017-10-24 17:03 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Manoj Gupta, David S . Miller, Simon Horman, Dirk van der Merwe,
oss-drivers, netdev, linux-kernel, Renato Golin, Guenter Roeck,
Doug Anderson
In-Reply-To: <20171024165603.GA96615@google.com>
On Tue, 24 Oct 2017 09:56:03 -0700, Matthias Kaehlcke wrote:
> > @@ -561,6 +568,6 @@ int __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
> > */
> > int __nfp_eth_set_split(struct nfp_nsp *nsp, unsigned int lanes)
> > {
> > - return nfp_eth_set_bit_config(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> > + return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> > lanes, NSP_ETH_CTRL_SET_LANES);
> > }
>
> Do you plan to send this as an official patch?
Sorry... Dirk is prepping a larger series for this area of code and it
got stuck there a bit :S He says it's coming any day now...
^ permalink raw reply
* Re: [patch net-next v2 00/20] net: sched: convert cls ndo_setup_tc offload calls to per-block callbacks
From: Or Gerlitz @ 2017-10-24 17:03 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Jiri Pirko, Netdev, Jamal Hadi Salim, Cong Wang,
mlxsw, Andrew Lunn, Vivien Didelot, Florian Fainelli,
Michael Chan, Ganesh Goudar, Jeff Kirsher, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel, Jakub Kicinski,
Alexei Starovoitov, Daniel Borkmann, Simon Horman
In-Reply-To: <CAJ3xEMgdRBEuv0hb_G43zJXXRy=PWgY2tdHuwDN0Opc2NVF35g@mail.gmail.com>
On Tue, Oct 24, 2017 at 8:02 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Tue, Oct 24, 2017 at 7:24 PM, Alexander Duyck <alexander.duyck@gmail.com> wrote:
>> On Tue, Oct 24, 2017 at 9:01 AM, Alexander Duyck <alexander.duyck@gmail.com> wrote:
>>> We are getting internal reports of regressions being seen with this
>>> patch set applied. Specifically the issues below have been pointed out
>>> to me. My understanding is that these issues are all being reported on ixgbe:
>>> 1. To offload filter into HW, the hw-tc-offload feature flag has
>>> to be turned on before creating the ingress qdisc.
>>> 2. Deleting the ingress qdisc fails to remove filters added in
>>> HW. Filters in SW gets deleted.
> FWIW, I don't think this is what you're hitting, but please note there are
> two fixes to the series in net-next
>
> 9d452ce net/sched: Fix actions list corruption when adding offloaded tc flows
> 0843c09 net/sched: Set the net-device for egress device instance
>
> I had to looked on other stuff today, but I will keep stressing see if/what
> is broken w.r.t mlx5
> and help to get things to work later this and next week so by netdev we'll
> be fine
>
> Or.
^ permalink raw reply
* Re: general protection fault in __list_del_entry_valid
From: Cong Wang @ 2017-10-24 17:06 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Miller, Herbert Xu, LKML, netdev, Steffen Klassert,
syzkaller-bugs
In-Reply-To: <CACT4Y+ZFWVLJ_TKw7RKAsybK8vBSpYhpmS=ObSSKn3s5azxn-Q@mail.gmail.com>
On Tue, Oct 24, 2017 at 8:02 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Oct 24, 2017 at 4:59 PM, syzbot
> <bot+b3b21cb3f2c95ba434f66810d52abd04c99b877e@syzkaller.appspotmail.com>
> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> aa69ff9e9c32db8aa84835baffea1b70c39e5112
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>
> This also happened on more recent commits, including net-next
> 33ad61d0f799656e8987e9c80e6e15151bb857f3 (Oct 20), with similar
> signature:
>
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 4.14.0-rc5+ #89
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Workqueue: events netlink_sock_destruct_work
> task: ffff8801d9f94480 task.stack: ffff8801d9fa0000
> RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
> RSP: 0018:ffff8801d9fa70b8 EFLAGS: 00010246
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffff8801cb186b60 RDI: ffff8801cb186b68
> RBP: ffff8801d9fa70d0 R08: ffffffff84248f02 R09: 0000000000000000
> R10: ffff8801d9fa6f98 R11: ffff8801ca127a10 R12: 0000000000000000
> R13: ffff8801d9fa7198 R14: ffff8801ca1279f8 R15: ffff8801cb186b68
> FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020000000 CR3: 00000001c17a4000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __list_del_entry include/linux/list.h:116 [inline]
> list_del include/linux/list.h:124 [inline]
> xfrm_policy_walk_done+0xfa/0x310 net/xfrm/xfrm_policy.c:1048
> xfrm_dump_policy_done+0x73/0xa0 net/xfrm/xfrm_user.c:1699
> netlink_sock_destruct+0xfa/0x3c0 net/netlink/af_netlink.c:362
> __sk_destruct+0xfd/0x910 net/core/sock.c:1560
> sk_destruct+0x47/0x80 net/core/sock.c:1595
> __sk_free+0x57/0x230 net/core/sock.c:1603
> sk_free+0x2a/0x40 net/core/sock.c:1614
> netlink_sock_destruct_work+0x19/0x20 net/netlink/af_netlink.c:384
> process_one_work+0xbf0/0x1bc0 kernel/workqueue.c:2119
> worker_thread+0x223/0x1860 kernel/workqueue.c:2253
> kthread+0x35e/0x430 kernel/kthread.c:231
I think this is probably fixed by:
[PATCH 2/2] ipsec: Fix aborted xfrm policy dump crash
^ permalink raw reply
* [PATCH v2] ethernet: cavium: octeon: Switch to using netdev_info().
From: Steven J. Hill @ 2017-10-24 17:04 UTC (permalink / raw)
To: netdev; +Cc: Steven J. Hill, David Daney
Signed-off-by: Steven J. Hill <Steven.Hill@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 27 +++++++++++-------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
index 2887bca..28e10dc 100644
--- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
@@ -705,14 +705,15 @@ static int octeon_mgmt_ioctl_hwtstamp(struct net_device *netdev,
u64 clock_comp = (NSEC_PER_SEC << 32) / octeon_get_io_clock_rate();
if (!ptp.s.ptp_en)
cvmx_write_csr(CVMX_MIO_PTP_CLOCK_COMP, clock_comp);
- pr_info("PTP Clock: Using sclk reference at %lld Hz\n",
- (NSEC_PER_SEC << 32) / clock_comp);
+ netdev_info(netdev,
+ "PTP Clock using sclk reference @ %lldHz\n",
+ (NSEC_PER_SEC << 32) / clock_comp);
} else {
/* The clock is already programmed to use a GPIO */
u64 clock_comp = cvmx_read_csr(CVMX_MIO_PTP_CLOCK_COMP);
- pr_info("PTP Clock: Using GPIO %d at %lld Hz\n",
- ptp.s.ext_clk_in,
- (NSEC_PER_SEC << 32) / clock_comp);
+ netdev_info(netdev,
+ "PTP Clock using GPIO%d @ %lld Hz\n",
+ ptp.s.ext_clk_in, (NSEC_PER_SEC << 32) / clock_comp);
}
/* Enable the clock if it wasn't done already */
@@ -925,16 +926,12 @@ static void octeon_mgmt_adjust_link(struct net_device *netdev)
spin_unlock_irqrestore(&p->lock, flags);
- if (link_changed != 0) {
- if (link_changed > 0) {
- pr_info("%s: Link is up - %d/%s\n", netdev->name,
- phydev->speed,
- phydev->duplex == DUPLEX_FULL ?
- "Full" : "Half");
- } else {
- pr_info("%s: Link is down\n", netdev->name);
- }
- }
+ if (link_changed != 0)
+ if (link_changed > 0)
+ netdev_info(netdev, "Link is up - %d/%s\n",
+ phydev->speed, phydev->duplex == DUPLEX_FULL ? "Full" : "Half");
+ else
+ netdev_info(netdev, "Link is down\n");
}
static int octeon_mgmt_init_phy(struct net_device *netdev)
--
2.1.4
^ permalink raw reply related
* Re: general protection fault in __list_del_entry_valid
From: Dmitry Vyukov @ 2017-10-24 17:11 UTC (permalink / raw)
To: Cong Wang
Cc: syzbot, David Miller, Herbert Xu, LKML, netdev, Steffen Klassert,
syzkaller-bugs
In-Reply-To: <CAM_iQpUv1SYMWMMhM1xDTfT8nVD+6oV-F-4nhEBxJe7TWoEwJQ@mail.gmail.com>
On Tue, Oct 24, 2017 at 7:06 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Tue, Oct 24, 2017 at 8:02 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Tue, Oct 24, 2017 at 4:59 PM, syzbot
>> <bot+b3b21cb3f2c95ba434f66810d52abd04c99b877e@syzkaller.appspotmail.com>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> aa69ff9e9c32db8aa84835baffea1b70c39e5112
>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>> C reproducer is attached
>>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>>> for information about syzkaller reproducers
>>
>> This also happened on more recent commits, including net-next
>> 33ad61d0f799656e8987e9c80e6e15151bb857f3 (Oct 20), with similar
>> signature:
>>
>> general protection fault: 0000 [#1] SMP KASAN
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 4.14.0-rc5+ #89
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> Workqueue: events netlink_sock_destruct_work
>> task: ffff8801d9f94480 task.stack: ffff8801d9fa0000
>> RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
>> RSP: 0018:ffff8801d9fa70b8 EFLAGS: 00010246
>> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: ffff8801cb186b60 RDI: ffff8801cb186b68
>> RBP: ffff8801d9fa70d0 R08: ffffffff84248f02 R09: 0000000000000000
>> R10: ffff8801d9fa6f98 R11: ffff8801ca127a10 R12: 0000000000000000
>> R13: ffff8801d9fa7198 R14: ffff8801ca1279f8 R15: ffff8801cb186b68
>> FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000020000000 CR3: 00000001c17a4000 CR4: 00000000001406e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>> __list_del_entry include/linux/list.h:116 [inline]
>> list_del include/linux/list.h:124 [inline]
>> xfrm_policy_walk_done+0xfa/0x310 net/xfrm/xfrm_policy.c:1048
>> xfrm_dump_policy_done+0x73/0xa0 net/xfrm/xfrm_user.c:1699
>> netlink_sock_destruct+0xfa/0x3c0 net/netlink/af_netlink.c:362
>> __sk_destruct+0xfd/0x910 net/core/sock.c:1560
>> sk_destruct+0x47/0x80 net/core/sock.c:1595
>> __sk_free+0x57/0x230 net/core/sock.c:1603
>> sk_free+0x2a/0x40 net/core/sock.c:1614
>> netlink_sock_destruct_work+0x19/0x20 net/netlink/af_netlink.c:384
>> process_one_work+0xbf0/0x1bc0 kernel/workqueue.c:2119
>> worker_thread+0x223/0x1860 kernel/workqueue.c:2253
>> kthread+0x35e/0x430 kernel/kthread.c:231
>
> I think this is probably fixed by:
Ah! I guess also syzkaller :)
> [PATCH 2/2] ipsec: Fix aborted xfrm policy dump crash
Can you please follow this part of the guideline? This will greatly
help keeping the overall process working. Thanks!
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> Note: all commands must start from beginning of the line.
^ permalink raw reply
* Re: [PATCH] nfp: convert nfp_eth_set_bit_config() into a macro
From: Matthias Kaehlcke @ 2017-10-24 17:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Manoj Gupta, David S . Miller, Simon Horman, Dirk van der Merwe,
oss-drivers, netdev, linux-kernel, Renato Golin, Guenter Roeck,
Doug Anderson
In-Reply-To: <20171024100356.63bcbb2f@cakuba.netronome.com>
El Tue, Oct 24, 2017 at 10:03:56AM -0700 Jakub Kicinski ha dit:
> On Tue, 24 Oct 2017 09:56:03 -0700, Matthias Kaehlcke wrote:
> > > @@ -561,6 +568,6 @@ int __nfp_eth_set_speed(struct nfp_nsp *nsp, unsigned int speed)
> > > */
> > > int __nfp_eth_set_split(struct nfp_nsp *nsp, unsigned int lanes)
> > > {
> > > - return nfp_eth_set_bit_config(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> > > + return NFP_ETH_SET_BIT_CONFIG(nsp, NSP_ETH_RAW_PORT, NSP_ETH_PORT_LANES,
> > > lanes, NSP_ETH_CTRL_SET_LANES);
> > > }
> >
> > Do you plan to send this as an official patch?
>
> Sorry... Dirk is prepping a larger series for this area of code and it
> got stuck there a bit :S
No prob, just wanted to make sure it didn't slip under the radar.
> He says it's coming any day now...
Great, thanks!
^ permalink raw reply
* RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged
From: Woojung.Huh @ 2017-10-24 17:18 UTC (permalink / raw)
To: privat, andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20171024093515.6749-3-privat@egil-hjelmeland.no>
Hi Egil,
> +static inline int lan9303_tx_use_arl(struct dsa_port *dp, u8 *dest_addr)
> +{
> + struct lan9303 *chip = dp->ds->priv;
> +
> + return chip->is_bridged && !ether_addr_equal(dest_addr,
> eth_stp_addr);
> +}
>
> static struct sk_buff *lan9303_xmit(struct sk_buff *skb, struct net_device
> *dev)
> {
> @@ -62,7 +80,10 @@ static struct sk_buff *lan9303_xmit(struct sk_buff *skb,
> struct net_device *dev)
>
> lan9303_tag = (u16 *)(skb->data + 2 * ETH_ALEN);
> lan9303_tag[0] = htons(ETH_P_8021Q);
> - lan9303_tag[1] = htons(dp->index | BIT(4));
> + lan9303_tag[1] = lan9303_tx_use_arl(dp, skb->data) ?
How about using skb_mac_header(skb) than skb->data?
> + LAN9303_TAG_TX_USE_ALR :
> + dp->index |
Thanks.
Woojung
^ permalink raw reply
* Re: [patch net-next v2 00/20] net: sched: convert cls ndo_setup_tc offload calls to per-block callbacks
From: Nambiar, Amritha @ 2017-10-24 17:22 UTC (permalink / raw)
To: Or Gerlitz, Alexander Duyck
Cc: David Miller, Jiri Pirko, Netdev, Jamal Hadi Salim, Cong Wang,
mlxsw, Andrew Lunn, Vivien Didelot, Florian Fainelli,
Michael Chan, Ganesh Goudar, Jeff Kirsher, Saeed Mahameed,
Matan Barak, Leon Romanovsky, Ido Schimmel, Jakub Kicinski,
Alexei Starovoitov, Daniel Borkmann, Simon Horman
In-Reply-To: <CAJ3xEMgdRBEuv0hb_G43zJXXRy=PWgY2tdHuwDN0Opc2NVF35g@mail.gmail.com>
On 10/24/2017 10:02 AM, Or Gerlitz wrote:
> On Tue, Oct 24, 2017 at 7:24 PM, Alexander Duyck
> <alexander.duyck@gmail.com <mailto:alexander.duyck@gmail.com>> wrote:
>
> On Tue, Oct 24, 2017 at 9:01 AM, Alexander Duyck
> <alexander.duyck@gmail.com <mailto:alexander.duyck@gmail.com>> wrote:
>
>
>
> > We are getting internal reports of regressions being seen with this
> > patch set applied. Specifically the issues below have been pointed out
> > to me. My understanding is that these issues are all being reported on
> > ixgbe:
> >
> > 1. To offload filter into HW, the hw-tc-offload feature flag has
> > to be turned on before creating the ingress qdisc.
>
>
>
> > 2. Deleting the ingress qdisc fails to remove filters added in
> > HW. Filters in SW gets deleted.
>
>
>
> FWIW, I don't think this is what you're hitting, but please note there
> are two fixes
> to the series in net-next
>
> 9d452ce net/sched: Fix actions list corruption when adding offloaded tc
> flows
It looks like this patch just got applied, this fix wasn't included
during our testing.
> 0843c09 net/sched: Set the net-device for egress device instance
This fix was already in place during our testing. Also, the filters
added were matching on IPv4 addresses with action drop.
> I had to looked on other stuff today, but I will keep stressing see
> if/what is broken w.r.t mlx5
> and help to get things to work later this and next week so by netdev
> we'll be fine
>
> Or.
>
>
^ permalink raw reply
* Re: [5/5] e1000e: Avoid receiver overrun interrupt bursts
From: Lennart Sorensen @ 2017-10-24 17:20 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Philip Prindeville, Jeff Kirsher, netdev, intel-wired-lan,
linux-kernel
In-Reply-To: <20170919194102.h2nu72evbqhpu765@f1.synalogic.ca>
On Tue, Sep 19, 2017 at 09:41:02PM +0200, Benjamin Poirier wrote:
> On 2017/09/19 12:38, Philip Prindeville wrote:
> > Hi.
> >
> > We’ve been running this patchset (all 5) for about as long as they’ve been under review… about 2 months. And in a burn-in lab with heavy traffic.
> >
> > We’ve not seen a single link-flap in hundreds of ours of saturated traffic.
> >
> > Would love to see some resolution soon on this as we don’t want to ship a release with unsanctioned patches.
> >
> > Is there an estimate on when that might be?
>
> The patches have been added to Jeff Kirsher's next-queue tree. I guess
> they will be submitted for v4.15 which might be released in early
> 2018...
> http://phb-crystal-ball.org/
And then they will be submitted to linux-stable so this long standing
regression can be fixed, right?
--
Len Sorensen
^ permalink raw reply
* Re: [PATCH] net: sunrpc: svcauth_gss: use BUG_ON instead of if condition followed by BUG
From: Weston Andros Adamson @ 2017-10-24 17:26 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Gustavo A. R. Silva, Jeff Layton, Trond Myklebust, Anna Schumaker,
David S. Miller, linux-nfs list, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <20171023203135.GA21106@fieldses.org>
Is there a reason to BUG() in these places? Couldn't we WARN_ON_ONCE and return an error?
-dros
> On Oct 23, 2017, at 4:31 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> In the past we've avoided BUG_ON(X) where X might have side effects, on
> the theory that it should actually be OK just to compile out BUG_ON()s.
> Has that changed?
>
> In any case, I don't find that this improves readability; dropping.
>
> --b.
>
> On Mon, Oct 23, 2017 at 01:16:35PM -0500, Gustavo A. R. Silva wrote:
>> Use BUG_ON instead of if condition followed by BUG.
>>
>> This issue was detected with the help of Coccinelle.
>>
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> net/sunrpc/auth_gss/svcauth_gss.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
>> index 7b1ee5a..a10ce43 100644
>> --- a/net/sunrpc/auth_gss/svcauth_gss.c
>> +++ b/net/sunrpc/auth_gss/svcauth_gss.c
>> @@ -855,11 +855,9 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf *buf, u32 seq, struct g
>> return stat;
>> if (integ_len > buf->len)
>> return stat;
>> - if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
>> - BUG();
>> + BUG_ON(xdr_buf_subsegment(buf, &integ_buf, 0, integ_len));
>> /* copy out mic... */
>> - if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
>> - BUG();
>> + BUG_ON(read_u32_from_xdr_buf(buf, integ_len, &mic.len));
>> if (mic.len > RPC_MAX_AUTH_SIZE)
>> return stat;
>> mic.data = kmalloc(mic.len, GFP_KERNEL);
>> @@ -1611,8 +1609,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
>> BUG_ON(integ_len % 4);
>> *p++ = htonl(integ_len);
>> *p++ = htonl(gc->gc_seq);
>> - if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
>> - BUG();
>> + BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len));
>> if (resbuf->tail[0].iov_base == NULL) {
>> if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
>> goto out_err;
>> --
>> 2.7.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ethernet: cavium: octeon: Switch to using netdev_info().
From: Steven J. Hill @ 2017-10-24 17:25 UTC (permalink / raw)
To: netdev; +Cc: Steven J. Hill, David Daney
Signed-off-by: Steven J. Hill <Steven.Hill@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 27 +++++++++++-------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
index 2887bca..28e10dc 100644
--- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
@@ -705,14 +705,15 @@ static int octeon_mgmt_ioctl_hwtstamp(struct net_device *netdev,
u64 clock_comp = (NSEC_PER_SEC << 32) / octeon_get_io_clock_rate();
if (!ptp.s.ptp_en)
cvmx_write_csr(CVMX_MIO_PTP_CLOCK_COMP, clock_comp);
- pr_info("PTP Clock: Using sclk reference at %lld Hz\n",
- (NSEC_PER_SEC << 32) / clock_comp);
+ netdev_info(netdev,
+ "PTP Clock using sclk reference @ %lldHz\n",
+ (NSEC_PER_SEC << 32) / clock_comp);
} else {
/* The clock is already programmed to use a GPIO */
u64 clock_comp = cvmx_read_csr(CVMX_MIO_PTP_CLOCK_COMP);
- pr_info("PTP Clock: Using GPIO %d at %lld Hz\n",
- ptp.s.ext_clk_in,
- (NSEC_PER_SEC << 32) / clock_comp);
+ netdev_info(netdev,
+ "PTP Clock using GPIO%d @ %lld Hz\n",
+ ptp.s.ext_clk_in, (NSEC_PER_SEC << 32) / clock_comp);
}
/* Enable the clock if it wasn't done already */
@@ -925,16 +926,12 @@ static void octeon_mgmt_adjust_link(struct net_device *netdev)
spin_unlock_irqrestore(&p->lock, flags);
- if (link_changed != 0) {
- if (link_changed > 0) {
- pr_info("%s: Link is up - %d/%s\n", netdev->name,
- phydev->speed,
- phydev->duplex == DUPLEX_FULL ?
- "Full" : "Half");
- } else {
- pr_info("%s: Link is down\n", netdev->name);
- }
- }
+ if (link_changed != 0)
+ if (link_changed > 0)
+ netdev_info(netdev, "Link is up - %d/%s\n",
+ phydev->speed, phydev->duplex == DUPLEX_FULL ? "Full" : "Half");
+ else
+ netdev_info(netdev, "Link is down\n");
}
static int octeon_mgmt_init_phy(struct net_device *netdev)
--
2.1.4
^ permalink raw reply related
* Re: [5/5] e1000e: Avoid receiver overrun interrupt bursts
From: Philip Prindeville @ 2017-10-24 17:39 UTC (permalink / raw)
To: Lennart Sorensen
Cc: Benjamin Poirier, Jeff Kirsher, netdev, intel-wired-lan,
linux-kernel
In-Reply-To: <20171024172027.onfcusdcicxqnfjp@csclub.uwaterloo.ca>
> On Oct 24, 2017, at 11:20 AM, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
>
> On Tue, Sep 19, 2017 at 09:41:02PM +0200, Benjamin Poirier wrote:
>> On 2017/09/19 12:38, Philip Prindeville wrote:
>>> Hi.
>>>
>>> We’ve been running this patchset (all 5) for about as long as they’ve been under review… about 2 months. And in a burn-in lab with heavy traffic.
>>>
>>> We’ve not seen a single link-flap in hundreds of ours of saturated traffic.
>>>
>>> Would love to see some resolution soon on this as we don’t want to ship a release with unsanctioned patches.
>>>
>>> Is there an estimate on when that might be?
>>
>> The patches have been added to Jeff Kirsher's next-queue tree. I guess
>> they will be submitted for v4.15 which might be released in early
>> 2018...
>> http://phb-crystal-ball.org/
>
> And then they will be submitted to linux-stable so this long standing
> regression can be fixed, right?
>
Let’s hope!
-Philip
^ permalink raw reply
* Re: [PATCH] net: sunrpc: svcauth_gss: use BUG_ON instead of if condition followed by BUG
From: J. Bruce Fields @ 2017-10-24 17:53 UTC (permalink / raw)
To: Weston Andros Adamson
Cc: Gustavo A. R. Silva, Jeff Layton, Trond Myklebust, Anna Schumaker,
David S. Miller, linux-nfs list, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <496D700A-E9D1-4745-B5DE-24BB9231A449-J6AcJDG0ZEwdnm+yROfE0A@public.gmane.org>
On Tue, Oct 24, 2017 at 01:26:49PM -0400, Weston Andros Adamson wrote:
> Is there a reason to BUG() in these places? Couldn't we WARN_ON_ONCE and return an error?
I think the BUG() will just kill an nfsd thread that isn't holding any
interesting locks.
The failures look unlikely. (Except for that read_u32... return, I
wonder if we're missing a check there.)
--b.
>
> -dros
>
> > On Oct 23, 2017, at 4:31 PM, J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:
> >
> > In the past we've avoided BUG_ON(X) where X might have side effects, on
> > the theory that it should actually be OK just to compile out BUG_ON()s.
> > Has that changed?
> >
> > In any case, I don't find that this improves readability; dropping.
> >
> > --b.
> >
> > On Mon, Oct 23, 2017 at 01:16:35PM -0500, Gustavo A. R. Silva wrote:
> >> Use BUG_ON instead of if condition followed by BUG.
> >>
> >> This issue was detected with the help of Coccinelle.
> >>
> >> Signed-off-by: Gustavo A. R. Silva <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>
> >> ---
> >> net/sunrpc/auth_gss/svcauth_gss.c | 9 +++------
> >> 1 file changed, 3 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
> >> index 7b1ee5a..a10ce43 100644
> >> --- a/net/sunrpc/auth_gss/svcauth_gss.c
> >> +++ b/net/sunrpc/auth_gss/svcauth_gss.c
> >> @@ -855,11 +855,9 @@ unwrap_integ_data(struct svc_rqst *rqstp, struct xdr_buf *buf, u32 seq, struct g
> >> return stat;
> >> if (integ_len > buf->len)
> >> return stat;
> >> - if (xdr_buf_subsegment(buf, &integ_buf, 0, integ_len))
> >> - BUG();
> >> + BUG_ON(xdr_buf_subsegment(buf, &integ_buf, 0, integ_len));
> >> /* copy out mic... */
> >> - if (read_u32_from_xdr_buf(buf, integ_len, &mic.len))
> >> - BUG();
> >> + BUG_ON(read_u32_from_xdr_buf(buf, integ_len, &mic.len));
> >> if (mic.len > RPC_MAX_AUTH_SIZE)
> >> return stat;
> >> mic.data = kmalloc(mic.len, GFP_KERNEL);
> >> @@ -1611,8 +1609,7 @@ svcauth_gss_wrap_resp_integ(struct svc_rqst *rqstp)
> >> BUG_ON(integ_len % 4);
> >> *p++ = htonl(integ_len);
> >> *p++ = htonl(gc->gc_seq);
> >> - if (xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len))
> >> - BUG();
> >> + BUG_ON(xdr_buf_subsegment(resbuf, &integ_buf, integ_offset, integ_len));
> >> if (resbuf->tail[0].iov_base == NULL) {
> >> if (resbuf->head[0].iov_len + RPC_MAX_AUTH_SIZE > PAGE_SIZE)
> >> goto out_err;
> >> --
> >> 2.7.4
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v9 00/10] net: stmmac: dwmac-sun8i: Handle integrated PHY
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: 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, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Corentin Labbe
Hello
The current way to find if the PHY is internal is to compare DT phy-mode
and emac_variant/internal_phy.
But it will negate a possible future SoC where an external PHY use the
same phy mode than the integrated one.
This patchs series adds a new way to handle this problem via a mdio-mux.
The first try was to create a new MDIO mux "mdio-mux-syscon".
mdio-mux-syscon working the same way than mdio-mux-mmioreg with the exception
that the register is used via syscon/regmap.
But this solution does not work for two reason:
- changing the MDIO selection need the reset of MAC which cannot be done by the
mdio-mux-syscon driver
- There were driver loading order problem:
- mdio-mux-syscon needing that stmmac register the parent MDIO
- stmmac needing that child MDIO was registered just after registering parent MDIO
So we cannot use any external MDIO-mux.
The final solution was to represent the mdio-mux in MAC node and let the MAC handle all things.
Since DT bits was reverted in 4.13, this patch series include the revert of the revert.
I have let patch splited for easy review. (for seeing what's new)
But the final serie could have some patch squashed if someone want.
Like squashing patch and 1 and 2 (documentation)
The first 7 patch should go via the sunxi tree, the last three via the net tree.
Regards
Changes since v8:
- added reference to mdio-mux.txt in documentation
- removed compatible mdio-mux
- added mdio-parent-bus
Changes since v7:
- moved mdio-mux ouf of mdio as asked by Andrew Lunn
- reordered patchs order
Changes since v6:
- renamed external mdio to "external_mdio"
- added compatible to mdio-mux and internal-mdio
- removed usage of phy-is-integrated
- renamed do_not_scan to compatible_muxes (patch 10)
- patch 8 9 of v6 are squashed
Changes since v5:
- reordered patch 1 and 2
- mdio-mux node is now a mdio's child
- added patch 11 for removing unnecessary scan of mdio-mux
Changes since v4:
- Update documentation for new bindings
- Added 4 patchs for bring back reverted stuff of 4.13
- dwmac-sun8i now handle mdio-mux
- MDIO use now compatible = "snps,dwmac-mdio";
Changes since v3:
- Added a patch for handling fixed-link
- Updated documentation
Changes since v2:
- Add a MDIO mux for creating distinction between integrated and external MDIO.
- phy-is-integrated is not set in dtsi.
Changes since v1:
- Dropped phy-is-integrated documentation patch since another same patch was already merged
- Moved phy-is-integrated from SoC dtsi to final board DT.
Acked-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Corentin Labbe (10):
dt-bindings: net: Restore sun8i dwmac binding
dt-bindings: net: dwmac-sun8i: update documentation about integrated
PHY
arm: dts: sunxi: h3/h5: Restore EMAC changes
arm: dts: sunxi: h3/h5: represent the mdio switch used by
sun8i-h3-emac
arm: dts: sunxi: Restore EMAC changes (boards)
arm64: dts: allwinner: Restore EMAC changes
arm64: dts: allwinner: add snps,dwmac-mdio compatible to emac/mdio
net: stmmac: snps,dwmac-mdio MDIOs are automatically registered
net: stmmac: dwmac-sun8i: Handle integrated/external MDIOs
net: stmmac: sun8i: Restore the compatibles
.../devicetree/bindings/net/dwmac-sun8i.txt | 205 ++++++++++++
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 9 +
arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 19 ++
arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 19 ++
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 +
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 22 ++
arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 16 +
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 48 +++
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 16 +
.../boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 15 +
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 17 +
.../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 16 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 ++
.../boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts | 17 +
.../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 17 +
.../dts/allwinner/sun50i-h5-orangepi-prime.dts | 17 +
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 361 +++++++++++++--------
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 -
23 files changed, 742 insertions(+), 134 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
--
2.13.6
--
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 v9 01/10] dt-bindings: net: Restore sun8i dwmac binding
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
andrew, f.fainelli
Cc: netdev, Corentin Labbe, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20171024175714.15840-1-clabbe.montjoie@gmail.com>
The original dwmac-sun8i DT bindings have some issue on how to handle
integrated PHY and was reverted in last RC of 4.13.
But now we have a solution so we need to get back that was reverted.
This patch restore dt-bindings documentation about dwmac-sun8i
This reverts commit 8aa33ec2f481 ("dt-bindings: net: Revert sun8i dwmac binding")
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/net/dwmac-sun8i.txt | 84 ++++++++++++++++++++++
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
new file mode 100644
index 000000000000..725f3b187886
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -0,0 +1,84 @@
+* Allwinner sun8i GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun8i-v3s-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- interrupts: interrupt for the device
+- interrupt-names: should be "macirq"
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "stmmaceth"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "stmmaceth"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+- syscon: A phandle to the syscon of the SoC with one of the following
+ compatible string:
+ - allwinner,sun8i-h3-system-controller
+ - allwinner,sun8i-v3s-system-controller
+ - allwinner,sun50i-a64-system-controller
+ - allwinner,sun8i-a83t-system-controller
+
+Optional properties:
+- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
+- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
+Both delay properties need to be a multiple of 100. They control the delay for
+external PHY.
+
+Optional properties for the following compatibles:
+ - "allwinner,sun8i-h3-emac",
+ - "allwinner,sun8i-v3s-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with the following compatibles:
+ - "allwinner,sun8i-h3-emac",
+ - "allwinner,sun8i-v3s-emac":
+- clocks: a phandle to the reference clock for the EPHY
+- resets: a phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet@1c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.13.6
^ permalink raw reply related
* [PATCH v9 03/10] arm: dts: sunxi: h3/h5: Restore EMAC changes
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: 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, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Corentin Labbe
In-Reply-To: <20171024175714.15840-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The original dwmac-sun8i DT bindings have some issue on how to handle
integrated PHY and was reverted in last RC of 4.13.
But now we have a solution so we need to get back that was reverted.
This patch restore sunxi-h3-h5.dtsi
This reverts partially commit fe45174b72ae ("arm: dts: sunxi: Revert EMAC changes")
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index c1bd09dab3da..d762098fc589 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -408,6 +408,32 @@
clocks = <&osc24M>;
};
+ emac: ethernet@1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x10000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.13.6
--
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 related
* [PATCH v9 04/10] arm: dts: sunxi: h3/h5: represent the mdio switch used by sun8i-h3-emac
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
andrew, f.fainelli
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
Corentin Labbe
In-Reply-To: <20171024175714.15840-1-clabbe.montjoie@gmail.com>
Since dwmac-sun8i could use either an integrated PHY or an external PHY
(which could be at same MDIO address), we need to represent this selection
by a MDIO switch.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d762098fc589..0e97df490aba 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -422,14 +422,36 @@
#size-cells = <0>;
status = "disabled";
- mdio: mdio {
+ mdio0: mdio {
#address-cells = <1>;
#size-cells = <0>;
- int_mii_phy: ethernet-phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
+ compatible = "snps,dwmac-mdio";
+ };
+
+ mdio-mux {
+ compatible = "allwinner,sun8i-h3-mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio-parent-bus = <&mdio0>;
+ /* Only one MDIO is usable at the time */
+ internal_mdio: mdio@1 {
+ compatible = "allwinner,sun8i-h3-mdio-internal";
reg = <1>;
- clocks = <&ccu CLK_BUS_EPHY>;
- resets = <&ccu RST_BUS_EPHY>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ int_mii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+
+ external_mdio: mdio@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
};
--
2.13.6
^ permalink raw reply related
* [PATCH v9 05/10] arm: dts: sunxi: Restore EMAC changes (boards)
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
andrew, f.fainelli
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
Corentin Labbe
In-Reply-To: <20171024175714.15840-1-clabbe.montjoie@gmail.com>
The original dwmac-sun8i DT bindings have some issue on how to handle
integrated PHY and was reverted in last RC of 4.13.
But now we have a solution so we need to get back that was reverted.
This patch restore all boards DT about dwmac-sun8i
This reverts partially commit fe45174b72ae ("arm: dts: sunxi: Revert EMAC changes")
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 9 +++++++++
arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 19 +++++++++++++++++++
arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 19 +++++++++++++++++++
arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 7 +++++++
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 ++++++++
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +++++
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 22 ++++++++++++++++++++++
arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts | 16 ++++++++++++++++
10 files changed, 121 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index b1502df7b509..6713d0f2b3f4 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -56,6 +56,8 @@
aliases {
serial0 = &uart0;
+ /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &xr819;
};
@@ -102,6 +104,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index e1dba9ffa94b..f2292deaa590 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -52,6 +52,7 @@
compatible = "sinovoip,bpi-m2-plus", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
serial1 = &uart1;
};
@@ -111,6 +112,24 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_rgmii_pins>;
+ phy-supply = <®_gmac_3v3>;
+ phy-handle = <&ext_rgmii_phy>;
+ phy-mode = "rgmii";
+
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
+&external_mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
index 73766d38ee6c..cfb96da3cfef 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -66,6 +66,25 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_rgmii_pins>;
+ phy-supply = <®_gmac_3v3>;
+ phy-handle = <&ext_rgmii_phy>;
+ phy-mode = "rgmii";
+
+ allwinner,leds-active-low;
+
+ status = "okay";
+};
+
+&external_mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <7>;
+ };
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
index 8d2cc6e9a03f..78f6c24952dd 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
@@ -46,3 +46,10 @@
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 1bf51802f5aa..b20be95b49d5 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &rtl8189;
};
@@ -117,6 +118,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index a1c6ff6fd05d..82e5d28cd698 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -97,6 +98,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
index 8b93f5c781a7..a10281b455f5 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
@@ -53,6 +53,11 @@
};
};
+&emac {
+ /* LEDs changed to active high on the plus */
+ /delete-property/ allwinner,leds-active-low;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index d0b80fda2f6b..6d98bcfbe877 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -52,6 +52,7 @@
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
aliases {
+ ethernet0 = &emac;
serial0 = &uart0;
};
@@ -117,6 +118,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
index 72ca01b93f1b..cbc499b04de4 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -47,6 +47,10 @@
model = "Xunlong Orange Pi Plus / Plus 2";
compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
+ aliases {
+ ethernet0 = &emac;
+ };
+
reg_gmac_3v3: gmac-3v3 {
compatible = "regulator-fixed";
regulator-name = "gmac-3v3";
@@ -74,6 +78,24 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_rgmii_pins>;
+ phy-supply = <®_gmac_3v3>;
+ phy-handle = <&ext_rgmii_phy>;
+ phy-mode = "rgmii";
+
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
+&external_mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_8bit_pins>;
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
index 97920b12a944..6dbf7b2e0c13 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts
@@ -61,3 +61,19 @@
gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
};
};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_rgmii_pins>;
+ phy-supply = <®_gmac_3v3>;
+ phy-handle = <&ext_rgmii_phy>;
+ phy-mode = "rgmii";
+ status = "okay";
+};
+
+&external_mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
--
2.13.6
^ permalink raw reply related
* [PATCH v9 07/10] arm64: dts: allwinner: add snps,dwmac-mdio compatible to emac/mdio
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: robh+dt, mark.rutland, maxime.ripard, wens, linux,
catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue,
andrew, f.fainelli
Cc: netdev, devicetree, linux-arm-kernel, linux-kernel,
Corentin Labbe
In-Reply-To: <20171024175714.15840-1-clabbe.montjoie@gmail.com>
stmmac bindings docs said that its mdio node must have
compatible = "snps,dwmac-mdio";
Since dwmac-sun8i does not have any good reasons to not doing it, all
their MDIO node must have it.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 0650a1cda107..0a2074f86f2c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -532,6 +532,7 @@
#size-cells = <0>;
mdio: mdio {
+ compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;
};
--
2.13.6
^ permalink raw reply related
* [PATCH v9 08/10] net: stmmac: snps,dwmac-mdio MDIOs are automatically registered
From: Corentin Labbe @ 2017-10-24 17:57 UTC (permalink / raw)
To: 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, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Corentin Labbe
In-Reply-To: <20171024175714.15840-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
stmmac bindings docs said that its mdio node must have
compatible = "snps,dwmac-mdio";
Since dwmac-sun8i does not have any good reasons to not doing it, all
their MDIO node must have it.
Since these compatible is automatically registered, dwmac-sun8i compatible
does not need to be in need_mdio_ids.
Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 8a280b48e3a9..9e616da0745d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -311,10 +311,6 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
bool mdio = true;
static const struct of_device_id need_mdio_ids[] = {
{ .compatible = "snps,dwc-qos-ethernet-4.10" },
- { .compatible = "allwinner,sun8i-a83t-emac" },
- { .compatible = "allwinner,sun8i-h3-emac" },
- { .compatible = "allwinner,sun8i-v3s-emac" },
- { .compatible = "allwinner,sun50i-a64-emac" },
{},
};
--
2.13.6
--
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 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