* Re: [PATCH v3 net] net: Properly update v4 routes with v6 nexthop
From: David Ahern @ 2019-09-04 15:02 UTC (permalink / raw)
To: Donald Sharp, netdev, dsahern, sworley
In-Reply-To: <20190904141158.17021-1-sharpd@cumulusnetworks.com>
On 9/4/19 8:11 AM, Donald Sharp wrote:
> When creating a v4 route that uses a v6 nexthop from a nexthop group.
> Allow the kernel to properly send the nexthop as v6 via the RTA_VIA
> attribute.
>
...
>
> Fixes: dcb1ecb50edf (“ipv4: Prepare for fib6_nh from a nexthop object”)
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> include/net/ip_fib.h | 4 ++--
> include/net/nexthop.h | 5 +++--
> net/ipv4/fib_semantics.c | 15 ++++++++-------
> net/ipv6/route.c | 11 ++++++-----
> 4 files changed, 19 insertions(+), 16 deletions(-)
>
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] ip nexthop: Allow flush|list operations to specify a specific protocol
From: David Ahern @ 2019-09-04 14:59 UTC (permalink / raw)
To: Donald Sharp, netdev
In-Reply-To: <20190810001843.32068-3-sharpd@cumulusnetworks.com>
On 8/9/19 6:18 PM, Donald Sharp wrote:
> In the case where we have a large number of nexthops from a specific
> protocol, allow the flush and list operations to take a protocol
> to limit the commands scopes.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> ip/ipnexthop.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
applied to iproute2-next. Thanks for the test cases.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: stmmac: Add support for MDIO interrupts
From: Andrew Lunn @ 2019-09-04 14:58 UTC (permalink / raw)
To: Voon Weifeng
Cc: David S. Miller, Maxime Coquelin, netdev, linux-kernel,
Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue, Ong Boon Leong
In-Reply-To: <1567605774-5500-1-git-send-email-weifeng.voon@intel.com>
On Wed, Sep 04, 2019 at 10:02:54PM +0800, Voon Weifeng wrote:
> From: "Chuah, Kim Tatt" <kim.tatt.chuah@intel.com>
>
> DW EQoS v5.xx controllers added capability for interrupt generation
> when MDIO interface is done (GMII Busy bit is cleared).
> This patch adds support for this interrupt on supported HW to avoid
> polling on GMII Busy bit.
>
> stmmac_mdio_read() & stmmac_mdio_write() will sleep until wake_up() is
> called by the interrupt handler.
>
> Reviewed-by: Voon Weifeng <weifeng.voon@intel.com>
> Reviewed-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
> Reviewed-by: Ong Boon Leong <boon.leong.ong@intel.com>
> Signed-off-by: Chuah, Kim Tatt <kim.tatt.chuah@intel.com>
> Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
> Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Hi Voon
It is normal to include a short description of what you changed
between the previous version and this version.
The formatting of this patch also looks a bit odd. Did you use
git format-patch ; git send-email?
Thanks
Andrew
^ permalink raw reply
* Re: Is bug 200755 in anyone's queue??
From: Steve Zabele @ 2019-09-04 14:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mark KEATON, Willem de Bruijn, Network Development,
shum@canndrew.org, vladimir116@gmail.com, saifi.khan@strikr.in,
Daniel Borkmann, on2k16nm@gmail.com, Stephen Hemminger
In-Reply-To: <c3b83305-82a5-f3c8-2602-1aed2e9b51ca@gmail.com>
I think a dual table approach makes a lot of sense here, especially if we look at the different use cases. For the DNS server example, almost certainly there will not be any connected sockets using the server port, so a test of whether the connected table is empty (maybe a boolean stored with the unconnected table?) should get to the existing code very quickly and not require accessing the memory holding the connected table. For our use case, the connected sockets persist for long periods (at network timescales at least) and so any rehashing should be infrequent and so have limited impact on performance overall.
So does a dual table approach seem workable to other folks that know the internals?
Thanks!
Steve
Sent from my iPhone
> On Sep 4, 2019, at 8:23 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
>> On 9/4/19 2:00 PM, Mark KEATON wrote:
>> Hi Willem,
>>
>> I am the person who commented on the original bug report in bugzilla.
>>
>> In communicating with Steve just now about possible solutions that maintain the efficiency that you are after, what would you think of the following: keep two lists of UDP sockets, those connected and those not connected, and always searching the connected list first.
>
> This was my suggestion.
>
> Note that this requires adding yet another hash table, and yet another lookup
> (another cache line miss per incoming packet)
>
> This lookup will slow down DNS and QUIC servers, or any application solely using not connected sockets.
>
>
> The word 'quick' you use is slightly misleading, since a change like that is a trade off.
> Some applications might become faster, while others become slower.
>
> Another issue is that a connect() can follow a bind(), we would need to rehash sockets
> from one table to another. (Or add another set of anchors in UDP sockets, so that sockets can be in all the hash tables)
>
>
> If the connected list is empty, then the lookup can quickly use the not connected list to find a socket for load balancing. If there are connected sockets, then only those connected sockets are searched first for an exact match.
>>
>> Another option might be to do it with a single list if the connected sockets are all at the beginning of the list. This would require the two separate lookups to start at different points in the list.
>>
>> Thoughts?
>>
>> Thanks!
>> Mark
>>
>>
>>> On Sep 4, 2019, at 6:28 AM, Steve Zabele <zabele@comcast.net> wrote:
>>>
>>> Hi Willem,
>>>
>>> Thanks for continuing to poke at this, much appreciated!
>>>
>>>> As for the BPF program: good point on accessing the udp port when
>>>> skb->data is already beyond the header.
>>>
>>>> Programs of type sk_filter can use bpf_skb_load_bytes(_relative).
>>>> Which I think will work, but have not tested.
>>>
>>> Please note that the test code was intentionally set up to make testing as simple as possible. Hence the source addresses for the multiple UDP sessions were identical -- but that is not the general case. In the general case a connected and bound socket should be associated with exactly one five tuple (source and dest addresses, source and destination ports, and protocol.
>>>
>>> So a 'connect bpf' would actually need access to the IP addresses as well, not just the ports. To do this, the load bytes call required negative arguments, which failed miserably when we tried it.
>>>
>>> In any event, there remains the issue of figuring out which index to return when a match is detected since the index is not the same as the file descriptor value and in fact can change as file descriptors are added and deleted. If I understand the kernel mechanism correctly, the operation is something like this. When you add the first one, its assigned to the first slot; when you add the second its assigned to the second slot; when you delete the first one, the second is moved to the first slot) so tracking this requires figuring out the order stored in the socket array within the kernel, and updating the bpf whenever something changes. I don't know if it's even possible to query which slot a given
>>>
>>> So we think handling this with a bpf is really not viable.
>>>
>>> One thing worth mentioning is that the connect mechanism here is meant to (at least used to) work the same as connect does with TCP. Bind sets the expected/required local address and port; connect sets the expected/required remote address and port -- so a socket file descriptor becomes associated with exactly one five-tuple. That's how it's worked for several decades anyway.
>>>
>>> Thanks again!!!
>>>
>>> Steve
>>>
>>> -----Original Message-----
>>> From: Willem de Bruijn [mailto:willemdebruijn.kernel@gmail.com]
>>> Sent: Tuesday, September 03, 2019 1:56 PM
>>> Cc: Eric Dumazet; Steve Zabele; Network Development; shum@canndrew.org; vladimir116@gmail.com; saifi.khan@strikr.in; Daniel Borkmann; on2k16nm@gmail.com; Stephen Hemminger
>>> Subject: Re: Is bug 200755 in anyone's queue??
>>>
>>> On Fri, Aug 30, 2019 at 4:30 PM Willem de Bruijn
>>> <willemdebruijn.kernel@gmail.com> wrote:
>>>>
>>>>> On Fri, Aug 30, 2019 at 4:54 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 8/29/19 9:26 PM, Willem de Bruijn wrote:
>>>>>>
>>>>>> SO_REUSEPORT was not intended to be used in this way. Opening
>>>>>> multiple connected sockets with the same local port.
>>>>>>
>>>>>> But since the interface allowed connect after joining a group, and
>>>>>> that is being used, I guess that point is moot. Still, I'm a bit
>>>>>> surprised that it ever worked as described.
>>>>>>
>>>>>> Also note that the default distribution algorithm is not round robin
>>>>>> assignment, but hash based. So multiple consecutive datagrams arriving
>>>>>> at the same socket is not unexpected.
>>>>>>
>>>>>> I suspect that this quick hack might "work". It seemed to on the
>>>>>> supplied .c file:
>>>>>>
>>>>>> score = compute_score(sk, net, saddr, sport,
>>>>>> daddr, hnum, dif, sdif);
>>>>>> if (score > badness) {
>>>>>> - if (sk->sk_reuseport) {
>>>>>> + if (sk->sk_reuseport && !sk->sk_state !=
>>>>>> TCP_ESTABLISHED) {
>>>>
>>>> This won't work for a mix of connected and connectionless sockets, of
>>>> course (even ignoring the typo), as it only skips reuseport on the
>>>> connected sockets.
>>>>
>>>>>>
>>>>>> But a more robust approach, that also works on existing kernels, is to
>>>>>> swap the default distribution algorithm with a custom BPF based one (
>>>>>> SO_ATTACH_REUSEPORT_EBPF).
>>>>>>
>>>>>
>>>>> Yes, I suspect that reuseport could still be used by to load-balance incoming packets
>>>>> targetting the same 4-tuple.
>>>>>
>>>>> So all sockets would have the same score, and we would select the first socket in
>>>>> the list (if not applying reuseport hashing)
>>>>
>>>> Can you elaborate a bit?
>>>>
>>>> One option I see is to record in struct sock_reuseport if any port in
>>>> the group is connected and, if so, don't return immediately on the
>>>> first reuseport_select_sock hit, but continue the search for a higher
>>>> scoring connected socket.
>>>>
>>>> Or do return immediately, but do this refined search in
>>>> reuseport_select_sock itself, as it has a reference to all sockets in the
>>>> group in sock_reuseport->socks[]. Instead of the straightforward hash.
>>>
>>> That won't work, as reuseport_select_sock does not have access to
>>> protocol specific data, notably inet_dport.
>>>
>>> Unfortunately, what I've come up with so far is not concise and slows
>>> down existing reuseport lookup in a busy port table slot. Note that it
>>> is needed for both ipv4 and ipv6.
>>>
>>> Do not break out of the port table slot early, but continue to search
>>> for a higher scored match even after matching a reuseport:
>>>
>>> "
>>> @@ -413,28 +413,39 @@ static struct sock *udp4_lib_lookup2(struct net *net,
>>> struct udp_hslot *hslot2,
>>> struct sk_buff *skb)
>>> {
>>> + struct sock *reuseport_result = NULL;
>>> struct sock *sk, *result;
>>> + int reuseport_score = 0;
>>> int score, badness;
>>> u32 hash = 0;
>>>
>>> result = NULL;
>>> badness = 0;
>>> udp_portaddr_for_each_entry_rcu(sk, &hslot2->head) {
>>> score = compute_score(sk, net, saddr, sport,
>>> daddr, hnum, dif, sdif);
>>> if (score > badness) {
>>> - if (sk->sk_reuseport) {
>>> + if (sk->sk_reuseport &&
>>> + sk->sk_state != TCP_ESTABLISHED &&
>>> + !reuseport_result) {
>>> hash = udp_ehashfn(net, daddr, hnum,
>>> saddr, sport);
>>> - result = reuseport_select_sock(sk, hash, skb,
>>> + reuseport_result =
>>> reuseport_select_sock(sk, hash, skb,
>>> sizeof(struct udphdr));
>>> - if (result)
>>> - return result;
>>> + if (reuseport_result)
>>> + reuseport_score = score;
>>> + continue;
>>> }
>>> badness = score;
>>> result = sk;
>>> }
>>> }
>>> +
>>> + if (badness < reuseport_score)
>>> + result = reuseport_result;
>>> +
>>> return result;
>>> "
>>>
>>> To break out after the first reuseport hit when it is safe, i.e., when
>>> it holds no connected sockets, requires adding this state to struct
>>> reuseport_sock at __ip4_datagram_connect. And modify
>>> reuseport_select_sock to read this. At least, I have not found a more
>>> elegant solution.
>>>
>>>> Steve, Re: your point on a scalable QUIC server. That is an
>>>> interesting case certainly. Opening a connected socket per flow adds
>>>> both memory and port table pressure. I once looked into an SO_TXONLY
>>>> udp socket option that does not hash connected sockets into the port
>>>> table. In effect receiving on a small set of listening sockets (e.g.,
>>>> one per cpu) and sending over separate tx-only sockets. That still
>>>> introduces unnecessary memory allocation. OTOH it amortizes some
>>>> operations, such as route lookup.
>>>>
>>>> Anyway, that does not fix the immediate issue you reported when using
>>>> SO_REUSEPORT as described.
>>>
>>> As for the BPF program: good point on accessing the udp port when
>>> skb->data is already beyond the header.
>>>
>>> Programs of type sk_filter can use bpf_skb_load_bytes(_relative).
>>> Which I think will work, but have not tested.
>>>
>>> As of kernel 4.19 programs of type BPF_PROG_TYPE_SK_REUSEPORT can be
>>> attached (with CAP_SYS_ADMIN). See
>>> tools/testing/selftests/bpf/progs/test_select_reuseport_kern.c for an
>>> example that parses udp headers with bpf_skb_load_bytes.
>>>
^ permalink raw reply
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Sergey Senozhatsky @ 2019-09-04 14:48 UTC (permalink / raw)
To: Qian Cai
Cc: Sergey Senozhatsky, Michal Hocko, Eric Dumazet, davem, netdev,
linux-mm, linux-kernel, Petr Mladek, Sergey Senozhatsky,
Steven Rostedt
In-Reply-To: <1567599263.5576.72.camel@lca.pw>
On (09/04/19 08:14), Qian Cai wrote:
> > Plus one more check - waitqueue_active(&log_wait). printk() adds
> > pending irq_work only if there is a user-space process sleeping on
> > log_wait and irq_work is not already scheduled. If the syslog is
> > active or there is noone to wakeup then we don't queue irq_work.
>
> Another possibility for this potential livelock is that those printk() from
> warn_alloc(), dump_stack() and show_mem() increase the time it needs to process
> build_skb() allocation failures significantly under memory pressure. As the
> result, ksoftirqd() could be rescheduled during that time via a different CPU
> (this is a large x86 NUMA system anyway),
>
> [83605.577256][ C31] run_ksoftirqd+0x1f/0x40
> [83605.577256][ C31] smpboot_thread_fn+0x255/0x440
> [83605.577256][ C31] kthread+0x1df/0x200
> [83605.577256][ C31] ret_from_fork+0x35/0x40
Hum hum hum...
So I can, _probably_, think of several patches.
First, move wake_up_klogd() back to console_unlock().
Second, move `printk_pending' out of per-CPU region and make it global.
So we will have just one printk irq_work scheduled across all CPUs;
currently we have one irq_work per CPU. I think I sent a patch a long
long time ago, but we never discussed it, as far as I remember.
> In addition, those printk() will deal with console drivers or even a networking
> console, so it is probably not unusual that it could call irq_exit()-
>__do_softirq() at one point and then this livelock.
Do you use netcon? Because this, theoretically, can open up one more
vector. netcon allocates skbs from ->write() path. We call con drivers'
->write() from printk_safe context, so should netcon skb allocation
warn we will scedule one more irq_work on that CPU to flush per-CPU
printk_safe buffer.
If this is the case, then we can stop calling console_driver() under
printk_safe. I sent a patch a while ago, but we agreed to keep the
things the way they are, fot the time being.
Let me think more.
-ss
^ permalink raw reply
* Re: [Bridge] [PATCH v3 1/2] net: bridge: use mac_len in bridge forwarding
From: Zahari Doychev @ 2019-09-04 14:32 UTC (permalink / raw)
To: Toshiaki Makita
Cc: netdev, makita.toshiaki, jiri, nikolay, simon.horman, roopa,
bridge, jhs, dsahern, xiyou.wangcong, johannes,
alexei.starovoitov
In-Reply-To: <a9a093f2-1ec6-339c-b015-eb658618cf2b@gmail.com>
On Wed, Sep 04, 2019 at 04:14:28PM +0900, Toshiaki Makita wrote:
> On 2019/09/03 22:36, Zahari Doychev wrote:
> > On Tue, Sep 03, 2019 at 08:37:36PM +0900, Toshiaki Makita wrote:
> > > Hi Zahari,
> > >
> > > Sorry for reviewing this late.
> > >
> > > On 2019/09/03 3:09, Zahari Doychev wrote:
> > > ...
> > > > @@ -466,13 +466,14 @@ static bool __allowed_ingress(const struct net_bridge *br,
> > > > /* Tagged frame */
> > > > if (skb->vlan_proto != br->vlan_proto) {
> > > > /* Protocol-mismatch, empty out vlan_tci for new tag */
> > > > - skb_push(skb, ETH_HLEN);
> > > > + skb_push(skb, skb->mac_len);
> > > > skb = vlan_insert_tag_set_proto(skb, skb->vlan_proto,
> > > > skb_vlan_tag_get(skb));
> > >
> > > I think we should insert vlan at skb->data, i.e. mac_header + mac_len, while this
> > > function inserts the tag at mac_header + ETH_HLEN which is not always the correct
> > > offset.
> >
> > Maybe I am misunderstanding the concern here but this should make sure that
> > the VLAN tag from the skb is move back in the payload as the outer most tag.
> > So it should follow the ethernet header. It looks like this e.g.,:
> >
> > VLAN1 in skb:
> > +------+------+-------+
> > | DMAC | SMAC | ETYPE |
> > +------+------+-------+
> >
> > VLAN1 moved to payload:
> > +------+------+-------+-------+
> > | DMAC | SMAC | VLAN1 | ETYPE |
> > +------+------+-------+-------+
> >
> > VLAN2 in skb:
> > +------+------+-------+-------+
> > | DMAC | SMAC | VLAN1 | ETYPE |
> > +------+------+-------+-------+
> >
> > VLAN2 moved to payload:
> >
> > +------+------+-------+-------+
> > | DMAC | SMAC | VLAN2 | VLAN1 | ....
> > +------+------+-------+-------+
> >
> > Doing the skb push with mac_len makes sure that VLAN tag is inserted in the
> > correct offset. For mac_len == ETH_HLEN this does not change the current
> > behaviour.
>
> Reordering VLAN headers here does not look correct to me. If skb->data points to ETH+VLAN,
> then we should insert the vlan at the offset.
> Vlan devices with reorder_hdr disabled produce packets whose mac_len includes ETH+VLAN header,
> and they expects vlan insertion after the outer vlan header.
I see so in this case we should handle differently as it seems sometimes
we have to insert after or before the tag in the packet. I am not quite sure
if this is possible to be detected here. I was trying to do bridging with VLAN
devices with reorder_hdr disabled working but somehow I was not able to get
mac_len longer then ETH_HLEN in all cases that I tried. Can you provide some
example how can I try this out? It will really help me to understand the
problem better.
>
> Also I'm not sure there is standard ethernet header in mac_len, as mac_len is not ETH_HLEN.
> E.g. tun devices can produce vlan packets without ehternet header.
How is the bridge forwarding decision done in this case when there are no
MAC addresses, vlan based only?
>
> >
> > >
> > > > if (unlikely(!skb))
> > > > return false;
> > > > skb_pull(skb, ETH_HLEN);
> > >
> > > Now skb->data is mac_header + ETH_HLEN which would be broken when mac_len is not
> > > ETH_HLEN?
> >
> > I thought it would be better to point in this case to the outer tag as otherwise
> > if mac_len is used the skb->data will point to the next tag which I find somehow
> > inconsistent or do you see some case where this can cause problems?
>
> Vlan devices with reorder_hdr off will break because it relies on skb->data offset
> as I described in the previous discussion.
I also see in vlan_do_receive that the VLAN tag is moved to the payload when
reorder_hdr is off and the vlan_dev is not a bridge port. So it seems that
I am misunderstanding the reorder_hdr option so if you can give me some more
details about how it is supposed to be used will be highly appreciated.
Thanks
Zahari
>
> Toshiaki Makita
^ permalink raw reply
* Re: Is bug 200755 in anyone's queue??
From: Willem de Bruijn @ 2019-09-04 14:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mark KEATON, Steve Zabele, Willem de Bruijn, Network Development,
shum@canndrew.org, vladimir116@gmail.com, saifi.khan@strikr.in,
Daniel Borkmann, on2k16nm@gmail.com, Stephen Hemminger
In-Reply-To: <c3b83305-82a5-f3c8-2602-1aed2e9b51ca@gmail.com>
On Wed, Sep 4, 2019 at 8:23 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 9/4/19 2:00 PM, Mark KEATON wrote:
> > Hi Willem,
> >
> > I am the person who commented on the original bug report in bugzilla.
> >
> > In communicating with Steve just now about possible solutions that maintain the efficiency that you are after, what would you think of the following: keep two lists of UDP sockets, those connected and those not connected, and always searching the connected list first.
>
> This was my suggestion.
>
> Note that this requires adding yet another hash table, and yet another lookup
> (another cache line miss per incoming packet)
>
> This lookup will slow down DNS and QUIC servers, or any application solely using not connected sockets.
Exactly.
The only way around it that I see is to keep the single list and
optionally mark a struct reuseport_sock as having no connected
members, in which case the search can break on the first reuseport
match, as it does today.
"
On top of the main patch it requires something like
@@ -22,6 +22,7 @@ struct sock_reuseport {
/* ID stays the same even after the size of socks[] grows. */
unsigned int reuseport_id;
bool bind_inany;
+ unsigned int connected;
struct bpf_prog __rcu *prog; /* optional BPF sock selector */
struct sock *socks[0]; /* array of sock pointers */
};
@@ -73,6 +74,15 @@ int __ip4_datagram_connect(struct sock *sk, struct
sockaddr *uaddr, int addr_len
sk_set_txhash(sk);
inet->inet_id = jiffies;
+ if (rcu_access_pointer(sk->sk_reuseport_cb)) {
+ struct sock_reuseport *reuse;
+
+ rcu_read_lock();
+ reuse = rcu_dereference(sk->sk_reuseport_cb);
+ reuse->connected = 1;
+ rcu_read_unlock();
+ }
+
sk_dst_set(sk, &rt->dst);
err = 0;
"
plus a way for reuseport_select_sock to communicate that. Probably a
variant __reuseport_select_sock with an extra argument.
As for BPF: the example I pointed out does read ip addresses and uses
a BPF map for socket selection. But as that feature is new with 4.19
it is probably moot for this purpose, as we are targeting a fix that
can be backported to 4.19 stable.
^ permalink raw reply
* [PATCH] net: hns: Move static keyword to the front of declaration
From: Krzysztof Wilczynski @ 2019-09-04 14:21 UTC (permalink / raw)
To: Yisen Zhuang, Salil Mehta, David S. Miller, Yonglong Liu, Peng Li,
Greg Kroah-Hartman, Colin Ian King, Huang Zijiang,
Thomas Gleixner
Cc: netdev, linux-kernel
Move the static keyword to the front of declaration of g_dsaf_mode_match,
and resolve the following compiler warning that can be seen when building
with warnings enabled (W=1):
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:27:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
---
Related: https://lore.kernel.org/r/20190827233017.GK9987@google.com
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index c1eba421ba82..3a14bbc26ea2 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -24,7 +24,7 @@
#include "hns_dsaf_rcb.h"
#include "hns_dsaf_misc.h"
-const static char *g_dsaf_mode_match[DSAF_MODE_MAX] = {
+static const char *g_dsaf_mode_match[DSAF_MODE_MAX] = {
[DSAF_MODE_DISABLE_2PORT_64VM] = "2port-64vf",
[DSAF_MODE_DISABLE_6PORT_0VM] = "6port-16rss",
[DSAF_MODE_DISABLE_6PORT_16VM] = "6port-16vf",
--
2.22.1
^ permalink raw reply related
* Re: [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
From: Marcel Holtmann @ 2019-09-04 14:19 UTC (permalink / raw)
To: Maxime Ripard
Cc: megous, Chen-Yu Tsai, Rob Herring, Johan Hedberg, Mark Rutland,
David S. Miller, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-bluetooth
In-Reply-To: <20190830132034.u65arlv7umh64lx6@flea>
Hi Maxime,
>>>>> (Resend to add missing lists, sorry for the noise.)
>>>>>
>>>>> This series implements bluetooth support for Xunlong Orange Pi 3 board.
>>>>>
>>>>> The board uses AP6256 WiFi/BT 5.0 chip.
>>>>>
>>>>> Summary of changes:
>>>>>
>>>>> - add more delay to let initialize the chip
>>>>> - let the kernel detect firmware file path
>>>>> - add new compatible and update dt-bindings
>>>>> - update Orange Pi 3 / H6 DTS
>>>>>
>>>>> Please take a look.
>>>>>
>>>>> thank you and regards,
>>>>> Ondrej Jirman
>>>>>
>>>>> Ondrej Jirman (5):
>>>>> dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
>>>>> bluetooth: bcm: Add support for loading firmware for BCM4345C5
>>>>> bluetooth: hci_bcm: Give more time to come out of reset
>>>>> arm64: dts: allwinner: h6: Add pin configs for uart1
>>>>> arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
>>>>>
>>>>> .../bindings/net/broadcom-bluetooth.txt | 1 +
>>>>> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
>>>>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
>>>>> drivers/bluetooth/btbcm.c | 3 +++
>>>>> drivers/bluetooth/hci_bcm.c | 3 ++-
>>>>> 5 files changed, 35 insertions(+), 1 deletion(-)
>>>>
>>>> all 5 patches have been applied to bluetooth-next tree.
>>>
>>> The DTS patches (last 2) should go through the arm-soc tree, can you
>>> drop them?
>>
>> why is that? We have included DTS changes for Bluetooth devices
>> directly all the time. What is different with this hardware?
>
> I guess some maintainers are more relaxed with it than we are then,
> but for the why, well, it's the usual reasons, the most immediate one
> being that it reduces to a minimum the conflicts between trees.
>
> The other being that it's not really usual to merge patches supposed
> to be handled by another maintainer without (at least) his
> consent. I'm pretty sure you would have asked the same request if I
> would have merged the bluetooth patches through my tree without
> notice.
I took the two DTS patches out now and let the submitter deal with getting these merged.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: add myself as maintainer for xilinx axiethernet driver
From: Michal Simek @ 2019-09-04 14:18 UTC (permalink / raw)
To: Radhey Shyam Pandey, davem, netdev
Cc: michal.simek, anirudha.sarangi, linux, mchehab+samsung, gregkh,
nicolas.ferre, linux-arm-kernel, linux-kernel
In-Reply-To: <1567604658-9335-1-git-send-email-radhey.shyam.pandey@xilinx.com>
On 04. 09. 19 15:44, Radhey Shyam Pandey wrote:
> I am maintaining xilinx axiethernet driver in xilinx tree and would like
> to maintain it in the mainline kernel as well. Hence adding myself as a
> maintainer. Also Anirudha and John has moved to new roles, so based on
> request removing them from the maintainer list.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> Acked-by: John Linn <john.linn@xilinx.com>
> ---
> MAINTAINERS | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a081c47..74d5566 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17714,8 +17714,7 @@ F: include/uapi/linux/dqblk_xfs.h
> F: include/uapi/linux/fsmap.h
>
> XILINX AXI ETHERNET DRIVER
> -M: Anirudha Sarangi <anirudh@xilinx.com>
> -M: John Linn <John.Linn@xilinx.com>
> +M: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> S: Maintained
> F: drivers/net/ethernet/xilinx/xilinx_axienet*
>
>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Thanks,
Michal
^ permalink raw reply
* [PATCH] net: qed: Move static keyword to the front of declaration
From: Krzysztof Wilczynski @ 2019-09-04 14:17 UTC (permalink / raw)
To: Ariel Elior; +Cc: David S. Miller, GR-everest-linux-l2, netdev, linux-kernel
Move the static keyword to the front of declaration of iwarp_state_names,
and resolve the following compiler warning that can be seen when building
with warnings enabled (W=1):
drivers/net/ethernet/qlogic/qed/qed_iwarp.c:385:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Also, resolve checkpatch.pl script warning:
WARNING: static const char * array should probably be
static const char * const
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
---
Related: https://lore.kernel.org/r/20190827233017.GK9987@google.com
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index f380fae8799d..65ec16a31658 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -382,7 +382,7 @@ qed_iwarp2roce_state(enum qed_iwarp_qp_state state)
}
}
-const static char *iwarp_state_names[] = {
+static const char * const iwarp_state_names[] = {
"IDLE",
"RTS",
"TERMINATE",
--
2.22.1
^ permalink raw reply related
* [PATCH v3 net] net: Properly update v4 routes with v6 nexthop
From: Donald Sharp @ 2019-09-04 14:11 UTC (permalink / raw)
To: netdev, dsahern, sworley
When creating a v4 route that uses a v6 nexthop from a nexthop group.
Allow the kernel to properly send the nexthop as v6 via the RTA_VIA
attribute.
Broken behavior:
$ ip nexthop add via fe80::9 dev eth0
$ ip nexthop show
id 1 via fe80::9 dev eth0 scope link
$ ip route add 4.5.6.7/32 nhid 1
$ ip route show
default via 10.0.2.2 dev eth0
4.5.6.7 nhid 1 via 254.128.0.0 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
$
Fixed behavior:
$ ip nexthop add via fe80::9 dev eth0
$ ip nexthop show
id 1 via fe80::9 dev eth0 scope link
$ ip route add 4.5.6.7/32 nhid 1
$ ip route show
default via 10.0.2.2 dev eth0
4.5.6.7 nhid 1 via inet6 fe80::9 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
$
v2, v3: Addresses code review comments from David Ahern
Fixes: dcb1ecb50edf (“ipv4: Prepare for fib6_nh from a nexthop object”)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
---
include/net/ip_fib.h | 4 ++--
include/net/nexthop.h | 5 +++--
net/ipv4/fib_semantics.c | 15 ++++++++-------
net/ipv6/route.c | 11 ++++++-----
4 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 4c81846ccce8..ab1ca9e238d2 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -513,7 +513,7 @@ int ip_valid_fib_dump_req(struct net *net, const struct nlmsghdr *nlh,
struct netlink_callback *cb);
int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nh,
- unsigned char *flags, bool skip_oif);
+ u8 rt_family, unsigned char *flags, bool skip_oif);
int fib_add_nexthop(struct sk_buff *skb, const struct fib_nh_common *nh,
- int nh_weight);
+ int nh_weight, u8 rt_family);
#endif /* _NET_FIB_H */
diff --git a/include/net/nexthop.h b/include/net/nexthop.h
index 95f766c31c90..331ebbc94fe7 100644
--- a/include/net/nexthop.h
+++ b/include/net/nexthop.h
@@ -161,7 +161,8 @@ struct nexthop *nexthop_mpath_select(const struct nexthop *nh, int nhsel)
}
static inline
-int nexthop_mpath_fill_node(struct sk_buff *skb, struct nexthop *nh)
+int nexthop_mpath_fill_node(struct sk_buff *skb, struct nexthop *nh,
+ u8 rt_family)
{
struct nh_group *nhg = rtnl_dereference(nh->nh_grp);
int i;
@@ -172,7 +173,7 @@ int nexthop_mpath_fill_node(struct sk_buff *skb, struct nexthop *nh)
struct fib_nh_common *nhc = &nhi->fib_nhc;
int weight = nhg->nh_entries[i].weight;
- if (fib_add_nexthop(skb, nhc, weight) < 0)
+ if (fib_add_nexthop(skb, nhc, weight, rt_family) < 0)
return -EMSGSIZE;
}
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 2db089e10ba0..0913a090b2bf 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1582,7 +1582,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg,
}
int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nhc,
- unsigned char *flags, bool skip_oif)
+ u8 rt_family, unsigned char *flags, bool skip_oif)
{
if (nhc->nhc_flags & RTNH_F_DEAD)
*flags |= RTNH_F_DEAD;
@@ -1613,7 +1613,7 @@ int fib_nexthop_info(struct sk_buff *skb, const struct fib_nh_common *nhc,
/* if gateway family does not match nexthop family
* gateway is encoded as RTA_VIA
*/
- if (nhc->nhc_gw_family != nhc->nhc_family) {
+ if (rt_family != nhc->nhc_gw_family) {
int alen = sizeof(struct in6_addr);
struct nlattr *nla;
struct rtvia *via;
@@ -1654,7 +1654,7 @@ EXPORT_SYMBOL_GPL(fib_nexthop_info);
#if IS_ENABLED(CONFIG_IP_ROUTE_MULTIPATH) || IS_ENABLED(CONFIG_IPV6)
int fib_add_nexthop(struct sk_buff *skb, const struct fib_nh_common *nhc,
- int nh_weight)
+ int nh_weight, u8 rt_family)
{
const struct net_device *dev = nhc->nhc_dev;
struct rtnexthop *rtnh;
@@ -1667,7 +1667,7 @@ int fib_add_nexthop(struct sk_buff *skb, const struct fib_nh_common *nhc,
rtnh->rtnh_hops = nh_weight - 1;
rtnh->rtnh_ifindex = dev ? dev->ifindex : 0;
- if (fib_nexthop_info(skb, nhc, &flags, true) < 0)
+ if (fib_nexthop_info(skb, nhc, rt_family, &flags, true) < 0)
goto nla_put_failure;
rtnh->rtnh_flags = flags;
@@ -1693,13 +1693,14 @@ static int fib_add_multipath(struct sk_buff *skb, struct fib_info *fi)
goto nla_put_failure;
if (unlikely(fi->nh)) {
- if (nexthop_mpath_fill_node(skb, fi->nh) < 0)
+ if (nexthop_mpath_fill_node(skb, fi->nh, AF_INET) < 0)
goto nla_put_failure;
goto mp_end;
}
for_nexthops(fi) {
- if (fib_add_nexthop(skb, &nh->nh_common, nh->fib_nh_weight) < 0)
+ if (fib_add_nexthop(skb, &nh->nh_common, nh->fib_nh_weight,
+ AF_INET) < 0)
goto nla_put_failure;
#ifdef CONFIG_IP_ROUTE_CLASSID
if (nh->nh_tclassid &&
@@ -1775,7 +1776,7 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
const struct fib_nh_common *nhc = fib_info_nhc(fi, 0);
unsigned char flags = 0;
- if (fib_nexthop_info(skb, nhc, &flags, false) < 0)
+ if (fib_nexthop_info(skb, nhc, AF_INET, &flags, false) < 0)
goto nla_put_failure;
rtm->rtm_flags = flags;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index fd059e08785a..cfb969e68d45 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5329,7 +5329,7 @@ static int rt6_fill_node_nexthop(struct sk_buff *skb, struct nexthop *nh,
if (!mp)
goto nla_put_failure;
- if (nexthop_mpath_fill_node(skb, nh))
+ if (nexthop_mpath_fill_node(skb, nh, AF_INET6))
goto nla_put_failure;
nla_nest_end(skb, mp);
@@ -5337,7 +5337,7 @@ static int rt6_fill_node_nexthop(struct sk_buff *skb, struct nexthop *nh,
struct fib6_nh *fib6_nh;
fib6_nh = nexthop_fib6_nh(nh);
- if (fib_nexthop_info(skb, &fib6_nh->nh_common,
+ if (fib_nexthop_info(skb, &fib6_nh->nh_common, AF_INET6,
flags, false) < 0)
goto nla_put_failure;
}
@@ -5466,13 +5466,14 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
if (fib_add_nexthop(skb, &rt->fib6_nh->nh_common,
- rt->fib6_nh->fib_nh_weight) < 0)
+ rt->fib6_nh->fib_nh_weight, AF_INET6) < 0)
goto nla_put_failure;
list_for_each_entry_safe(sibling, next_sibling,
&rt->fib6_siblings, fib6_siblings) {
if (fib_add_nexthop(skb, &sibling->fib6_nh->nh_common,
- sibling->fib6_nh->fib_nh_weight) < 0)
+ sibling->fib6_nh->fib_nh_weight,
+ AF_INET6) < 0)
goto nla_put_failure;
}
@@ -5489,7 +5490,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
rtm->rtm_flags |= nh_flags;
} else {
- if (fib_nexthop_info(skb, &rt->fib6_nh->nh_common,
+ if (fib_nexthop_info(skb, &rt->fib6_nh->nh_common, AF_INET6,
&nh_flags, false) < 0)
goto nla_put_failure;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/2] net: gmii2rgmii: Switch priv field in mdio device structure
From: Harini Katakam @ 2019-09-04 14:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: Harini Katakam, Florian Fainelli, Heiner Kallweit, David Miller,
Michal Simek, netdev, linux-arm-kernel, linux-kernel,
radhey.shyam.pandey
In-Reply-To: <20190813153820.GY14290@lunn.ch>
Hi Andrew,
On Tue, Aug 13, 2019 at 9:40 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > The kernel does have a few helper, spi_get_drvdata, pci_get_drvdata,
> > > hci_get_drvdata. So maybe had add phydev_get_drvdata(struct phy_device
> > > *phydev)?
> >
> > Maybe phydev_mdio_get_drvdata? Because the driver data member available is
> > phydev->mdio.dev.driver_data.
>
> I still prefer phydev_get_drvdata(). It fits with the X_get_drvdata()
> pattern, where X is the type of parameter passed to the call, spi,
> pci, hci.
>
> We can also add mdiodev_get_drvdata(mdiodev). A few DSA drivers could
> use that.
Sorry for the late reply. I just sent a v2 adding
mdiodev_get/set_drvdata helpers
and using them in gmii2rgmii driver.
I did not add a corresponding phydev helper because there is no "struct dev" in
"struct phy_device" and I dint know if there were any users to add the member
and then a helper for driver data. Also,
strutct phy_device { struct mdio_device { struct device }}
is already available and it seemed logical to use that field to
set/get driver data
for gmii2rgmii. Please let me know if v2 is okay.
Regards,
Harini
^ permalink raw reply
* [PATCH net-next 4/7] net: hns3: add client node validity judgment
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Peng Li, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
From: Peng Li <lipeng321@huawei.com>
HNS3 driver can only unregister client which included in hnae3_client_list.
This patch adds the client node validity judgment.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 528f624..6aa5257 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -138,12 +138,28 @@ EXPORT_SYMBOL(hnae3_register_client);
void hnae3_unregister_client(struct hnae3_client *client)
{
+ struct hnae3_client *client_tmp;
struct hnae3_ae_dev *ae_dev;
+ bool existed = false;
if (!client)
return;
mutex_lock(&hnae3_common_lock);
+
+ list_for_each_entry(client_tmp, &hnae3_client_list, node) {
+ if (client_tmp->type == client->type) {
+ existed = true;
+ break;
+ }
+ }
+
+ if (!existed) {
+ mutex_unlock(&hnae3_common_lock);
+ pr_err("client %s not existed!\n", client->name);
+ return;
+ }
+
/* un-initialize the client on every matched port */
list_for_each_entry(ae_dev, &hnae3_ae_dev_list, node) {
hnae3_uninit_client_instance(client, ae_dev);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/7] net: hns3: add some bugfixes and cleanups
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
This patch-set includes bugfixes and cleanups for the HNS3
ethernet controller driver.
[patch 01/07] fixes an error when setting VLAN offload.
[patch 02/07] fixes an double free issue when setting ringparam.
[patch 03/07] fixes a mis-assignment of hdev->reset_level.
[patch 04/07] adds a checking for client's validity.
[patch 05/07] simplifies bool variable's assignment.
[patch 06/07] disables loopback when initializing.
[patch 07/07] makes internal function to static.
Guojia Liao (2):
net: hns3: remove explicit conversion to bool
net: hns3: make hclge_dbg_get_m7_stats_info static
Huazhong Tan (2):
net: hns3: fix double free bug when setting ringparam
net: hns3: fix mis-assignment to hdev->reset_level in hclge_reset
Jian Shen (1):
net: hns3: fix error VF index when setting VLAN offload
Peng Li (1):
net: hns3: add client node validity judgment
Yufeng Mo (1):
net: hns3: disable loopback setting in hclge_mac_init
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 16 ++++++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 59 ++++++++++++++++++----
4 files changed, 69 insertions(+), 12 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next 5/7] net: hns3: remove explicit conversion to bool
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
Relational and logical operators evaluate to bool,
explicit conversion is overly verbose and unnecessary.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 76e1c84..dde752f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -6174,7 +6174,7 @@ static void hclge_enable_fd(struct hnae3_handle *handle, bool enable)
bool clear;
hdev->fd_en = enable;
- clear = hdev->fd_active_type == HCLGE_FD_ARFS_ACTIVE ? true : false;
+ clear = hdev->fd_active_type == HCLGE_FD_ARFS_ACTIVE;
if (!enable)
hclge_del_all_fd_entries(handle, clear);
else
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/7] net: hns3: fix double free bug when setting ringparam
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
The system will panic when change the ringparam in HNS3 drivers:
[ 1459.627727] hns3 0000:bd:00.0 eth6: Changing Tx/Rx ring ds from 1024/1024 to 24/24
[ 1459.635766] hns3 0000:bd:00.0 eth6: link down
[ 1459.640788] BUG: Bad page state in process ethtool pfn:203f75c18
[ 1459.646940] page:ffff7ee4ffd70600 refcount:0 mapcount:0 mapping:ffff993fff40f400 index:0x0 compound_mapcount: 0
[ 1459.656987] flags: 0x9fffe00000010200(slab|head)
[ 1459.661591] raw: 9fffe00000010200 dead000000000100 dead000000000122 ffff993fff40f400
[ 1459.669302] raw: 0000000000000000 0000000080100010 00000000ffffffff 0000000000000000
[ 1459.677016] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
[ 1459.683432] bad because of flags: 0x200(slab)
[ 1459.687775] Modules linked in: ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi hns_roce_hw_v2 crct10dif_ce hns3 ses hclge hnae3 hisi_hpre hisi_zip qm uacce ip_tables x_tables hisi_sas_v3_hw hisi_sas_main libsas scsi_transport_sas
[ 1459.709329] CPU: 14 PID: 17244 Comm: ethtool Tainted: G O 5.3.0-rc4-00415-gc86f057 #1
[ 1459.718419] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B040.01 07/26/2019
[ 1459.727248] Call trace:
[ 1459.729688] dump_backtrace+0x0/0x150
[ 1459.733335] show_stack+0x24/0x30
[ 1459.736639] dump_stack+0xa0/0xc4
[ 1459.739943] bad_page+0xf0/0x158
[ 1459.743157] free_pages_check_bad+0x84/0xa0
[ 1459.747322] __free_pages_ok+0x348/0x378
[ 1459.751228] page_frag_free+0x80/0x88
[ 1459.754877] skb_free_head+0x38/0x48
[ 1459.758436] skb_release_data+0x134/0x160
[ 1459.762427] skb_release_all+0x30/0x40
[ 1459.766158] consume_skb+0x38/0x108
[ 1459.769633] __dev_kfree_skb_any+0x58/0x68
[ 1459.773718] hns3_fini_ring+0x48/0x58 [hns3]
[ 1459.777970] hns3_set_ringparam+0x2a8/0x418 [hns3]
[ 1459.782741] dev_ethtool+0x5f4/0x2080
[ 1459.786390] dev_ioctl+0x190/0x3d8
[ 1459.789777] sock_do_ioctl+0xf8/0x220
[ 1459.793423] sock_ioctl+0x3bc/0x490
[ 1459.796896] do_vfs_ioctl+0xc4/0x868
[ 1459.800454] ksys_ioctl+0x8c/0xa0
[ 1459.803752] __arm64_sys_ioctl+0x28/0x38
[ 1459.807658] el0_svc_common.constprop.0+0xe0/0x1e0
[ 1459.812426] el0_svc_handler+0x34/0x90
[ 1459.816158] el0_svc+0x10/0x14
[ 1459.819220] Disabling lock debugging due to kernel taint
[ 1459.825182] ------------[ cut here ]------------
Since ndo_stop will reclaim the RX's skb allocated by the driver,
so the backed up ring parameter should not keep this info.
Fixes: a723fb8efe29 ("net: hns3: refine for set ring parameters")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index c52eccc..aa692b1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -908,9 +908,11 @@ static struct hns3_enet_ring *hns3_backup_ringparam(struct hns3_nic_priv *priv)
if (!tmp_rings)
return NULL;
- for (i = 0; i < handle->kinfo.num_tqps * 2; i++)
+ for (i = 0; i < handle->kinfo.num_tqps * 2; i++) {
memcpy(&tmp_rings[i], priv->ring_data[i].ring,
sizeof(struct hns3_enet_ring));
+ tmp_rings[i].skb = NULL;
+ }
return tmp_rings;
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/7] net: hns3: fix mis-assignment to hdev->reset_level in hclge_reset
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
Since hclge_get_reset_level may return HNAE3_NONE_RESET,
so hdev->reset_level can not be assigned with the return
value in the hclge_reset(), otherwise, it will cause
the use of hdev->reset_level in hclge_reset_event get
into error.
Fixes: 012fcb52f67c ("net: hns3: activate reset timer when calling reset_event")
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 0e1225c..76e1c84 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3619,6 +3619,7 @@ static int hclge_reset_stack(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
+ enum hnae3_reset_type reset_level;
int ret;
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3697,10 +3698,10 @@ static void hclge_reset(struct hclge_dev *hdev)
* it should be handled as soon as possible. since some errors
* need this kind of reset to fix.
*/
- hdev->reset_level = hclge_get_reset_level(ae_dev,
- &hdev->default_reset_request);
- if (hdev->reset_level != HNAE3_NONE_RESET)
- set_bit(hdev->reset_level, &hdev->reset_request);
+ reset_level = hclge_get_reset_level(ae_dev,
+ &hdev->default_reset_request);
+ if (reset_level != HNAE3_NONE_RESET)
+ set_bit(reset_level, &hdev->reset_request);
return;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 7/7] net: hns3: make hclge_dbg_get_m7_stats_info static
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Guojia Liao, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
From: Guojia Liao <liaoguojia@huawei.com>
hclge_dbg_get_m7_info is used only in the hclge_debugfs.c,
so it should be declared with static.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index 1c6b501..6dcce48 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -949,7 +949,7 @@ static void hclge_dbg_dump_rst_info(struct hclge_dev *hdev)
hdev->rst_stats.reset_cnt);
}
-void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
+static void hclge_dbg_get_m7_stats_info(struct hclge_dev *hdev)
{
struct hclge_desc *desc_src, *desc_tmp;
struct hclge_get_m7_bd_cmd *req;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 6/7] net: hns3: disable loopback setting in hclge_mac_init
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Yufeng Mo, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
From: Yufeng Mo <moyufeng@huawei.com>
If the selftest and reset are performed at the same time, the loopback
setting may be still in the enable state after the reset. As a result,
packets cannot be sent out.
This patch fixes this issue by disabling loopback in hclge_mac_init.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 34 +++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index dde752f..8d4dc1b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -66,6 +66,7 @@ static void hclge_rfs_filter_expire(struct hclge_dev *hdev);
static void hclge_clear_arfs_rules(struct hnae3_handle *handle);
static enum hnae3_reset_type hclge_get_reset_level(struct hnae3_ae_dev *ae_dev,
unsigned long *addr);
+static int hclge_set_default_loopback(struct hclge_dev *hdev);
static struct hnae3_ae_algo ae_algo;
@@ -2599,6 +2600,10 @@ static int hclge_mac_init(struct hclge_dev *hdev)
return ret;
}
+ ret = hclge_set_default_loopback(hdev);
+ if (ret)
+ return ret;
+
ret = hclge_buffer_alloc(hdev);
if (ret)
dev_err(&hdev->pdev->dev,
@@ -6331,7 +6336,7 @@ static int hclge_set_app_loopback(struct hclge_dev *hdev, bool en)
return ret;
}
-static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
+static int hclge_cfg_serdes_loopback(struct hclge_dev *hdev, bool en,
enum hnae3_loop loop_mode)
{
#define HCLGE_SERDES_RETRY_MS 10
@@ -6392,6 +6397,17 @@ static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
dev_err(&hdev->pdev->dev, "serdes loopback set failed in fw\n");
return -EIO;
}
+ return ret;
+}
+
+static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
+ enum hnae3_loop loop_mode)
+{
+ int ret;
+
+ ret = hclge_cfg_serdes_loopback(hdev, en, loop_mode);
+ if (ret)
+ return ret;
hclge_cfg_mac_mode(hdev, en);
@@ -6535,6 +6551,22 @@ static int hclge_set_loopback(struct hnae3_handle *handle,
return 0;
}
+static int hclge_set_default_loopback(struct hclge_dev *hdev)
+{
+ int ret;
+
+ ret = hclge_set_app_loopback(hdev, false);
+ if (ret)
+ return ret;
+
+ ret = hclge_cfg_serdes_loopback(hdev, false, HNAE3_LOOP_SERIAL_SERDES);
+ if (ret)
+ return ret;
+
+ return hclge_cfg_serdes_loopback(hdev, false,
+ HNAE3_LOOP_PARALLEL_SERDES);
+}
+
static void hclge_reset_tqp_stats(struct hnae3_handle *handle)
{
struct hclge_vport *vport = hclge_get_vport(handle);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/7] net: hns3: fix error VF index when setting VLAN offload
From: Huazhong Tan @ 2019-09-04 14:06 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski, Jian Shen, Huazhong Tan
In-Reply-To: <1567606006-39598-1-git-send-email-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
In original codes, the VF index used incorrectly in function
hclge_set_vlan_rx_offload_cfg() and hclge_set_vlan_rx_offload_cfg().
When VF id is greater than 8, for example 9, it will set the
same bit with VF id 1.
This patch fixes it by using vport->vport_id % HCLGE_VF_NUM_PER_CMD /
HCLGE_VF_NUM_PER_BYTE as the array index, intead of vport->vport_id /
HCLGE_VF_NUM_PER_CMD.
Fixes: 052ece6dc19c ("net: hns3: add ethtool related offload command")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 2b65f27..0e1225c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -7691,6 +7691,7 @@ static int hclge_set_vlan_tx_offload_cfg(struct hclge_vport *vport)
struct hclge_vport_vtag_tx_cfg_cmd *req;
struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
+ u16 bmap_index;
int status;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_VLAN_PORT_TX_CFG, false);
@@ -7713,8 +7714,10 @@ static int hclge_set_vlan_tx_offload_cfg(struct hclge_vport *vport)
hnae3_set_bit(req->vport_vlan_cfg, HCLGE_CFG_NIC_ROCE_SEL_B, 0);
req->vf_offset = vport->vport_id / HCLGE_VF_NUM_PER_CMD;
- req->vf_bitmap[req->vf_offset] =
- 1 << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
+ bmap_index = vport->vport_id % HCLGE_VF_NUM_PER_CMD /
+ HCLGE_VF_NUM_PER_BYTE;
+ req->vf_bitmap[bmap_index] =
+ 1U << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
status = hclge_cmd_send(&hdev->hw, &desc, 1);
if (status)
@@ -7731,6 +7734,7 @@ static int hclge_set_vlan_rx_offload_cfg(struct hclge_vport *vport)
struct hclge_vport_vtag_rx_cfg_cmd *req;
struct hclge_dev *hdev = vport->back;
struct hclge_desc desc;
+ u16 bmap_index;
int status;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_VLAN_PORT_RX_CFG, false);
@@ -7746,8 +7750,10 @@ static int hclge_set_vlan_rx_offload_cfg(struct hclge_vport *vport)
vcfg->vlan2_vlan_prionly ? 1 : 0);
req->vf_offset = vport->vport_id / HCLGE_VF_NUM_PER_CMD;
- req->vf_bitmap[req->vf_offset] =
- 1 << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
+ bmap_index = vport->vport_id % HCLGE_VF_NUM_PER_CMD /
+ HCLGE_VF_NUM_PER_BYTE;
+ req->vf_bitmap[bmap_index] =
+ 1U << (vport->vport_id % HCLGE_VF_NUM_PER_BYTE);
status = hclge_cmd_send(&hdev->hw, &desc, 1);
if (status)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net-next] net: stmmac: Add support for MDIO interrupts
From: Voon Weifeng @ 2019-09-04 14:02 UTC (permalink / raw)
To: David S. Miller, Maxime Coquelin
Cc: netdev, linux-kernel, Jose Abreu, Giuseppe Cavallaro, Andrew Lunn,
Alexandre Torgue, Ong Boon Leong, Voon Weifeng
From: "Chuah, Kim Tatt" <kim.tatt.chuah@intel.com>
DW EQoS v5.xx controllers added capability for interrupt generation
when MDIO interface is done (GMII Busy bit is cleared).
This patch adds support for this interrupt on supported HW to avoid
polling on GMII Busy bit.
stmmac_mdio_read() & stmmac_mdio_write() will sleep until wake_up() is
called by the interrupt handler.
Reviewed-by: Voon Weifeng <weifeng.voon@intel.com>
Reviewed-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Chuah, Kim Tatt <kim.tatt.chuah@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 49aa56ca09cc..775a1c114b1a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -448,6 +448,8 @@ struct mac_device_info {
unsigned int pcs;
unsigned int pmt;
unsigned int ps;
+ bool mdio_intr_en;
+ wait_queue_head_t mdio_busy_wait;
};
struct stmmac_rx_routing {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 2ed11a581d80..1be6a8a88b8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -106,6 +106,7 @@ enum dwmac4_irq_status {
mmc_irq = 0x00000100,
lpi_irq = 0x00000020,
pmt_irq = 0x00000010,
+ mdio_irq = 0x00040000,
};
/* MAC PMT bitmap */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index fc9954e4a772..97fca6d65141 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -59,6 +59,9 @@ static void dwmac4_core_init(struct mac_device_info *hw,
if (hw->pcs)
value |= GMAC_PCS_IRQ_DEFAULT;
+ if (hw->mdio_intr_en)
+ value |= GMAC_INT_MDIO_EN;
+
writel(value, ioaddr + GMAC_INT_EN);
}
@@ -629,6 +632,9 @@ static int dwmac4_irq_status(struct mac_device_info *hw,
x->irq_rx_path_exit_lpi_mode_n++;
}
+ if (intr_status & mdio_irq)
+ wake_up(&hw->mdio_busy_wait);
+
dwmac_pcs_isr(ioaddr, GMAC_PCS_BASE, intr_status, x);
if (intr_status & PCS_RGSMIIIS_IRQ)
dwmac4_phystatus(ioaddr, x);
@@ -836,6 +842,7 @@ static void dwmac4_set_mac_loopback(void __iomem *ioaddr, bool enable)
.rxp_config = dwmac5_rxp_config,
.flex_pps_config = dwmac5_flex_pps_config,
.set_mac_loopback = dwmac4_set_mac_loopback,
+ .mdio_intr_dis = dwmac5_mdio_intr_dis,
};
int dwmac4_setup(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
index 3f4f3132e16b..c58751e1dcb6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
@@ -549,3 +549,11 @@ int dwmac5_flex_pps_config(void __iomem *ioaddr, int index,
writel(val, ioaddr + MAC_PPS_CONTROL);
return 0;
}
+
+void dwmac5_mdio_intr_dis(void __iomem *ioaddr)
+{
+ u32 val = readl(ioaddr + GMAC_INT_EN);
+
+ val &= ~GMAC_INT_MDIO_EN;
+ writel(val, ioaddr + GMAC_INT_EN);
+}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.h b/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
index 775db776b3cc..a56511a4c97d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
@@ -72,6 +72,9 @@
#define TCEIE BIT(0)
#define DMA_ECC_INT_STATUS 0x00001088
+/* MDIO interrupt enable in MAC_Interrupt_Enable register */
+#define GMAC_INT_MDIO_EN BIT(18)
+
int dwmac5_safety_feat_config(void __iomem *ioaddr, unsigned int asp);
int dwmac5_safety_feat_irq_status(struct net_device *ndev,
void __iomem *ioaddr, unsigned int asp,
@@ -83,5 +86,6 @@ int dwmac5_rxp_config(void __iomem *ioaddr, struct stmmac_tc_entry *entries,
int dwmac5_flex_pps_config(void __iomem *ioaddr, int index,
struct stmmac_pps_cfg *cfg, bool enable,
u32 sub_second_inc, u32 systime_flags);
+void dwmac5_mdio_intr_dis(void __iomem *ioaddr);
#endif /* __DWMAC5_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 3af2e5015245..7127efe652db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -73,6 +73,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
bool gmac;
bool gmac4;
bool xgmac;
+ bool mdio_intr_en;
u32 min_id;
const struct stmmac_regs_off regs;
const void *desc;
@@ -90,6 +91,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = false,
.gmac4 = false,
.xgmac = false,
+ .mdio_intr_en = false,
.min_id = 0,
.regs = {
.ptp_off = PTP_GMAC3_X_OFFSET,
@@ -108,6 +110,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = true,
.gmac4 = false,
.xgmac = false,
+ .mdio_intr_en = false,
.min_id = 0,
.regs = {
.ptp_off = PTP_GMAC3_X_OFFSET,
@@ -126,6 +129,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = false,
.gmac4 = true,
.xgmac = false,
+ .mdio_intr_en = false,
.min_id = 0,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
@@ -144,6 +148,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = false,
.gmac4 = true,
.xgmac = false,
+ .mdio_intr_en = false,
.min_id = DWMAC_CORE_4_00,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
@@ -162,6 +167,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = false,
.gmac4 = true,
.xgmac = false,
+ .mdio_intr_en = false,
.min_id = DWMAC_CORE_4_10,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
@@ -180,6 +186,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = false,
.gmac4 = true,
.xgmac = false,
+ .mdio_intr_en = true,
.min_id = DWMAC_CORE_5_10,
.regs = {
.ptp_off = PTP_GMAC4_OFFSET,
@@ -198,6 +205,7 @@ static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
.gmac = false,
.gmac4 = false,
.xgmac = true,
+ .mdio_intr_en = false,
.min_id = DWXGMAC_CORE_2_10,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
@@ -276,6 +284,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
mac->mode = mac->mode ? : entry->mode;
mac->tc = mac->tc ? : entry->tc;
mac->mmc = mac->mmc ? : entry->mmc;
+ mac->mdio_intr_en = mac->mdio_intr_en ? : entry->mdio_intr_en;
priv->hw = mac;
priv->ptpaddr = priv->ioaddr + entry->regs.ptp_off;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 9435b312495d..d42885426e78 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -363,6 +363,8 @@ struct stmmac_ops {
int (*get_mac_tx_timestamp)(struct mac_device_info *hw, u64 *ts);
/* Source Address Insertion / Replacement */
void (*sarc_configure)(void __iomem *ioaddr, int val);
+ /* Disable mdio interrupt */
+ void (*mdio_intr_dis)(void __iomem *ioaddr);
};
#define stmmac_core_init(__priv, __args...) \
@@ -443,6 +445,8 @@ struct stmmac_ops {
stmmac_do_callback(__priv, mac, get_mac_tx_timestamp, __args)
#define stmmac_sarc_configure(__priv, __args...) \
stmmac_do_void_callback(__priv, mac, sarc_configure, __args)
+#define stmmac_mdio_intr_dis(__priv, __args...) \
+ stmmac_do_void_callback(__priv, mac, mdio_intr_dis, __args)
/* PTP and HW Timer helpers */
struct stmmac_hwtimestamp {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 06ccd216ae90..2557a2beb03d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2768,6 +2768,8 @@ static int stmmac_release(struct net_device *dev)
phylink_stop(priv->phylink);
phylink_disconnect_phy(priv->phylink);
+ stmmac_mdio_intr_dis(priv, priv->ioaddr);
+
stmmac_stop_all_queues(priv);
stmmac_disable_all_queues(priv);
@@ -4463,6 +4465,9 @@ int stmmac_dvr_probe(struct device *device,
if (ret)
goto error_hw_init;
+ /* mdio intr wait queue */
+ init_waitqueue_head(&priv->hw->mdio_busy_wait);
+
stmmac_check_ether_addr(priv);
/* Configure real RX and TX queues */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 40c42637ad75..625e1fde0c86 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -19,6 +19,8 @@
#include <linux/property.h>
#include <linux/slab.h>
+#include "dwmac4.h"
+#include "dwmac5.h"
#include "dwxgmac2.h"
#include "stmmac.h"
@@ -142,6 +144,18 @@ static int stmmac_xgmac2_mdio_write(struct mii_bus *bus, int phyaddr,
!(tmp & MII_XGMAC_BUSY), 100, 10000);
}
+static bool stmmac_mdio_intr_done(struct mii_bus *bus)
+{
+ struct net_device *ndev = bus->priv;
+ struct stmmac_priv *priv;
+ unsigned int mii_address;
+
+ priv = netdev_priv(ndev);
+ mii_address = priv->hw->mii.addr;
+
+ return !(readl(priv->ioaddr + mii_address) & MII_BUSY);
+}
+
/**
* stmmac_mdio_read
* @bus: points to the mii_bus structure
@@ -159,9 +173,11 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
u32 value = MII_BUSY;
+ u32 mdio_intr_en = 0;
int data = 0;
u32 v;
+ mdio_intr_en = readl(priv->ioaddr + GMAC_INT_EN) & GMAC_INT_MDIO_EN;
value |= (phyaddr << priv->hw->mii.addr_shift)
& priv->hw->mii.addr_mask;
value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
@@ -181,16 +197,26 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
}
}
- if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
- 100, 10000))
+ if (mdio_intr_en) {
+ if (!wait_event_timeout(priv->hw->mdio_busy_wait,
+ stmmac_mdio_intr_done(bus), HZ / 100))
+ return -EBUSY;
+ } else if (readl_poll_timeout(priv->ioaddr + mii_address, v,
+ !(v & MII_BUSY), 100, 10000)) {
return -EBUSY;
+ }
writel(data, priv->ioaddr + mii_data);
writel(value, priv->ioaddr + mii_address);
- if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
- 100, 10000))
+ if (mdio_intr_en) {
+ if (!wait_event_timeout(priv->hw->mdio_busy_wait,
+ stmmac_mdio_intr_done(bus), HZ / 100))
+ return -EBUSY;
+ } else if (readl_poll_timeout(priv->ioaddr + mii_address, v,
+ !(v & MII_BUSY), 100, 10000)) {
return -EBUSY;
+ }
/* Read the data from the MII data register */
data = (int)readl(priv->ioaddr + mii_data) & MII_DATA_MASK;
@@ -214,9 +240,11 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
u32 value = MII_BUSY;
+ u32 mdio_intr_en = 0;
int data = phydata;
u32 v;
+ mdio_intr_en = readl(priv->ioaddr + GMAC_INT_EN) & GMAC_INT_MDIO_EN;
value |= (phyaddr << priv->hw->mii.addr_shift)
& priv->hw->mii.addr_mask;
value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
@@ -240,17 +268,30 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
}
/* Wait until any existing MII operation is complete */
- if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
- 100, 10000))
+ if (mdio_intr_en) {
+ if (!wait_event_timeout(priv->hw->mdio_busy_wait,
+ stmmac_mdio_intr_done(bus), HZ / 100))
+ return -EBUSY;
+ } else if (readl_poll_timeout(priv->ioaddr + mii_address, v,
+ !(v & MII_BUSY), 100, 10000)) {
return -EBUSY;
+ }
/* Set the MII address register to write */
writel(data, priv->ioaddr + mii_data);
writel(value, priv->ioaddr + mii_address);
/* Wait until any existing MII operation is complete */
- return readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
- 100, 10000);
+ if (mdio_intr_en) {
+ if (!wait_event_timeout(priv->hw->mdio_busy_wait,
+ stmmac_mdio_intr_done(bus), HZ / 100))
+ return -EBUSY;
+ } else if (readl_poll_timeout(priv->ioaddr + mii_address, v,
+ !(v & MII_BUSY), 100, 10000)) {
+ return -EBUSY;
+ }
+
+ return 0;
}
/**
--
Changelog v2
*mdio interrupt mode or polling mode will depends on mdio interrupt enable bit
*Disable the mdio interrupt enable bit in stmmac_release
*Remove the condition for initialize wait queues
*Applied reverse Christmas tree
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] net: phy: gmii2rgmii: Dont use priv field in phy device
From: Harini Katakam @ 2019-09-04 14:00 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem
Cc: michal.simek, netdev, linux-arm-kernel, linux-kernel,
harinikatakamlinux, harini.katakam, radhey.shyam.pandey
In-Reply-To: <1567605621-6818-1-git-send-email-harini.katakam@xilinx.com>
Use set/get drv data in phydev's mdio device instead. Phy device priv
field maybe used by the external phy driver and should not be
overwritten.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
v2:
Use mdio driver data helper.
drivers/net/phy/xilinx_gmii2rgmii.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c b/drivers/net/phy/xilinx_gmii2rgmii.c
index 2d14493..151c2a3 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -29,7 +29,7 @@ struct gmii2rgmii {
static int xgmiitorgmii_read_status(struct phy_device *phydev)
{
- struct gmii2rgmii *priv = phydev->priv;
+ struct gmii2rgmii *priv = mdiodev_get_drvdata(&phydev->mdio);
struct mii_bus *bus = priv->mdio->bus;
int addr = priv->mdio->addr;
u16 val = 0;
@@ -90,7 +90,7 @@ static int xgmiitorgmii_probe(struct mdio_device *mdiodev)
memcpy(&priv->conv_phy_drv, priv->phy_dev->drv,
sizeof(struct phy_driver));
priv->conv_phy_drv.read_status = xgmiitorgmii_read_status;
- priv->phy_dev->priv = priv;
+ mdiodev_set_drvdata(&priv->phy_dev->mdio, priv);
priv->phy_dev->drv = &priv->conv_phy_drv;
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/2] Fix GMII2RGMII private field
From: Harini Katakam @ 2019-09-04 14:00 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem
Cc: michal.simek, netdev, linux-arm-kernel, linux-kernel,
harinikatakamlinux, harini.katakam, radhey.shyam.pandey
Fix the usage of external phy's priv field by gmii2rgmii driver.
Based on net-next.
Harini Katakam (2):
include: mdio: Add driver data helpers
net: phy: gmii2rgmii: Dont use priv field in phy device
drivers/net/phy/xilinx_gmii2rgmii.c | 4 ++--
include/linux/mdio.h | 11 +++++++++++
2 files changed, 13 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] include: mdio: Add driver data helpers
From: Harini Katakam @ 2019-09-04 14:00 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem
Cc: michal.simek, netdev, linux-arm-kernel, linux-kernel,
harinikatakamlinux, harini.katakam, radhey.shyam.pandey
In-Reply-To: <1567605621-6818-1-git-send-email-harini.katakam@xilinx.com>
Add set/get drv_data helpers for mdio device.
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
---
v2:
Added this patch driver data helpers in mdio instead of priv field.
include/linux/mdio.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index e8242ad8..a760424 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -68,6 +68,17 @@ struct mdio_driver {
#define to_mdio_driver(d) \
container_of(to_mdio_common_driver(d), struct mdio_driver, mdiodrv)
+/* device driver data */
+static inline void mdiodev_set_drvdata(struct mdio_device *mdio, void *data)
+{
+ dev_set_drvdata(&mdio->dev, data);
+}
+
+static inline void *mdiodev_get_drvdata(struct mdio_device *mdio)
+{
+ return dev_get_drvdata(&mdio->dev);
+}
+
void mdio_device_free(struct mdio_device *mdiodev);
struct mdio_device *mdio_device_create(struct mii_bus *bus, int addr);
int mdio_device_register(struct mdio_device *mdiodev);
--
2.7.4
^ 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