* Re: [PATCH v2] rhashtable: make walk safe from softirq context
From: David Miller @ 2019-02-12 18:43 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, j, tgraf, herbert, johannes.berg
In-Reply-To: <20190206090721.8001-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 6 Feb 2019 10:07:21 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> When an rhashtable walk is done from softirq context, we rightfully
> get a lockdep complaint saying that we could get a softirq in the
> middle of a rehash, and thus deadlock on &ht->lock. This happened
> e.g. in mac80211 as it does a walk in softirq context.
>
> Fix this by using spin_lock_bh() wherever we use the &ht->lock.
>
> Initially, I thought it would be sufficient to do this only in the
> rehash (rhashtable_rehash_table), but I changed my mind:
> * the caller doesn't really need to disable softirqs across all
> of the rhashtable_walk_* functions, only those parts that they
> actually do within the lock need it
> * maybe more importantly, it would still lead to massive lockdep
> complaints - false positives, but hard to fix - because lockdep
> wouldn't know about different ht->lock instances, and thus one
> user of the code doing a walk w/o any locking (when it only ever
> uses process context this is fine) vs. another user like in wifi
> where we noticed this problem would still cause it to complain.
>
> Cc: stable@vger.kernel.org
> Reported-by: Jouni Malinen <j@w1.fi>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Herbert and Johannes, I need some guidance.
It seems Herbert wants the softirq usage of rhashtables removed, but
since things have been like this for so long that's not the most
reasonable requirement if we can fix it more simply with Johannes's
patch especially for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit
From: Heiner Kallweit @ 2019-02-12 18:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: John David Anglin, Russell King, Vivien Didelot, Florian Fainelli,
netdev
In-Reply-To: <20190212125644.GA7527@lunn.ch>
On 12.02.2019 13:56, Andrew Lunn wrote:
> On Tue, Feb 12, 2019 at 07:51:05AM +0100, Heiner Kallweit wrote:
>> On 12.02.2019 04:58, Andrew Lunn wrote:
>>>>> Hi David
>>>>>
>>>>> I just tested this on one of my boards. It loops endlessly:
>>>>>
>>>>> [ 47.173396] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.182108] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.190820] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.199535] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.208254] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>>
>>>>> These are reg, ctl1, reg & ctl1.
>>>>>
>>>>> So there is an unhandled device interrupt.
>>>
>>> Hi Heiner
>>>
>>> Your patch Fixes: 2b3e88ea6528 ("net: phy: improve phy state
>>> checking") is causing me problems with interrupts for the Marvell
>>> switches.
>>>
>> Hi Andrew,
>>
>> what kernel version is it?
>
> It is a little bit old, 5.0-rc1 net-next. I should rebase and
> retest. I'm testing on a ZII board which is not fully in mainline So i
> need some patches.
>
Thanks, Andrew. Indeed 5.0 needs a fix, as also pointed out by Russell.
I think I will simply remove the following:
if (!phy_is_started(phydev))
return IRQ_NONE;
Then we basically do the same like phy_mac_interrupt(), we always run
the state machine. If it has nothing to do, then it does nothing.
Therefore also state HALTED doesn't need a special handling.
This way we handle interrupts (incl. spurious ones) gracefully.
>> And the PHY driver in use is "Marvell 88E6390" ?
>
> Yes, the marvell 1G driver.
>
> Andrew
> .
>
Heiner
^ permalink raw reply
* Re: [PATCH net-next v4 00/17] Refactor classifier API to work with chain/classifiers without rtnl lock
From: David Miller @ 2019-02-12 18:42 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, ast, daniel
In-Reply-To: <20190211085548.7190-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 11 Feb 2019 10:55:31 +0200
> Currently, all netlink protocol handlers for updating rules, actions and
> qdiscs are protected with single global rtnl lock which removes any
> possibility for parallelism. This patch set is a third step to remove
> rtnl lock dependency from TC rules update path.
...
I have to say, this stuff is very ambitious. Thanks for working on this.
Series applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH v2] net/packet: fix 4gb buffer limit due to overflow check
From: David Miller @ 2019-02-12 18:38 UTC (permalink / raw)
To: kal.conley
Cc: willemb, edumazet, alexander.h.duyck, jeffrey.t.kirsher, ktkhai,
vincent.whitchurch, lirongqing, magnus.karlsson, netdev,
linux-kernel
In-Reply-To: <20190210085712.31622-1-kal.conley@dectris.com>
From: Kal Conley <kal.conley@dectris.com>
Date: Sun, 10 Feb 2019 09:57:11 +0100
> When calculating rb->frames_per_block * req->tp_block_nr the result
> can overflow. Check it for overflow without limiting the total buffer
> size to UINT_MAX.
>
> This change fixes support for packet ring buffers >= UINT_MAX.
>
> Fixes: 8f8d28e4d6d8 ("net/packet: fix overflow in check for tp_frame_nr")
> Signed-off-by: Kal Conley <kal.conley@dectris.com>
> ---
> Changes in v2:
> - Add Signed-off-by and Fixes tag
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] inet_diag: fix reporting cgroup classid and fallback to priority
From: David Miller @ 2019-02-12 18:37 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, linux-kernel, sashal, linux-sctp
In-Reply-To: <154970855279.305165.13649851988934332761.stgit@buzz>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Sat, 09 Feb 2019 13:35:52 +0300
> Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
> extensions has only 8 bits. Thus extensions starting from DCTCPINFO
> cannot be requested directly. Some of them included into response
> unconditionally or hook into some of lower 8 bits.
>
> Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
>
> This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
> reservation, and documents behavior for other extensions.
>
> Also this patch adds fallback to reporting socket priority. This filed
> is more widely used for traffic classification because ipv4 sockets
> automatically maps TOS to priority and default qdisc pfifo_fast knows
> about that. But priority could be changed via setsockopt SO_PRIORITY so
> INET_DIAG_TOS isn't enough for predicting class.
>
> Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
> reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
>
> So, after this patch INET_DIAG_CLASS_ID will report socket priority
> for most common setup when net_cls isn't set and/or cgroup2 in use.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Fixes: 0888e372c37f ("net: inet: diag: expose sockets cgroup classid")
Applied, and queued up for -stable.
Please always put the Fixes: tag first in the list of tags. I fixed
it up for you this time.
Thanks.
^ permalink raw reply
* Re: [PATCH net] batman-adv: fix uninit-value in batadv_interface_tx()
From: David Miller @ 2019-02-12 18:31 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, syzkaller
In-Reply-To: <20190211224122.122242-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 11 Feb 2019 14:41:22 -0800
> KMSAN reported batadv_interface_tx() was possibly using a
> garbage value [1]
>
> batadv_get_vid() does have a pskb_may_pull() call
> but batadv_interface_tx() does not actually make sure
> this did not fail.
...
> Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] isdn: i4l: isdn_tty: Mark expected switch fall-through
From: David Miller @ 2019-02-12 18:29 UTC (permalink / raw)
To: gustavo; +Cc: isdn, netdev, linux-kernel, keescook
In-Reply-To: <20190211223821.GA13158@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 11 Feb 2019 16:38:21 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/isdn/i4l/isdn_tty.c: In function ‘isdn_tty_edit_at’:
> drivers/isdn/i4l/isdn_tty.c:3644:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> m->mdmcmdl = 0;
> ~~~~~~~~~~~^~~
> drivers/isdn/i4l/isdn_tty.c:3646:5: note: here
> case 0:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] isdn_v110: mark expected switch fall-through
From: David Miller @ 2019-02-12 18:29 UTC (permalink / raw)
To: gustavo; +Cc: isdn, netdev, linux-kernel, keescook
In-Reply-To: <20190211224237.GA29262@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 11 Feb 2019 16:42:37 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/isdn/i4l/isdn_v110.c: In function ‘EncodeMatrix’:
> drivers/isdn/i4l/isdn_v110.c:353:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (line >= mlen) {
> ^
> drivers/isdn/i4l/isdn_v110.c:358:3: note: here
> case 128:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ser_gigaset: mark expected switch fall-through
From: David Miller @ 2019-02-12 18:29 UTC (permalink / raw)
To: gustavo; +Cc: pebolle, isdn, gigaset307x-common, netdev, linux-kernel, keescook
In-Reply-To: <20190211223444.GA29517@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 11 Feb 2019 16:34:44 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/isdn/gigaset/ser-gigaset.c: In function ‘gigaset_tty_ioctl’:
> drivers/isdn/gigaset/ser-gigaset.c:627:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
> switch (arg) {
> ^~~~~~
> drivers/isdn/gigaset/ser-gigaset.c:638:2: note: here
> default:
> ^~~~~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* [PATCH] rpc: properly check debugfs dentry before using it
From: Greg Kroah-Hartman @ 2019-02-12 18:27 UTC (permalink / raw)
To: J. Bruce Fields, Jeff Layton, Trond Myklebust, Anna Schumaker
Cc: linux-nfs, netdev, David Howells
debugfs can now report an error code if something went wrong instead of
just NULL. So if the return value is to be used as a "real" dentry, it
needs to be checked if it is an error before dereferencing it.
This is now happening because of ff9fb72bc077 ("debugfs: return error
values, not NULL"), but why debugfs files are not being created properly
is an older issue, probably one that has always been there and should
probably be looked at...
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org
Reported-by: David Howells <dhowells@redhat.com>
Tested-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I can take this through my tree if people don't object, or it can go
through the NFS tree. It does need to get merged before 5.0-final
though.
I also have a "larger" debugfs cleanup patch for this file, but that's
not really 5.0-final material and I will send it out later.
thanks,
greg k-h
diff --git a/net/sunrpc/debugfs.c b/net/sunrpc/debugfs.c
index 45a033329cd4..19bb356230ed 100644
--- a/net/sunrpc/debugfs.c
+++ b/net/sunrpc/debugfs.c
@@ -146,7 +146,7 @@ rpc_clnt_debugfs_register(struct rpc_clnt *clnt)
rcu_read_lock();
xprt = rcu_dereference(clnt->cl_xprt);
/* no "debugfs" dentry? Don't bother with the symlink. */
- if (!xprt->debugfs) {
+ if (IS_ERR_OR_NULL(xprt->debugfs)) {
rcu_read_unlock();
return;
}
^ permalink raw reply related
* Re: [net-next PATCH V2 1/3] mm: add dma_addr_t to struct page
From: Florian Fainelli @ 2019-02-12 18:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-mm, Toke Høiland-Jørgensen,
Ilias Apalodimas, willy, Saeed Mahameed, Alexander Duyck,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan
In-Reply-To: <20190212191917.2ef91a88@carbon>
On 2/12/19 10:19 AM, Jesper Dangaard Brouer wrote:
> On Tue, 12 Feb 2019 10:05:39 -0800
> Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> On 2/12/19 6:49 AM, Jesper Dangaard Brouer wrote:
>>> The page_pool API is using page->private to store DMA addresses.
>>> As pointed out by David Miller we can't use that on 32-bit architectures
>>> with 64-bit DMA
>>>
>>> This patch adds a new dma_addr_t struct to allow storing DMA addresses
>>>
>>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>> ---
>>> include/linux/mm_types.h | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>>> index 2c471a2c43fa..581737bd0878 100644
>>> --- a/include/linux/mm_types.h
>>> +++ b/include/linux/mm_types.h
>>> @@ -95,6 +95,13 @@ struct page {
>>> */
>>> unsigned long private;
>>> };
>>> + struct { /* page_pool used by netstack */
>>> + /**
>>> + * @dma_addr: page_pool requires a 64-bit value even on
>>> + * 32-bit architectures.
>>> + */
>>
>> Nit: might require? dma_addr_t, as you mention in the commit may have a
>> different size based on CONFIG_ARCH_DMA_ADDR_T_64BIT.
>
> So you want me to change the comment to be:
>
> /**
> * @dma_addr: might require a 64-bit value even on
> * 32-bit architectures.
> */
>
> Correctly understood?
Correct, that is what I would change. The commit message is correct, but
the comment makes it sound like dma_addr_t is guaranteed to be 64-bit,
while it is actually platform dependent. Does that make it clearer?
--
Florian
^ permalink raw reply
* Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Ilias Apalodimas @ 2019-02-12 18:20 UTC (permalink / raw)
To: Alexander Duyck
Cc: Eric Dumazet, Tariq Toukan, Matthew Wilcox, brouer@redhat.com,
David Miller, toke@redhat.com, netdev@vger.kernel.org,
mgorman@techsingularity.net, linux-mm@kvack.org
In-Reply-To: <CAKgT0UfG08aYoN=zO_aVyx+OgNPmN9pVkBNeZMPTF2KL7XqoBQ@mail.gmail.com>
Hi Alexander,
On Tue, Feb 12, 2019 at 10:13:30AM -0800, Alexander Duyck wrote:
> On Tue, Feb 12, 2019 at 7:16 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >
> >
> > On 02/12/2019 04:39 AM, Tariq Toukan wrote:
> > >
> > >
> > > On 2/11/2019 7:14 PM, Eric Dumazet wrote:
> > >>
> > >>
> > >> On 02/11/2019 12:53 AM, Tariq Toukan wrote:
> > >>>
> > >>
> > >>> Hi,
> > >>>
> > >>> It's great to use the struct page to store its dma mapping, but I am
> > >>> worried about extensibility.
> > >>> page_pool is evolving, and it would need several more per-page fields.
> > >>> One of them would be pageref_bias, a planned optimization to reduce the
> > >>> number of the costly atomic pageref operations (and replace existing
> > >>> code in several drivers).
> > >>>
> > >>
> > >> But the point about pageref_bias is to place it in a different cache line than "struct page"
> > >>
> > >> The major cost is having a cache line bouncing between producer and consumer.
> > >>
> > >
> > > pageref_bias is meant to be dirtied only by the page requester, i.e. the
> > > NIC driver / page_pool.
> > > All other components (basically, SKB release flow / put_page) should
> > > continue working with the atomic page_refcnt, and not dirty the
> > > pageref_bias.
> >
> > This is exactly my point.
> >
> > You suggested to put pageref_bias in struct page, which breaks this completely.
> >
> > pageref_bias is better kept in a driver structure, with appropriate prefetching
> > since most NIC use a ring buffer for their queues.
> >
> > The dma address _can_ be put in the struct page, since the driver does not dirty it
> > and does not even read it when page can be recycled.
>
> Instead of maintaining the pageref_bias in the page itself it could be
> maintained in some sort of separate structure. You could just maintain
> a pointer to a slot in an array somewhere. Then you can still access
> it if needed, the pointer would be static for as long as it is in the
> page pool, and you could invalidate the pointer prior to removing the
> bias from the page.
I think that's what Tariq was suggesting in the first place.
/Ilias
^ permalink raw reply
* Re: [net-next PATCH V2 1/3] mm: add dma_addr_t to struct page
From: Jesper Dangaard Brouer @ 2019-02-12 18:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, linux-mm, Toke Høiland-Jørgensen,
Ilias Apalodimas, willy, Saeed Mahameed, Alexander Duyck,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan, brouer
In-Reply-To: <dc34bb0b-1efd-4200-2ee7-bf8adef8a0b5@gmail.com>
On Tue, 12 Feb 2019 10:05:39 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 2/12/19 6:49 AM, Jesper Dangaard Brouer wrote:
> > The page_pool API is using page->private to store DMA addresses.
> > As pointed out by David Miller we can't use that on 32-bit architectures
> > with 64-bit DMA
> >
> > This patch adds a new dma_addr_t struct to allow storing DMA addresses
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > Acked-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > include/linux/mm_types.h | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2c471a2c43fa..581737bd0878 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -95,6 +95,13 @@ struct page {
> > */
> > unsigned long private;
> > };
> > + struct { /* page_pool used by netstack */
> > + /**
> > + * @dma_addr: page_pool requires a 64-bit value even on
> > + * 32-bit architectures.
> > + */
>
> Nit: might require? dma_addr_t, as you mention in the commit may have a
> different size based on CONFIG_ARCH_DMA_ADDR_T_64BIT.
So you want me to change the comment to be:
/**
* @dma_addr: might require a 64-bit value even on
* 32-bit architectures.
*/
Correctly understood?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next 00/10] s390/qeth: updates 2019-02-12
From: David Miller @ 2019-02-12 18:14 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20190212173325.36555-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Tue, 12 Feb 2019 18:33:15 +0100
> please apply one more round of qeth patches to net-next. This
> series targets the driver's control paths. It primarily brings
> improvements to the error handling for sent cmds and received
> responses, along with the usual cleanup and consolidation efforts.
Series applied, thanks.
^ permalink raw reply
* Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Alexander Duyck @ 2019-02-12 18:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tariq Toukan, Ilias Apalodimas, Matthew Wilcox, brouer@redhat.com,
David Miller, toke@redhat.com, netdev@vger.kernel.org,
mgorman@techsingularity.net, linux-mm@kvack.org
In-Reply-To: <d8fa6786-c252-6bb0-409f-42ce18127cb3@gmail.com>
On Tue, Feb 12, 2019 at 7:16 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 02/12/2019 04:39 AM, Tariq Toukan wrote:
> >
> >
> > On 2/11/2019 7:14 PM, Eric Dumazet wrote:
> >>
> >>
> >> On 02/11/2019 12:53 AM, Tariq Toukan wrote:
> >>>
> >>
> >>> Hi,
> >>>
> >>> It's great to use the struct page to store its dma mapping, but I am
> >>> worried about extensibility.
> >>> page_pool is evolving, and it would need several more per-page fields.
> >>> One of them would be pageref_bias, a planned optimization to reduce the
> >>> number of the costly atomic pageref operations (and replace existing
> >>> code in several drivers).
> >>>
> >>
> >> But the point about pageref_bias is to place it in a different cache line than "struct page"
> >>
> >> The major cost is having a cache line bouncing between producer and consumer.
> >>
> >
> > pageref_bias is meant to be dirtied only by the page requester, i.e. the
> > NIC driver / page_pool.
> > All other components (basically, SKB release flow / put_page) should
> > continue working with the atomic page_refcnt, and not dirty the
> > pageref_bias.
>
> This is exactly my point.
>
> You suggested to put pageref_bias in struct page, which breaks this completely.
>
> pageref_bias is better kept in a driver structure, with appropriate prefetching
> since most NIC use a ring buffer for their queues.
>
> The dma address _can_ be put in the struct page, since the driver does not dirty it
> and does not even read it when page can be recycled.
Instead of maintaining the pageref_bias in the page itself it could be
maintained in some sort of separate structure. You could just maintain
a pointer to a slot in an array somewhere. Then you can still access
it if needed, the pointer would be static for as long as it is in the
page pool, and you could invalidate the pointer prior to removing the
bias from the page.
^ permalink raw reply
* Re: [net-next PATCH V2 1/3] mm: add dma_addr_t to struct page
From: Florian Fainelli @ 2019-02-12 18:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, linux-mm
Cc: Toke Høiland-Jørgensen, Ilias Apalodimas, willy,
Saeed Mahameed, Alexander Duyck, Andrew Morton, mgorman,
David S. Miller, Tariq Toukan
In-Reply-To: <154998294324.8783.9045146111677125556.stgit@firesoul>
On 2/12/19 6:49 AM, Jesper Dangaard Brouer wrote:
> The page_pool API is using page->private to store DMA addresses.
> As pointed out by David Miller we can't use that on 32-bit architectures
> with 64-bit DMA
>
> This patch adds a new dma_addr_t struct to allow storing DMA addresses
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Acked-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> include/linux/mm_types.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2c471a2c43fa..581737bd0878 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -95,6 +95,13 @@ struct page {
> */
> unsigned long private;
> };
> + struct { /* page_pool used by netstack */
> + /**
> + * @dma_addr: page_pool requires a 64-bit value even on
> + * 32-bit architectures.
> + */
Nit: might require? dma_addr_t, as you mention in the commit may have a
different size based on CONFIG_ARCH_DMA_ADDR_T_64BIT.
--
Florian
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Li Yang @ 2019-02-12 18:01 UTC (permalink / raw)
To: Pankaj Bansal, Rob Herring
Cc: Shawn Guo, Andrew Lunn, Florian Fainelli, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR0401MB24818DB35D5DEF95DA710038F1650@AM5PR0401MB2481.eurprd04.prod.outlook.com>
On Mon, Feb 11, 2019 at 9:28 PM Pankaj Bansal <pankaj.bansal@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Leo Li
> > Sent: Tuesday, 12 February, 2019 02:14 AM
> > To: Shawn Guo <shawnguo@kernel.org>; Pankaj Bansal
> > <pankaj.bansal@nxp.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>; Florian Fainelli <f.fainelli@gmail.com>;
> > netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> > Subject: RE: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
> >
> >
> >
> > > -----Original Message-----
> > > From: Shawn Guo <shawnguo@kernel.org>
> > > Sent: Sunday, February 10, 2019 9:00 PM
> > > To: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > Cc: Leo Li <leoyang.li@nxp.com>; Andrew Lunn <andrew@lunn.ch>; Florian
> > > Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org; linux-arm-
> > > kernel@lists.infradead.org
> > > Subject: Re: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
> > >
> > > On Wed, Feb 06, 2019 at 09:40:33AM +0000, Pankaj Bansal wrote:
> > > > The two external MDIO buses used to communicate with phy devices
> > > > that are external to SOC are muxed in LX2160AQDS board.
> > > >
> > > > These buses can be routed to any one of the eight IO slots on
> > > > LX2160AQDS board depending on value in fpga register 0x54.
> > > >
> > > > Additionally the external MDIO1 is used to communicate to the
> > > > onboard RGMII phy devices.
> > > >
> > > > The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is
> > > > controlled by bits 0-3 of fpga register.
> > > >
> > > > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > > ---
> > > >
> > > > Notes:
> > > > V3:
> > > > - Add status = disabled in soc file and status = okay in board file
> > > > for external MDIO nodes
> > > > - Add interrupts property in external mdio nodes in soc file
> > > > V2:
> > > > - removed unnecassary TODO statements
> > > > - removed device_type from mdio nodes
> > > > - change the case of hex number to lowercase
> > > > - removed board specific comments from soc file
> > > >
> > > > .../boot/dts/freescale/fsl-lx2160a-qds.dts | 123 +++++++++++++++++
> > > > .../boot/dts/freescale/fsl-lx2160a.dtsi | 22 +++
> > > > 2 files changed, 145 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > index 99a22abbe725..079264b391a2 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > @@ -35,6 +35,14 @@
> > > > status = "okay";
> > > > };
> > > >
> > > > +&emdio1 {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > +&emdio2 {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > &esdhc0 {
> > > > status = "okay";
> > > > };
> > > > @@ -46,6 +54,121 @@
> > > > &i2c0 {
> > > > status = "okay";
> > > >
> > > > + fpga@66 {
> > > > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > > > + reg = <0x66>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + mdio-mux-1@54 {
> > > > + mdio-parent-bus = <&emdio1>;
> > > > + reg = <0x54>; /* BRDCFG4 */
> > > > + mux-mask = <0xf8>; /* EMI1_MDIO */
> > > > + #address-cells=<1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + mdio@0 {
> > > > + reg = <0x00>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > >
> > > Please have a newline between nodes. It doesn't deserve a respin
> > > though. I can fix them up when applying if Leo is fine with this version.
> >
> > I think there should be a compatible string defined for the binding of parent
> > node mdio-mux, probably "mdio-mux-regmap", and be used here in the device
> > tree.
>
> I have two concerns :
> 1. The regmap is linux s/w construct, while device tree is h/w representation and is s/w agnostic. can we use regmap in device tree?
Well, if we want to avoid using the regmap name, we probably can try
"mdio-mux-reg" or "mdio-mux-syscon"? With further search I also found
a more generic mux binding at Documentation/devicetree/bindings/mux/,
would be even better if we can use that to describe the mux.
> 2. By convention the device tree compatible binding is defined as "<manufacturer>,<model>" e.g. "fsl,mpc8349-uart". The mdio-mux node and it's sub nodes are a generic representation of mdio mux and it is not dependent on a particular manufacturer device. How to define the compatible in this case?
The manufacturer prefix is for vendor specific bindings. If the
binding a suppose to be generic, we don't need the vendor prefix.
>
> >
> > >
> > > Shawn
> > >
> > > > + mdio@40 {
> > > > + reg = <0x40>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@c0 {
> > > > + reg = <0xc0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@c8 {
> > > > + reg = <0xc8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@d0 {
> > > > + reg = <0xd0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@d8 {
> > > > + reg = <0xd8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@e0 {
> > > > + reg = <0xe0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@e8 {
> > > > + reg = <0xe8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@f0 {
> > > > + reg = <0xf0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@f8 {
> > > > + reg = <0xf8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + };
> > > > +
> > > > + mdio-mux-2@54 {
> > > > + mdio-parent-bus = <&emdio2>;
> > > > + reg = <0x54>; /* BRDCFG4 */
> > > > + mux-mask = <0x07>; /* EMI2_MDIO */
> > > > + #address-cells=<1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + mdio@0 {
> > > > + reg = <0x00>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@1 {
> > > > + reg = <0x01>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@2 {
> > > > + reg = <0x02>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@3 {
> > > > + reg = <0x03>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@4 {
> > > > + reg = <0x04>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@5 {
> > > > + reg = <0x05>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@6 {
> > > > + reg = <0x06>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@7 {
> > > > + reg = <0x07>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > i2c-mux@77 {
> > > > compatible = "nxp,pca9547";
> > > > reg = <0x77>;
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > index a79f5c1ea56d..7def5252ac1a 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > @@ -762,5 +762,27 @@
> > > > <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> > > > dma-coherent;
> > > > };
> > > > +
> > > > + /* WRIOP0: 0x8b8_0000, E-MDIO1: 0x1_6000 */
> > > > + emdio1: mdio@8b96000 {
> > > > + compatible = "fsl,fman-memac-mdio";
> > > > + reg = <0x0 0x8b96000 0x0 0x1000>;
> > > > + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + little-endian; /* force the driver in LE mode */
> > > > + status = "disabled";
> > > > + };
> > > > +
> > > > + /* WRIOP0: 0x8b8_0000, E-MDIO2: 0x1_7000 */
> > > > + emdio2: mdio@8b97000 {
> > > > + compatible = "fsl,fman-memac-mdio";
> > > > + reg = <0x0 0x8b97000 0x0 0x1000>;
> > > > + interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + little-endian; /* force the driver in LE mode */
> > > > + status = "disabled";
> > > > + };
> > > > };
> > > > };
> > > > --
> > > > 2.17.1
> > > >
^ permalink raw reply
* Re: [v3, 0/9] Add ENETC PTP clock driver
From: David Miller @ 2019-02-12 17:59 UTC (permalink / raw)
To: yangbo.lu; +Cc: netdev, devicetree, richardcochran, robh+dt, claudiu.manoil
In-Reply-To: <20190212042404.15575-1-yangbo.lu@nxp.com>
From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Tue, 12 Feb 2019 12:23:55 +0800
> There is same QorIQ 1588 timer IP block on the new ENETC Ethernet
> controller with eTSEC/DPAA Ethernet controllers. However it's
> different endianness (little-endian) and using PCI driver.
>
> To support ENETC PTP driver, ptp_qoriq driver needed to be
> reworked to make functions global for reusing, to add little-
> endian support, to add ENETC memory map support, and to add
> ENETC dependency for ptp_qoriq driver.
>
> In addition, although ENETC PTP driver is a PCI driver, the dts
> node still could be used. Currently the ls1028a dtsi which is
> the only platform by now using ENETC is not complete, so there
> is still dependency for ENETC PTP node upstreaming. This will
> be done in the near future. The hardware timestamping support
> for ENETC is done but needs to be reworked with new method in
> internal git tree, and will be sent out soon.
Series applied.
I'll push this out after my build tests pass.
^ permalink raw reply
* Re: [net-next PATCH V2 3/3] page_pool: use DMA_ATTR_SKIP_CPU_SYNC for DMA mappings
From: Jesper Dangaard Brouer @ 2019-02-12 17:58 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, netdev, linux-mm, Toke Høiland-Jørgensen,
Ilias Apalodimas, willy, Saeed Mahameed, Alexander Duyck,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan, brouer
In-Reply-To: <201902130132.DXE6rH81%fengguang.wu@intel.com>
On Wed, 13 Feb 2019 01:12:59 +0800
kbuild test robot <lkp@intel.com> wrote:
> net/core/page_pool.c: In function '__page_pool_clean_page':
> >> net/core/page_pool.c:187:2: error: implicit declaration of function 'dma_unmap_page_attr'; did you mean 'dma_unmap_page_attrs'? [-Werror=implicit-function-declaration]
> dma_unmap_page_attr(pool->p.dev, dma,
> ^~~~~~~~~~~~~~~~~~~
> dma_unmap_page_attrs
> cc1: some warnings being treated as errors
Ups, in my compile test I didn't have CONFIG_PAGE_POOL defined.
Will respin a V3.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] net/skbuff: fix up kernel-doc placement
From: David Miller @ 2019-02-12 17:55 UTC (permalink / raw)
To: briannorris; +Cc: netdev, linux-kernel
In-Reply-To: <20190211210225.132282-1-briannorris@chromium.org>
From: Brian Norris <briannorris@chromium.org>
Date: Mon, 11 Feb 2019 13:02:25 -0800
> There are several skb_* functions where the locked and unlocked
> functions are confusingly documented. For several of them, the
> kernel-doc for the unlocked version is placed above the locked version,
> which to the casual reader makes it seems like the locked version "takes
> no locks and you must therefore hold required locks before calling it."
>
> One can see, for example, that this link claims to document
> skb_queue_head(), while instead describing __skb_queue_head().
>
> https://www.kernel.org/doc/html/latest/networking/kapi.html#c.skb_queue_head
>
> The correct documentation for skb_queue_head() is also included further
> down the page.
>
> This diff tested via:
>
> $ scripts/kernel-doc -rst include/linux/skbuff.h net/core/skbuff.c
>
> No new warnings were seen, and the output makes a little more sense.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Applied, thanks Brian.
^ permalink raw reply
* Re: [PATCH 0/3] gcc-plugins: Introduce stackinit plugin
From: Kees Cook @ 2019-02-12 17:54 UTC (permalink / raw)
To: Alexander Popov
Cc: LKML, Ard Biesheuvel, Laura Abbott, xen-devel,
Maling list - DRI developers, intel-gfx, intel-wired-lan,
Network Development, linux-usb, linux-fsdevel@vger.kernel.org,
Linux-MM, dev, linux-kbuild, linux-security-module,
Kernel Hardening, Greg KH, Jann Horn, William Kucharski,
Jani Nikula, Edwin Zimmerman, Matthew Wilcox, Jeff Kirsher
In-Reply-To: <874b8c23-068b-f8e7-2168-12947c06e145@linux.com>
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov <alex.popov@linux.com> wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of the initialization of all stack
> variables. So I did a very brief test with this plugin on top of 4.20.5.
>
> hackbench on Intel Core i7-4770 showed ~0.7% slowdown.
> hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown.
Thanks for looking at this! I'll be including my hackbench
measurements for the v2 here in a moment.
> This test involves the kernel scheduler and allocator. I can't say whether they
> use stack aggressively. Maybe performance tests of other subsystems (e.g.
> network subsystem) can show different numbers. Did you try?
I haven't found a stable network test yet. If someone can find a
reasonable workload, I'd love to hear about it.
> I've heard a hypothesis that the initialization of all stack variables would
> pollute CPU caches, which is critical for some types of computations. Maybe some
> micro-benchmarks can disprove/confirm that?
I kind of think micro-benchmarks aren't so useful because they don't
represent a real-world workload. I've heard people talk about SAP-HANA
as a good test, but I can't get my hands on it. I wonder if anyone has
tried "mysqlslap"?
--
Kees Cook
^ permalink raw reply
* Re: [PATCH net-next 0/3] Remove getting SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
From: Florian Fainelli @ 2019-02-12 17:54 UTC (permalink / raw)
To: David Miller
Cc: netdev, idosch, linux-kernel, devel, bridge, jiri, andrew,
vivien.didelot
In-Reply-To: <20190212.095030.1445077555795164973.davem@davemloft.net>
On 2/12/19 9:50 AM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Mon, 11 Feb 2019 13:17:46 -0800
>
>> AFAICT there is no code that attempts to get the value of the attribute
>> SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS while it is used with
>> switchdev_port_attr_set().
>>
>> This is effectively no doing anything and it can slow down future work
>> that tries to make modifications in these areas so remove that.
>
> Series applied.
>
>> David, there should be no dependency with previous patch series, but
>> again, feedback from Ido and Jiri would be welcome in case this was
>> added for a reason.
>
> Ok, is there going to be another respin of that switchdev_ops removal
> series?
Yes, I will be working on a v5 which addresses Ido's feedback in the
next hours.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/3] Remove getting SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
From: David Miller @ 2019-02-12 17:50 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, idosch, linux-kernel, devel, bridge, jiri, andrew,
vivien.didelot
In-Reply-To: <20190211211749.19847-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 11 Feb 2019 13:17:46 -0800
> AFAICT there is no code that attempts to get the value of the attribute
> SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS while it is used with
> switchdev_port_attr_set().
>
> This is effectively no doing anything and it can slow down future work
> that tries to make modifications in these areas so remove that.
Series applied.
> David, there should be no dependency with previous patch series, but
> again, feedback from Ido and Jiri would be welcome in case this was
> added for a reason.
Ok, is there going to be another respin of that switchdev_ops removal
series?
^ permalink raw reply
* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
From: Paul Burton @ 2019-02-12 17:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
iommu@lists.linux-foundation.org, linux-mips@vger.kernel.org
In-Reply-To: <20190201084801.10983-2-hch@lst.de>
Hello,
Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
> allocation, as we aren't in interrupt context or under a lock.
>
> Note that this whole function looks somewhat bogus given that we never
> even look at the returned dma address, and the CPHYSADDR magic on
> a returned noncached mapping looks "interesting". But I'll leave
> that to people more familiar with the code to sort out.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Applied to mips-fixes.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply
* Re: [PATCH net-next] net: phy: simplify genphy_config_eee_advert
From: David Miller @ 2019-02-12 17:40 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <8323b521-11aa-c9b2-1ac3-52b8b6439fa7@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 11 Feb 2019 22:16:13 +0100
> Use new function phy_modify_mmd_changed(), the result speaks for itself.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Nice cleanup Heiner, applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox