* [PATCH net-next v3 02/16] net: sched: refactor tc_ctl_chain() to use block->lock
From: Vlad Buslov @ 2019-02-04 12:32 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, ast, daniel, Vlad Buslov
In-Reply-To: <20190204123301.4223-1-vladbu@mellanox.com>
In order to remove dependency on rtnl lock, modify chain API to use
block->lock to protect chain from concurrent modification. Rearrange
tc_ctl_chain() code to call tcf_chain_hold() while holding block->lock to
prevent concurrent chain removal.
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
---
net/sched/cls_api.c | 36 +++++++++++++++++++++++++-----------
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index cc416b6a3aa2..a1bd1cd0e1ae 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -2247,6 +2247,8 @@ static int tc_ctl_chain(struct sk_buff *skb, struct nlmsghdr *n,
err = -EINVAL;
goto errout_block;
}
+
+ mutex_lock(&block->lock);
chain = tcf_chain_lookup(block, chain_index);
if (n->nlmsg_type == RTM_NEWCHAIN) {
if (chain) {
@@ -2258,41 +2260,49 @@ static int tc_ctl_chain(struct sk_buff *skb, struct nlmsghdr *n,
} else {
NL_SET_ERR_MSG(extack, "Filter chain already exists");
err = -EEXIST;
- goto errout_block;
+ goto errout_block_locked;
}
} else {
if (!(n->nlmsg_flags & NLM_F_CREATE)) {
NL_SET_ERR_MSG(extack, "Need both RTM_NEWCHAIN and NLM_F_CREATE to create a new chain");
err = -ENOENT;
- goto errout_block;
+ goto errout_block_locked;
}
chain = tcf_chain_create(block, chain_index);
if (!chain) {
NL_SET_ERR_MSG(extack, "Failed to create filter chain");
err = -ENOMEM;
- goto errout_block;
+ goto errout_block_locked;
}
}
} else {
if (!chain || tcf_chain_held_by_acts_only(chain)) {
NL_SET_ERR_MSG(extack, "Cannot find specified filter chain");
err = -EINVAL;
- goto errout_block;
+ goto errout_block_locked;
}
tcf_chain_hold(chain);
}
+ if (n->nlmsg_type == RTM_NEWCHAIN) {
+ /* Modifying chain requires holding parent block lock. In case
+ * the chain was successfully added, take a reference to the
+ * chain. This ensures that an empty chain does not disappear at
+ * the end of this function.
+ */
+ tcf_chain_hold(chain);
+ chain->explicitly_created = true;
+ }
+ mutex_unlock(&block->lock);
+
switch (n->nlmsg_type) {
case RTM_NEWCHAIN:
err = tc_chain_tmplt_add(chain, net, tca, extack);
- if (err)
+ if (err) {
+ tcf_chain_put_explicitly_created(chain);
goto errout;
- /* In case the chain was successfully added, take a reference
- * to the chain. This ensures that an empty chain
- * does not disappear at the end of this function.
- */
- tcf_chain_hold(chain);
- chain->explicitly_created = true;
+ }
+
tc_chain_notify(chain, NULL, 0, NLM_F_CREATE | NLM_F_EXCL,
RTM_NEWCHAIN, false);
break;
@@ -2327,6 +2337,10 @@ static int tc_ctl_chain(struct sk_buff *skb, struct nlmsghdr *n,
/* Replay the request. */
goto replay;
return err;
+
+errout_block_locked:
+ mutex_unlock(&block->lock);
+ goto errout_block;
}
/* called with RTNL */
--
2.13.6
^ permalink raw reply related
* [PATCH net-next v3 00/16] Refactor classifier API to work with chain/classifiers without rtnl lock
From: Vlad Buslov @ 2019-02-04 12:32 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, ast, daniel, Vlad Buslov
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.
Recently, new rtnl registration flag RTNL_FLAG_DOIT_UNLOCKED was added.
Handlers registered with this flag are called without RTNL taken. End
goal is to have rule update handlers(RTM_NEWTFILTER, RTM_DELTFILTER,
etc.) to be registered with UNLOCKED flag to allow parallel execution.
However, there is no intention to completely remove or split rtnl lock
itself. This patch set addresses specific problems in implementation of
classifiers API that prevent its control path from being executed
concurrently, and completes refactoring of cls API rules update handlers
by removing rtnl lock dependency from code that handles chains and
classifiers. Rules update handlers are registered with
RTNL_FLAG_DOIT_UNLOCKED flag.
This patch set substitutes global rtnl lock dependency on rules update
path in cls API by extending its data structures with following locks:
- tcf_block with 'lock' mutex. It is used to protect block state and
life-time management fields of chains on the block (chain->refcnt,
chain->action_refcnt, chain->explicitly crated, etc.).
- tcf_chain with 'filter_chain_lock' mutex, that is used to protect list
of classifier instances attached to chain. chain0->filter_chain_lock
serializes calls to head change callbacks and allows them to rely on
filter_chain_lock for serialization instead of rtnl lock.
- tcf_proto with 'lock' spinlock that is intended to be used to
synchronize access to classifiers that support unlocked execution.
Classifiers are extended with reference counting to accommodate parallel
access by unlocked cls API. Classifier ops structure is extended with
additional 'put' function to allow reference counting of filters and
intended to be used by classifiers that implement rtnl-unlocked API.
Users of classifiers and individual filter instances are modified to
always hold reference while working with them.
Classifiers that support unlocked execution still need to know the
status of rtnl lock, so their API is extended with additional
'rtnl_held' argument that is used to indicate that caller holds rtnl
lock. Cls API propagates rtnl lock status across its helper functions
and passes it to classifier.
Changes from V2 to V3:
- Change block->lock and chain->filter_chain_lock type to mutex. This
removes the need for async miniqp refactoring and allows calling
sleeping functions while holding the block->lock and
chain->filter_chain_lock locks.
- Previous patch 1 - async miniqp is no longer needed, remove the patch.
- Patch 1:
- Change block->lock type to mutex.
- Implement tcf_block_destroy() helper function that destroys
block->lock mutex before deallocating the block.
- Revert GFP_KERNEL->GFP_ATOMIC memory allocation flags of tcf_chain
which is no longer needed after block->lock type change.
- Patch 6:
- Change chain->filter_chain_lock type to mutex.
- Assume chain0->filter_chain_lock synchronizations instead of rtnl
lock in mini_qdisc_pair_swap() function that is called from head
change callback of ingress Qdisc. With filter_chain_lock type
changed to mutex it is now possible to call sleeping function while
holding it, so it is now used instead of async implementation from
previous versions of this patch set.
- Patch 7:
- Add local tp_next var to tcf_chain_flush() and use it to store
tp->next pointer dereferenced with rcu_dereference_protected() to
satisfy kbuild test robot.
- Reset tp pointer to NULL at the beginning of tc_new_tfilter() to
prevent its uninitialized usage in error handling code. This code
was already implemented in patch 10, but must be in patch 8 to
preserve code bisectability.
- Put parent chain in tcf_proto_destroy(). In previous version this
code was implemented in patch 1 which was removed in V3.
Changes from V1 to V2:
- Patch 1:
- Use smp_store_release() instead of xchg() for setting
miniqp->tp_head.
- Move Qdisc deallocation to tc_proto_wq ordered workqueue that is
used to destroy tcf proto instances. This is necessary to ensure
that Qdisc is destroyed after all instances of chain/proto that it
contains in order to prevent use-after-free error in
tc_chain_notify_delete().
- Cache parent net device ifindex in block to prevent use-after-free
of dev queue in tc_chain_notify_delete().
- Patch 2:
- Use lockdep_assert_held() instead of spin_is_locked() for assertion.
- Use 'free_block' argument in tcf_chain_destroy() instead of checking
block's reference count and chain_list for second time.
- Patch 7:
- Refactor tcf_chain0_head_change_cb_add() to not take block->lock and
chain0->filter_chain_lock in correct order.
- Patch 10:
- Always set 'tp_created' flag when creating tp to prevent releasing
the chain twice when tp with same priority was inserted
concurrently.
- Patch 11:
- Add additional check to prevent creation of new proto instance when
parent chain is being flushed to reduce CPU usage.
- Don't call tcf_chain_delete_empty() if tp insertion failed.
- Patch 16 - new.
- Patch 17:
- Refactor to only lock take rtnl lock once (at the beginning of rule
update handlers).
- Always release rtnl mutex in the same function that locked it.
Remove unlock code from tcf_block_release().
Github:
[https://github.com/vbuslov/linux/tree/cls_api_rtnl_lock_remove_for_cong_v3]
Vlad Buslov (16):
net: sched: protect block state with mutex
net: sched: refactor tc_ctl_chain() to use block->lock
net: sched: protect block->chain0 with block->lock
net: sched: traverse chains in block with tcf_get_next_chain()
net: sched: protect chain template accesses with block lock
net: sched: protect filter_chain list with filter_chain_lock mutex
net: sched: introduce reference counting for tcf_proto
net: sched: traverse classifiers in chain with tcf_get_next_proto()
net: sched: refactor tp insert/delete for concurrent execution
net: sched: prevent insertion of new classifiers during chain flush
net: sched: track rtnl lock status when validating extensions
net: sched: extend proto ops with 'put' callback
net: sched: extend proto ops to support unlocked classifiers
net: sched: add flags to Qdisc class ops struct
net: sched: refactor tcf_block_find() into standalone functions
net: sched: unlock rules update API
include/net/pkt_cls.h | 6 +-
include/net/sch_generic.h | 68 ++-
net/sched/cls_api.c | 1213 ++++++++++++++++++++++++++++++++++-----------
net/sched/cls_basic.c | 14 +-
net/sched/cls_bpf.c | 15 +-
net/sched/cls_cgroup.c | 13 +-
net/sched/cls_flow.c | 15 +-
net/sched/cls_flower.c | 16 +-
net/sched/cls_fw.c | 15 +-
net/sched/cls_matchall.c | 16 +-
net/sched/cls_route.c | 14 +-
net/sched/cls_rsvp.h | 16 +-
net/sched/cls_tcindex.c | 17 +-
net/sched/cls_u32.c | 14 +-
net/sched/sch_api.c | 10 +-
net/sched/sch_generic.c | 6 +-
16 files changed, 1103 insertions(+), 365 deletions(-)
--
2.13.6
^ permalink raw reply
* Re: [PATCH 7/7] sh_eth: offload RX checksum on SH7763
From: Rob Landley @ 2019-02-04 11:55 UTC (permalink / raw)
To: Sergei Shtylyov, netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <e8ce7a88-b689-6114-66e4-c45a95087a1f@cogentembedded.com>
On 1/27/19 11:42 AM, Sergei Shtylyov wrote:
> The SH7763 SoC manual describes the Ether MAC's RX checksum offload
> the same way as it's implemented in the EtherAVB MACs...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
I think this is the chip in the JCI N40 on my desk, how would I test this and
tell it was working? (Is there an existing test program or...?)
Also, can this be tested under QEMU's r2 board emulation?
Rob
^ permalink raw reply
* Compiler warning - ipv4 fib_trie
From: Koen Vandeputte @ 2019-02-04 11:55 UTC (permalink / raw)
To: netdev
Hi All,
During compilation of kernel 4.14.96 and 5.0-rc5 I'm seeing following
warning:
net/ipv4/fib_trie.c: In function 'fib_trie_unmerge':
net/ipv4/fib_trie.c:1749:8: warning: 'local_tp' may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (fib_insert_alias(lt, local_tp, local_l, new_fa,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NULL, l->key)) {
~~~~~~~~~~~~~
Code:
https://elixir.bootlin.com/linux/v5.0-rc5/source/net/ipv4/fib_trie.c#L1731
Looks like 'local_tp' should be NULL-ified
Thanks,
Koen
^ permalink raw reply
* Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames
From: Jesper Dangaard Brouer @ 2019-02-04 11:53 UTC (permalink / raw)
To: David Ahern
Cc: David Miller, mst, makita.toshiaki, jasowang, netdev,
virtualization, hawk, Toke Høiland-Jørgensen, brouer,
Jakub Kicinski, John Fastabend, Daniel Borkmann, Saeed Mahameed,
Tariq Toukan
In-Reply-To: <b8c97120-851f-450f-dc71-59350236329e@gmail.com>
On Sat, 2 Feb 2019 14:27:26 -0700
David Ahern <dsahern@gmail.com> wrote:
> On 1/31/19 1:15 PM, Jesper Dangaard Brouer wrote:
> >>
> >> David, Jesper, care to chime in where we ended up in that last thread
> >> discussion this?
> >
> > IHMO packets RX and TX on a device need to be accounted, in standard
> > counters, regardless of XDP. For XDP RX the packet is counted as RX,
> > regardless if XDP choose to XDP_DROP. On XDP TX which is via
> > XDP_REDIRECT or XDP_TX, the driver that transmit the packet need to
> > account the packet in a TX counter (this if often delayed to DMA TX
> > completion handling). We cannot break the expectation that RX and TX
> > counter are visible to userspace stats tools. XDP should not make these
> > packets invisible.
>
> Agreed. What I was pushing on that last thread was Rx, Tx and dropped
> are all accounted by the driver in standard stats. Basically if the
> driver touched it, the driver's counters should indicate that.
Sound like we all agree (except with the dropped counter, see below).
Do notice that mlx5 driver doesn't do this. It is actually rather
confusing to use XDP on mlx5, as when XDP "consume" which include
XDP_DROP, XDP_REDIRECT or XDP_TX, then the driver standard stats are
not incremented... the packet is invisible to "ifconfig" stat based
tools.
> The push back was on dropped packets and whether that counter should be
> bumped on XDP_DROP.
My opinion is the XDP_DROP action should NOT increment the drivers drop
counter. First of all the "dropped" counter is also use for other
stuff, which will confuse that this counter express. Second, choosing
XDP_DROP is a policy choice, it still means it was RX-ed at the driver
level.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Compiler warning
From: Koen Vandeputte @ 2019-02-04 11:43 UTC (permalink / raw)
To: netdev
Hi All,
I'm seeing following compiler warning during kernel compilation
(5.0-rc5 and 4.14.96):
net/core/dev.c: In function 'validate_xmit_skb_list':
net/core/dev.c:3405:15: warning: 'tail' may be used uninitialized in
this function [-Wmaybe-uninitialized]
tail->next = skb;
~~~~~~~~~~~^~~~~
Source shows this:
https://elixir.bootlin.com/linux/v5.0-rc5/source/net/core/dev.c#L3387
Looks like "tail" can get deferenced while it indeed doesn't get
initialized? Kind regards, Koen
^ permalink raw reply
* [PATCH 3.18 20/31] net/rose: fix NULL ax25_cb kernel panic
From: Greg Kroah-Hartman @ 2019-02-04 10:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bernard Pidoux, Dmitry Vyukov,
syzbot+1a2c456a1ea08fa5b5f7, David S. Miller, Ralf Baechle,
linux-hams, netdev
In-Reply-To: <20190204103557.903263774@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Pidoux <f6bvp@free.fr>
[ Upstream commit b0cf029234f9b18e10703ba5147f0389c382bccc ]
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -849,6 +849,7 @@ void rose_link_device_down(struct net_de
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -866,6 +867,10 @@ int rose_route_frame(struct sk_buff *skb
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
^ permalink raw reply
* [PATCH 4.4 38/65] net/rose: fix NULL ax25_cb kernel panic
From: Greg Kroah-Hartman @ 2019-02-04 10:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bernard Pidoux, Dmitry Vyukov,
syzbot+1a2c456a1ea08fa5b5f7, David S. Miller, Ralf Baechle,
linux-hams, netdev
In-Reply-To: <20190204103610.583715954@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Pidoux <f6bvp@free.fr>
[ Upstream commit b0cf029234f9b18e10703ba5147f0389c382bccc ]
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -848,6 +848,7 @@ void rose_link_device_down(struct net_de
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -865,6 +866,10 @@ int rose_route_frame(struct sk_buff *skb
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
^ permalink raw reply
* [PATCH 4.14 07/46] net/rose: fix NULL ax25_cb kernel panic
From: Greg Kroah-Hartman @ 2019-02-04 10:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bernard Pidoux, Dmitry Vyukov,
syzbot+1a2c456a1ea08fa5b5f7, David S. Miller, Ralf Baechle,
linux-hams, netdev
In-Reply-To: <20190204103608.651205056@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Pidoux <f6bvp@free.fr>
[ Upstream commit b0cf029234f9b18e10703ba5147f0389c382bccc ]
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -848,6 +848,7 @@ void rose_link_device_down(struct net_de
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -865,6 +866,10 @@ int rose_route_frame(struct sk_buff *skb
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
^ permalink raw reply
* [PATCH 4.19 12/74] net/rose: fix NULL ax25_cb kernel panic
From: Greg Kroah-Hartman @ 2019-02-04 10:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bernard Pidoux, Dmitry Vyukov,
syzbot+1a2c456a1ea08fa5b5f7, David S. Miller, Ralf Baechle,
linux-hams, netdev
In-Reply-To: <20190204103619.714714157@linuxfoundation.org>
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Pidoux <f6bvp@free.fr>
[ Upstream commit b0cf029234f9b18e10703ba5147f0389c382bccc ]
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -850,6 +850,7 @@ void rose_link_device_down(struct net_de
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -867,6 +868,10 @@ int rose_route_frame(struct sk_buff *skb
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
^ permalink raw reply
* [PATCH 4.19 68/74] of: Convert to using %pOFn instead of device_node.name
From: Greg Kroah-Hartman @ 2019-02-04 10:37 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Frank Rowand, Andrew Lunn,
Florian Fainelli, netdev, Rob Herring, Guenter Roeck
In-Reply-To: <20190204103619.714714157@linuxfoundation.org>
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <robh@kernel.org>
commit a613b26a50136ae90ab13943afe90bcbd34adb44 upstream.
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/of/device.c | 5 +++--
drivers/of/of_mdio.c | 12 ++++++------
drivers/of/of_numa.c | 4 ++--
drivers/of/overlay.c | 4 ++--
drivers/of/platform.c | 8 ++++----
drivers/of/unittest.c | 12 ++++++------
6 files changed, 23 insertions(+), 22 deletions(-)
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -221,7 +221,8 @@ static ssize_t of_device_get_modalias(st
return -ENODEV;
/* Name & Type */
- csize = snprintf(str, len, "of:N%sT%s", dev->of_node->name,
+ /* %p eats all alphanum characters, so %c must be used here */
+ csize = snprintf(str, len, "of:N%pOFn%c%s", dev->of_node, 'T',
dev->of_node->type);
tsize = csize;
len -= csize;
@@ -300,7 +301,7 @@ void of_device_uevent(struct device *dev
if ((!dev) || (!dev->of_node))
return;
- add_uevent_var(env, "OF_NAME=%s", dev->of_node->name);
+ add_uevent_var(env, "OF_NAME=%pOFn", dev->of_node);
add_uevent_var(env, "OF_FULLNAME=%pOF", dev->of_node);
if (dev->of_node->type && strcmp("<NULL>", dev->of_node->type) != 0)
add_uevent_var(env, "OF_TYPE=%s", dev->of_node->type);
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -97,8 +97,8 @@ static int of_mdiobus_register_phy(struc
return rc;
}
- dev_dbg(&mdio->dev, "registered phy %s at address %i\n",
- child->name, addr);
+ dev_dbg(&mdio->dev, "registered phy %pOFn at address %i\n",
+ child, addr);
return 0;
}
@@ -127,8 +127,8 @@ static int of_mdiobus_register_device(st
return rc;
}
- dev_dbg(&mdio->dev, "registered mdio device %s at address %i\n",
- child->name, addr);
+ dev_dbg(&mdio->dev, "registered mdio device %pOFn at address %i\n",
+ child, addr);
return 0;
}
@@ -263,8 +263,8 @@ int of_mdiobus_register(struct mii_bus *
continue;
/* be noisy to encourage people to set reg property */
- dev_info(&mdio->dev, "scan phy %s at address %i\n",
- child->name, addr);
+ dev_info(&mdio->dev, "scan phy %pOFn at address %i\n",
+ child, addr);
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -168,8 +168,8 @@ int of_node_to_nid(struct device_node *d
np = of_get_next_parent(np);
}
if (np && r)
- pr_warn("Invalid \"numa-node-id\" property in node %s\n",
- np->name);
+ pr_warn("Invalid \"numa-node-id\" property in node %pOFn\n",
+ np);
of_node_put(np);
/*
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -427,8 +427,8 @@ static int build_changeset_next_level(st
for_each_child_of_node(overlay_node, child) {
ret = add_changeset_node(ovcs, target_node, child);
if (ret) {
- pr_debug("Failed to apply node @%pOF/%s, err=%d\n",
- target_node, child->name, ret);
+ pr_debug("Failed to apply node @%pOF/%pOFn, err=%d\n",
+ target_node, child, ret);
of_node_put(child);
return ret;
}
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -91,8 +91,8 @@ static void of_device_make_bus_id(struct
*/
reg = of_get_property(node, "reg", NULL);
if (reg && (addr = of_translate_address(node, reg)) != OF_BAD_ADDR) {
- dev_set_name(dev, dev_name(dev) ? "%llx.%s:%s" : "%llx.%s",
- (unsigned long long)addr, node->name,
+ dev_set_name(dev, dev_name(dev) ? "%llx.%pOFn:%s" : "%llx.%pOFn",
+ (unsigned long long)addr, node,
dev_name(dev));
return;
}
@@ -142,8 +142,8 @@ struct platform_device *of_device_alloc(
WARN_ON(rc);
}
if (of_irq_to_resource_table(np, res, num_irq) != num_irq)
- pr_debug("not all legacy IRQ resources mapped for %s\n",
- np->name);
+ pr_debug("not all legacy IRQ resources mapped for %pOFn\n",
+ np);
}
dev->dev.of_node = of_node_get(np);
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -212,8 +212,8 @@ static int __init of_unittest_check_node
for_each_child_of_node(np, child) {
if (child->parent != np) {
- pr_err("Child node %s links to wrong parent %s\n",
- child->name, np->name);
+ pr_err("Child node %pOFn links to wrong parent %pOFn\n",
+ child, np);
rc = -EINVAL;
goto put_child;
}
@@ -1046,16 +1046,16 @@ static void __init of_unittest_platform_
for_each_child_of_node(np, child) {
for_each_child_of_node(child, grandchild)
unittest(of_find_device_by_node(grandchild),
- "Could not create device for node '%s'\n",
- grandchild->name);
+ "Could not create device for node '%pOFn'\n",
+ grandchild);
}
of_platform_depopulate(&test_bus->dev);
for_each_child_of_node(np, child) {
for_each_child_of_node(child, grandchild)
unittest(!of_find_device_by_node(grandchild),
- "device didn't get destroyed '%s'\n",
- grandchild->name);
+ "device didn't get destroyed '%pOFn'\n",
+ grandchild);
}
platform_device_unregister(test_bus);
^ permalink raw reply
* [PATCH 4.20 11/80] net/rose: fix NULL ax25_cb kernel panic
From: Greg Kroah-Hartman @ 2019-02-04 10:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bernard Pidoux, Dmitry Vyukov,
syzbot+1a2c456a1ea08fa5b5f7, David S. Miller, Ralf Baechle,
linux-hams, netdev
In-Reply-To: <20190204103620.287366543@linuxfoundation.org>
4.20-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Pidoux <f6bvp@free.fr>
[ Upstream commit b0cf029234f9b18e10703ba5147f0389c382bccc ]
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -850,6 +850,7 @@ void rose_link_device_down(struct net_de
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -867,6 +868,10 @@ int rose_route_frame(struct sk_buff *skb
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
^ permalink raw reply
* [PATCH 4.9 07/30] net/rose: fix NULL ax25_cb kernel panic
From: Greg Kroah-Hartman @ 2019-02-04 10:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bernard Pidoux, Dmitry Vyukov,
syzbot+1a2c456a1ea08fa5b5f7, David S. Miller, Ralf Baechle,
linux-hams, netdev
In-Reply-To: <20190204103605.271746870@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernard Pidoux <f6bvp@free.fr>
[ Upstream commit b0cf029234f9b18e10703ba5147f0389c382bccc ]
When an internally generated frame is handled by rose_xmit(),
rose_route_frame() is called:
if (!rose_route_frame(skb, NULL)) {
dev_kfree_skb(skb);
stats->tx_errors++;
return NETDEV_TX_OK;
}
We have the same code sequence in Net/Rom where an internally generated
frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
However, in this function NULL argument is tested while it is not in
rose_route_frame().
Then kernel panic occurs later on when calling ax25cmp() with a NULL
ax25_cb argument as reported many times and recently with syzbot.
We need to test if ax25 is NULL before using it.
Testing:
Built kernel with CONFIG_ROSE=y.
Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Bernard Pidoux <f6bvp@free.fr>
Cc: linux-hams@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rose/rose_route.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -848,6 +848,7 @@ void rose_link_device_down(struct net_de
/*
* Route a frame to an appropriate AX.25 connection.
+ * A NULL ax25_cb indicates an internally generated frame.
*/
int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
{
@@ -865,6 +866,10 @@ int rose_route_frame(struct sk_buff *skb
if (skb->len < ROSE_MIN_LEN)
return res;
+
+ if (!ax25)
+ return rose_loopback_queue(skb, NULL);
+
frametype = skb->data[2];
lci = ((skb->data[0] << 8) & 0xF00) + ((skb->data[1] << 0) & 0x0FF);
if (frametype == ROSE_CALL_REQUEST &&
^ permalink raw reply
* [PATCH v2] net: phy: fixed-phy: Drop GPIO from fixed_phy_add()
From: Linus Walleij @ 2019-02-04 10:26 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David S . Miller
Cc: netdev, Laurent Pinchart, Linus Walleij
All users of the fixed_phy_add() pass -1 as GPIO number
to the fixed phy driver, and all users of fixed_phy_register()
pass -1 as GPIO number as well, except for the device
tree MDIO bus.
Any new users should create a proper device and pass the
GPIO as a descriptor associated with the device so delete
the GPIO argument from the calls and drop the code looking
requesting a GPIO in fixed_phy_add().
In fixed phy_register(), investigate the "fixed-link"
node and pick the GPIO descriptor from "link-gpios" if
this property exists. Move the corresponding code out
of of_mdio.c as the fixed phy code anyways requires
OF to be in use.
Tested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Collected Andrew's Tested-by
- Drop and reword some comments.
- Fix an instance of missing reverse christmas tree.
- Add a newline in fixed_phy_add()
---
.../device_drivers/stmicro/stmmac.txt | 2 +-
arch/m68k/coldfire/m5272.c | 2 +-
arch/mips/ar7/platform.c | 4 +-
arch/mips/bcm47xx/setup.c | 2 +-
drivers/net/dsa/dsa_loop.c | 2 +-
drivers/net/ethernet/broadcom/bgmac.c | 2 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 +-
drivers/net/phy/fixed_phy.c | 82 ++++++++++++++-----
drivers/net/usb/lan78xx.c | 3 +-
drivers/of/of_mdio.c | 9 +-
include/linux/phy_fixed.h | 8 +-
11 files changed, 72 insertions(+), 46 deletions(-)
diff --git a/Documentation/networking/device_drivers/stmicro/stmmac.txt b/Documentation/networking/device_drivers/stmicro/stmmac.txt
index 2bb07078f535..1ae979fd90d2 100644
--- a/Documentation/networking/device_drivers/stmicro/stmmac.txt
+++ b/Documentation/networking/device_drivers/stmicro/stmmac.txt
@@ -267,7 +267,7 @@ static struct fixed_phy_status stmmac0_fixed_phy_status = {
During the board's device_init we can configure the first
MAC for fixed_link by calling:
- fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status, -1);
+ fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status);
and the second one, with a real PHY device attached to the bus,
by using the stmmac_mdio_bus_data structure (to provide the id, the
reset procedure etc).
diff --git a/arch/m68k/coldfire/m5272.c b/arch/m68k/coldfire/m5272.c
index ad1185c68df7..6b3ab583c698 100644
--- a/arch/m68k/coldfire/m5272.c
+++ b/arch/m68k/coldfire/m5272.c
@@ -127,7 +127,7 @@ static struct fixed_phy_status nettel_fixed_phy_status __initdata = {
static int __init init_BSP(void)
{
m5272_uarts_init();
- fixed_phy_add(PHY_POLL, 0, &nettel_fixed_phy_status, -1);
+ fixed_phy_add(PHY_POLL, 0, &nettel_fixed_phy_status);
return 0;
}
diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
index f09262e0a72f..10ff07b7721e 100644
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -683,7 +683,7 @@ static int __init ar7_register_devices(void)
if (ar7_has_high_cpmac()) {
res = fixed_phy_add(PHY_POLL, cpmac_high.id,
- &fixed_phy_status, -1);
+ &fixed_phy_status);
if (!res) {
cpmac_get_mac(1, cpmac_high_data.dev_addr);
@@ -696,7 +696,7 @@ static int __init ar7_register_devices(void)
} else
cpmac_low_data.phy_mask = 0xffffffff;
- res = fixed_phy_add(PHY_POLL, cpmac_low.id, &fixed_phy_status, -1);
+ res = fixed_phy_add(PHY_POLL, cpmac_low.id, &fixed_phy_status);
if (!res) {
cpmac_get_mac(0, cpmac_low_data.dev_addr);
res = platform_device_register(&cpmac_low);
diff --git a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
index 6054d49e608e..2517b8b611a8 100644
--- a/arch/mips/bcm47xx/setup.c
+++ b/arch/mips/bcm47xx/setup.c
@@ -243,7 +243,7 @@ static int __init bcm47xx_register_bus_complete(void)
bcm47xx_leds_register();
bcm47xx_workarounds();
- fixed_phy_add(PHY_POLL, 0, &bcm47xx_fixed_phy_status, -1);
+ fixed_phy_add(PHY_POLL, 0, &bcm47xx_fixed_phy_status);
return 0;
}
device_initcall(bcm47xx_register_bus_complete);
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index 816f34d64736..17482ae09aa5 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -343,7 +343,7 @@ static int __init dsa_loop_init(void)
unsigned int i;
for (i = 0; i < NUM_FIXED_PHYS; i++)
- phydevs[i] = fixed_phy_register(PHY_POLL, &status, -1, NULL);
+ phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL);
return mdio_driver_register(&dsa_loop_drv);
}
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index cabc8e49ad24..76b480e65698 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1446,7 +1446,7 @@ int bgmac_phy_connect_direct(struct bgmac *bgmac)
struct phy_device *phy_dev;
int err;
- phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
if (!phy_dev || IS_ERR(phy_dev)) {
dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
return -ENODEV;
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index aceb9b7b55bd..51880d83131a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -525,7 +525,7 @@ static int bcmgenet_mii_pd_init(struct bcmgenet_priv *priv)
.asym_pause = 0,
};
- phydev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
if (!phydev || IS_ERR(phydev)) {
dev_err(kdev, "failed to register fixed PHY device\n");
return -ENODEV;
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 72d43c88e6ff..029f63af913a 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -22,7 +22,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/of.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/seqlock.h>
#include <linux/idr.h>
#include <linux/netdevice.h>
@@ -42,7 +42,7 @@ struct fixed_phy {
bool no_carrier;
int (*link_update)(struct net_device *, struct fixed_phy_status *);
struct list_head node;
- int link_gpio;
+ struct gpio_desc *link_gpiod;
};
static struct platform_device *pdev;
@@ -71,8 +71,8 @@ EXPORT_SYMBOL_GPL(fixed_phy_change_carrier);
static void fixed_phy_update(struct fixed_phy *fp)
{
- if (!fp->no_carrier && gpio_is_valid(fp->link_gpio))
- fp->status.link = !!gpio_get_value_cansleep(fp->link_gpio);
+ if (!fp->no_carrier && fp->link_gpiod)
+ fp->status.link = !!gpiod_get_value_cansleep(fp->link_gpiod);
}
static int fixed_mdio_read(struct mii_bus *bus, int phy_addr, int reg_num)
@@ -137,9 +137,9 @@ int fixed_phy_set_link_update(struct phy_device *phydev,
}
EXPORT_SYMBOL_GPL(fixed_phy_set_link_update);
-int fixed_phy_add(unsigned int irq, int phy_addr,
- struct fixed_phy_status *status,
- int link_gpio)
+static int fixed_phy_add_gpiod(unsigned int irq, int phy_addr,
+ struct fixed_phy_status *status,
+ struct gpio_desc *gpiod)
{
int ret;
struct fixed_mdio_bus *fmb = &platform_fmb;
@@ -160,24 +160,19 @@ int fixed_phy_add(unsigned int irq, int phy_addr,
fp->addr = phy_addr;
fp->status = *status;
- fp->link_gpio = link_gpio;
-
- if (gpio_is_valid(fp->link_gpio)) {
- ret = gpio_request_one(fp->link_gpio, GPIOF_DIR_IN,
- "fixed-link-gpio-link");
- if (ret)
- goto err_regs;
- }
+ fp->link_gpiod = gpiod;
fixed_phy_update(fp);
list_add_tail(&fp->node, &fmb->phys);
return 0;
+}
-err_regs:
- kfree(fp);
- return ret;
+int fixed_phy_add(unsigned int irq, int phy_addr,
+ struct fixed_phy_status *status) {
+
+ return fixed_phy_add_gpiod(irq, phy_addr, status, NULL);
}
EXPORT_SYMBOL_GPL(fixed_phy_add);
@@ -191,8 +186,8 @@ static void fixed_phy_del(int phy_addr)
list_for_each_entry_safe(fp, tmp, &fmb->phys, node) {
if (fp->addr == phy_addr) {
list_del(&fp->node);
- if (gpio_is_valid(fp->link_gpio))
- gpio_free(fp->link_gpio);
+ if (fp->link_gpiod)
+ gpiod_put(fp->link_gpiod);
kfree(fp);
ida_simple_remove(&phy_fixed_ida, phy_addr);
return;
@@ -200,12 +195,50 @@ static void fixed_phy_del(int phy_addr)
}
}
+#ifdef CONFIG_OF_GPIO
+static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
+{
+ struct device_node *fixed_link_node;
+ struct gpio_desc *gpiod;
+
+ if (!np)
+ return NULL;
+
+ fixed_link_node = of_get_child_by_name(np, "fixed-link");
+ if (!fixed_link_node)
+ return NULL;
+
+ /*
+ * As the fixed link is just a device tree node without any
+ * Linux device associated with it, we simply have obtain
+ * the GPIO descriptor from the device tree like this.
+ */
+ gpiod = gpiod_get_from_of_node(fixed_link_node, "link-gpios", 0,
+ GPIOD_IN, "mdio");
+ of_node_put(fixed_link_node);
+ if (IS_ERR(gpiod)) {
+ if (PTR_ERR(gpiod) == -EPROBE_DEFER)
+ return gpiod;
+ pr_err("error getting GPIO for fixed link %pOF, proceed without\n",
+ fixed_link_node);
+ gpiod = NULL;
+ }
+
+ return gpiod;
+}
+#else
+static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
+{
+ return NULL;
+}
+#endif
+
struct phy_device *fixed_phy_register(unsigned int irq,
struct fixed_phy_status *status,
- int link_gpio,
struct device_node *np)
{
struct fixed_mdio_bus *fmb = &platform_fmb;
+ struct gpio_desc *gpiod = NULL;
struct phy_device *phy;
int phy_addr;
int ret;
@@ -213,12 +246,17 @@ struct phy_device *fixed_phy_register(unsigned int irq,
if (!fmb->mii_bus || fmb->mii_bus->state != MDIOBUS_REGISTERED)
return ERR_PTR(-EPROBE_DEFER);
+ /* Check if we have a GPIO associated with this fixed phy */
+ gpiod = fixed_phy_get_gpiod(np);
+ if (IS_ERR(gpiod))
+ return ERR_CAST(gpiod);
+
/* Get the next available PHY address, up to PHY_MAX_ADDR */
phy_addr = ida_simple_get(&phy_fixed_ida, 0, PHY_MAX_ADDR, GFP_KERNEL);
if (phy_addr < 0)
return ERR_PTR(phy_addr);
- ret = fixed_phy_add(irq, phy_addr, status, link_gpio);
+ ret = fixed_phy_add_gpiod(irq, phy_addr, status, gpiod);
if (ret < 0) {
ida_simple_remove(&phy_fixed_ida, phy_addr);
return ERR_PTR(ret);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index e96bc0c6140f..3d92ea6fcc02 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2051,8 +2051,7 @@ static struct phy_device *lan7801_phy_init(struct lan78xx_net *dev)
phydev = phy_find_first(dev->mdiobus);
if (!phydev) {
netdev_dbg(dev->net, "PHY Not Found!! Registering Fixed PHY\n");
- phydev = fixed_phy_register(PHY_POLL, &fphy_status, -1,
- NULL);
+ phydev = fixed_phy_register(PHY_POLL, &fphy_status, NULL);
if (IS_ERR(phydev)) {
netdev_err(dev->net, "No PHY/fixed_PHY found\n");
return NULL;
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 5ad1342f5682..de6157357e26 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -16,7 +16,6 @@
#include <linux/phy.h>
#include <linux/phy_fixed.h>
#include <linux/of.h>
-#include <linux/of_gpio.h>
#include <linux/of_irq.h>
#include <linux/of_mdio.h>
#include <linux/of_net.h>
@@ -463,7 +462,6 @@ int of_phy_register_fixed_link(struct device_node *np)
struct device_node *fixed_link_node;
u32 fixed_link_prop[5];
const char *managed;
- int link_gpio = -1;
if (of_property_read_string(np, "managed", &managed) == 0 &&
strcmp(managed, "in-band-status") == 0) {
@@ -485,11 +483,7 @@ int of_phy_register_fixed_link(struct device_node *np)
status.pause = of_property_read_bool(fixed_link_node, "pause");
status.asym_pause = of_property_read_bool(fixed_link_node,
"asym-pause");
- link_gpio = of_get_named_gpio_flags(fixed_link_node,
- "link-gpios", 0, NULL);
of_node_put(fixed_link_node);
- if (link_gpio == -EPROBE_DEFER)
- return -EPROBE_DEFER;
goto register_phy;
}
@@ -508,8 +502,7 @@ int of_phy_register_fixed_link(struct device_node *np)
return -ENODEV;
register_phy:
- return PTR_ERR_OR_ZERO(fixed_phy_register(PHY_POLL, &status, link_gpio,
- np));
+ return PTR_ERR_OR_ZERO(fixed_phy_register(PHY_POLL, &status, np));
}
EXPORT_SYMBOL(of_phy_register_fixed_link);
diff --git a/include/linux/phy_fixed.h b/include/linux/phy_fixed.h
index 9525567b1951..c78fc203db43 100644
--- a/include/linux/phy_fixed.h
+++ b/include/linux/phy_fixed.h
@@ -15,11 +15,9 @@ struct device_node;
#if IS_ENABLED(CONFIG_FIXED_PHY)
extern int fixed_phy_change_carrier(struct net_device *dev, bool new_carrier);
extern int fixed_phy_add(unsigned int irq, int phy_id,
- struct fixed_phy_status *status,
- int link_gpio);
+ struct fixed_phy_status *status);
extern struct phy_device *fixed_phy_register(unsigned int irq,
struct fixed_phy_status *status,
- int link_gpio,
struct device_node *np);
extern void fixed_phy_unregister(struct phy_device *phydev);
extern int fixed_phy_set_link_update(struct phy_device *phydev,
@@ -27,14 +25,12 @@ extern int fixed_phy_set_link_update(struct phy_device *phydev,
struct fixed_phy_status *));
#else
static inline int fixed_phy_add(unsigned int irq, int phy_id,
- struct fixed_phy_status *status,
- int link_gpio)
+ struct fixed_phy_status *status)
{
return -ENODEV;
}
static inline struct phy_device *fixed_phy_register(unsigned int irq,
struct fixed_phy_status *status,
- int gpio_link,
struct device_node *np)
{
return ERR_PTR(-ENODEV);
--
2.20.1
^ permalink raw reply related
* [PATCH net v3] net: dp83640: expire old TX-skb
From: Sebastian Andrzej Siewior @ 2019-02-04 10:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Richard Cochran, Florian Fainelli, Heiner Kallweit, netdev
In-Reply-To: <20190201211551.GD8274@lunn.ch>
During sendmsg() a cloned skb is saved via dp83640_txtstamp() in
->tx_queue. After the NIC sends this packet, the PHY will reply with a
timestamp for that TX packet. If the cable is pulled at the right time I
don't see that packet. It might gets flushed as part of queue shutdown
on NIC's side.
Once the link is up again then after the next sendmsg() we enqueue
another skb in dp83640_txtstamp() and have two on the list. Then the PHY
will send a reply and decode_txts() attaches it to the first skb on the
list.
No crash occurs since refcounting works but we are one packet behind.
linuxptp/ptp4l usually closes the socket and opens a new one (in such a
timeout case) so those "stale" replies never get there. However it does
not resume normal operation anymore.
Purge old skbs in decode_txts().
Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Acked-by: Richard Cochran <richardcochran@gmail.com>
---
v2…v3:
- added a Fixes: tag, Richard's Acked-by and `net' after PATCH.
RFC … v2:
- reverse xmas tree
- stable tag
drivers/net/phy/dp83640.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 18b41bc345ab..6e8807212aa3 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -898,14 +898,14 @@ static void decode_txts(struct dp83640_private *dp83640,
struct phy_txts *phy_txts)
{
struct skb_shared_hwtstamps shhwtstamps;
+ struct dp83640_skb_info *skb_info;
struct sk_buff *skb;
- u64 ns;
u8 overflow;
+ u64 ns;
/* We must already have the skb that triggered this. */
-
+again:
skb = skb_dequeue(&dp83640->tx_queue);
-
if (!skb) {
pr_debug("have timestamp but tx_queue empty\n");
return;
@@ -920,6 +920,11 @@ static void decode_txts(struct dp83640_private *dp83640,
}
return;
}
+ skb_info = (struct dp83640_skb_info *)skb->cb;
+ if (time_after(jiffies, skb_info->tmo)) {
+ kfree_skb(skb);
+ goto again;
+ }
ns = phy2txts(phy_txts);
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
@@ -1472,6 +1477,7 @@ static bool dp83640_rxtstamp(struct phy_device *phydev,
static void dp83640_txtstamp(struct phy_device *phydev,
struct sk_buff *skb, int type)
{
+ struct dp83640_skb_info *skb_info = (struct dp83640_skb_info *)skb->cb;
struct dp83640_private *dp83640 = phydev->priv;
switch (dp83640->hwts_tx_en) {
@@ -1484,6 +1490,7 @@ static void dp83640_txtstamp(struct phy_device *phydev,
/* fall through */
case HWTSTAMP_TX_ON:
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
+ skb_info->tmo = jiffies + SKB_TIMESTAMP_TIMEOUT;
skb_queue_tail(&dp83640->tx_queue, skb);
break;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH stable 4.4 v2 00/11] fix FragmentSmack in stable branch (CVE-2018-5391)
From: Greg KH @ 2019-02-04 10:03 UTC (permalink / raw)
To: Mao Wenan; +Cc: stable, edumazet, netdev, davem, eric.dumazet
In-Reply-To: <1548384524-174152-1-git-send-email-maowenan@huawei.com>
On Fri, Jan 25, 2019 at 10:48:33AM +0800, Mao Wenan wrote:
> There is one CVE: CVE-2018-5391 kernel: IP fragments with random offsets allow a
> remote denial of service (FragmentSmack),
> A fix is a merge commit in the Linux kernel tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c30f1fc041b74ecdb072dd44f858750414b8b19f
>
> consisting of the following commits:
> 7969e5c40dfd04799d4341f1b7cd266b6e47f227 ip: discard IPv4 datagrams with overlapping segments.
> 385114dec8a49b5e5945e77ba7de6356106713f4 net: modify skb_rbtree_purge to return the truesize of all purged skbs.
> fa0f527358bd900ef92f925878ed6bfbd51305cc ip: use rb trees for IP frag queue.
>
> All above patches are with rb tree to fix this CVE, which is very similar the CVE-2018-5390, that I have backport
> to stable 4.4 branch in last year.
>
> In these patchset, I will backport some patches to fix CVE-2018-5391 with rb tree.
>
> v1->v2: in this patch, ipv6: defrag: drop non-last frags smaller than min mtu
> fix the incorrect return value of nf_ct_frag6_gather.
Thanks for fixing that up, I've queued the patches up now, let's see if
they pass the testers :)
greg k-h
^ permalink raw reply
* [PATCH v2 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2019-02-04 8:59 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org, Pankaj Bansal
In-Reply-To: <20190204142435.21175-1-pankaj.bansal@nxp.com>
Add support for an MDIO bus multiplexer controlled by a regmap
device, like an FPGA.
Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
attached to the i2c bus.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V2:
- Added Kconfig entry for regmap based mdio mux
- restrict the comment lines to 80 chars
- use kerneldoc formatting for this function documentation.
drivers/net/phy/Kconfig | 14 +++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-regmap.c | 171 ++++++++++++++++++++++++++++
include/linux/mdio-mux.h | 34 ++++++
4 files changed, 220 insertions(+)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 3d187cd50eb0..93ef2505caba 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -87,6 +87,20 @@ config MDIO_BUS_MUX_MMIOREG
Currently, only 8/16/32 bits registers are supported.
+config MDIO_BUS_MUX_REGMAP
+ tristate "regmap device controlled MDIO bus multiplexers"
+ depends on OF_MDIO && REGMAP
+ select MDIO_BUS_MUX
+ help
+ This module provides a driver for MDIO bus multiplexers that
+ are controlled via a regmap device, like an FPGA connected to i2c bus
+ or spi bus or memory mapped FPGA.
+ The multiplexer connects one of several child MDIO busses to a
+ parent bus. Child bus selection is under the control of one of
+ the FPGA's registers.
+
+ Currently, only 32 bits registers are supported.
+
config MDIO_CAVIUM
tristate
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b7d60e..0827a700eb31 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MDIO_BCM_IPROC) += mdio-bcm-iproc.o
obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
+obj-$(CONFIG_MDIO_BUS_MUX_REGMAP) += mdio-mux-regmap.o
obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-iproc.o
obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
diff --git a/drivers/net/phy/mdio-mux-regmap.c b/drivers/net/phy/mdio-mux-regmap.c
new file mode 100644
index 000000000000..f2cb3cad1d9b
--- /dev/null
+++ b/drivers/net/phy/mdio-mux-regmap.c
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Simple regmap based MDIO MUX driver
+ *
+ * Copyright 2018-2019 NXP
+ *
+ * Based on mdio-mux-mmioreg.c by Timur Tabi
+ *
+ * Author:
+ * Pankaj Bansal <pankaj.bansal@nxp.com>
+ */
+
+#include <linux/platform_device.h>
+#include <linux/device.h>
+#include <linux/of_mdio.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/mdio-mux.h>
+#include <linux/regmap.h>
+
+struct mdio_mux_regmap_state {
+ void *mux_handle;
+ struct device *dev;
+ struct regmap *regmap;
+ u32 mux_reg;
+ u32 mask;
+};
+
+/**
+ * mdio_mux_regmap_switch_fn - This function is called by the mdio-mux layer
+ * when it thinks the mdio bus multiplexer needs
+ * to switch.
+ * @current_child: current value of the mux register (masked via s->mask).
+ * @desired_child: value of the 'reg' property of the target child MDIO node.
+ * @data: Private data used by this switch_fn passed to mdio_mux_init function
+ * via mdio_mux_init(.., .., .., .., data, ..).
+ *
+ * The first time this function is called, current_child == -1.
+ * If current_child == desired_child, then the mux is already set to the
+ * correct bus.
+ */
+static int mdio_mux_regmap_switch_fn(int current_child, int desired_child,
+ void *data)
+{
+ struct mdio_mux_regmap_state *s = data;
+ bool change;
+ int ret;
+
+ ret = regmap_update_bits_check(s->regmap,
+ s->mux_reg,
+ s->mask,
+ desired_child,
+ &change);
+
+ if (ret)
+ return ret;
+ if (change)
+ dev_dbg(s->dev, "%s %d -> %d\n", __func__, current_child,
+ desired_child);
+ return ret;
+}
+
+/**
+ * mdio_mux_regmap_init - control MDIO bus muxing using regmap constructs.
+ * @dev: device with which regmap construct is associated.
+ * @mux_node: mdio bus mux node that contains parent mdio bus phandle.
+ * This node also contains sub nodes, where each subnode denotes
+ * a child mdio bus. All the child mdio buses are muxed, i.e. at a
+ * time only one of the child mdio buses can be used.
+ * @data: to store the address of data allocated by this function
+ */
+int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data)
+{
+ struct device_node *child;
+ struct mdio_mux_regmap_state *s;
+ int ret;
+ u32 val;
+
+ dev_dbg(dev, "probing node %pOF\n", mux_node);
+
+ s = devm_kzalloc(dev, sizeof(*s), GFP_KERNEL);
+ if (!s)
+ return -ENOMEM;
+
+ s->regmap = dev_get_regmap(dev, NULL);
+ if (IS_ERR(s->regmap)) {
+ dev_err(dev, "Failed to get parent regmap\n");
+ return PTR_ERR(s->regmap);
+ }
+
+ ret = of_property_read_u32(mux_node, "reg", &s->mux_reg);
+ if (ret) {
+ dev_err(dev, "missing or invalid reg property\n");
+ return -ENODEV;
+ }
+
+ /* Test Register read write */
+ ret = regmap_read(s->regmap, s->mux_reg, &val);
+ if (ret) {
+ dev_err(dev, "error while reading reg\n");
+ return ret;
+ }
+
+ ret = regmap_write(s->regmap, s->mux_reg, val);
+ if (ret) {
+ dev_err(dev, "error while writing reg\n");
+ return ret;
+ }
+
+ ret = of_property_read_u32(mux_node, "mux-mask", &s->mask);
+ if (ret) {
+ dev_err(dev, "missing or invalid mux-mask property\n");
+ return -ENODEV;
+ }
+
+ /* Verify that the 'reg' property of each child MDIO bus does not
+ * set any bits outside of the 'mask'.
+ */
+ for_each_available_child_of_node(mux_node, child) {
+ ret = of_property_read_u32(child, "reg", &val);
+ if (ret) {
+ dev_err(dev, "%pOF is missing a 'reg' property\n",
+ child);
+ of_node_put(child);
+ return -ENODEV;
+ }
+ if (val & ~s->mask) {
+ dev_err(dev,
+ "%pOF has a 'reg' value with unmasked bits\n",
+ child);
+ of_node_put(child);
+ return -ENODEV;
+ }
+ }
+
+ ret = mdio_mux_init(dev, mux_node, mdio_mux_regmap_switch_fn,
+ &s->mux_handle, s, NULL);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "failed to register mdio-mux bus %pOF\n",
+ mux_node);
+ return ret;
+ }
+
+ *data = s;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mdio_mux_regmap_init);
+
+/**
+ * mdio_mux_regmap_uninit - relinquish the control of MDIO bus muxing using
+ * regmap constructs.
+ * @data: address of data allocated by mdio_mux_regmap_init
+ */
+int mdio_mux_regmap_uninit(void *data)
+{
+ struct mdio_mux_regmap_state *s = data;
+
+ mdio_mux_uninit(s->mux_handle);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mdio_mux_regmap_uninit);
+
+MODULE_AUTHOR("Pankaj Bansal <pankaj.bansal@nxp.com>");
+MODULE_DESCRIPTION("regmap based MDIO MUX driver");
+MODULE_LICENSE("GPL");
+
diff --git a/include/linux/mdio-mux.h b/include/linux/mdio-mux.h
index a5d58f221939..fb715d56999b 100644
--- a/include/linux/mdio-mux.h
+++ b/include/linux/mdio-mux.h
@@ -29,4 +29,38 @@ int mdio_mux_init(struct device *dev,
void mdio_mux_uninit(void *mux_handle);
+#ifdef CONFIG_MDIO_BUS_MUX_REGMAP
+/**
+ * mdio_mux_regmap_init - control MDIO bus muxing using regmap constructs.
+ * @dev: device with which regmap construct is associated.
+ * @mux_node: mdio bus mux node that contains parent mdio bus phandle.
+ * This node also contains sub nodes, where each subnode denotes
+ * a child mdio bus. All the child mdio buses are muxed, i.e. at a
+ * time only one of the child mdio buses can be used.
+ * @data: to store the address of data allocated by this function
+ */
+int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data);
+
+/**
+ * mdio_mux_regmap_uninit - relinquish the control of MDIO bus muxing using
+ * regmap constructs.
+ * @data: address of data allocated by mdio_mux_regmap_init
+ */
+int mdio_mux_regmap_uninit(void *data);
+#else /* CONFIG_MDIO_BUS_MUX_REGMAP */
+static inline int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data)
+{
+ return -ENODEV;
+}
+
+static inline int mdio_mux_regmap_uninit(void *data)
+{
+ return 0;
+}
+#endif /* CONFIG_MDIO_BUS_MUX_REGMAP */
+
#endif /* __LINUX_MDIO_MUX_H */
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2019-02-04 8:59 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org, Pankaj Bansal
In-Reply-To: <20190204142435.21175-1-pankaj.bansal@nxp.com>
Add support for an MDIO bus multiplexer controlled by a regmap
device, like an FPGA.
Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA
attached to the i2c bus.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V2:
- New file describing the device tree bindings for regmap controlled devices'
mdio mux
.../bindings/net/mdio-mux-regmap.txt | 167 +++++++++++++++++
1 file changed, 167 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
new file mode 100644
index 000000000000..8968f317965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
@@ -0,0 +1,167 @@
+Properties for an MDIO bus multiplexer controlled by a regmap
+
+This is a special case of a MDIO bus multiplexer. A regmap device,
+like an FPGA, is used to control which child bus is connected. The mdio-mux
+node must be a child of the device that is controlled by a regmap.
+The driver currently only supports devices with upto 32-bit registers.
+
+Required properties in addition to the generic multiplexer properties:
+
+- reg : integer, contains the offset of the register that controls the bus
+ multiplexer. it can be 32 bit number.
+
+- mux-mask : integer, contains an 32 bit mask that specifies which
+ bits in the register control the actual bus multiplexer. The
+ 'reg' property of each child mdio-mux node must be constrained by
+ this mask.
+
+Example 1:
+
+The FPGA node defines a i2c connected FPGA with a register space of 0x30 bytes.
+For the "EMI2" MDIO bus, register 0x54 (BRDCFG4) controls the mux on that bus.
+A bitmask of 0x07 means that bits 0, 1 and 2 (bit 0 is lsb) are the bits on
+BRDCFG4 that control the actual mux.
+
+i2c@2000000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2000000 0x0 0x10000>;
+ interrupts = <0 34 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ fsl-scl-gpio = <&gpio2 15 0>;
+ status = "okay";
+
+ /* The FPGA node */
+ fpga@66 {
+ compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>; // fpga device address on i2c bus
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-mux-2@54 {
+ mdio-parent-bus = <&emdio2>; /* MDIO bus */
+ reg = <0x54>; /* BRDCFG4 */
+ mux-mask = <0x07>; /* EMI2_MDIO */
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ mdio@0 { // Slot 1
+ reg = <0x00>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@@1 {
+ reg = <1>;
+ compatible = "ethernet-phy-id0210.7441";
+ };
+
+ ethernet-phy@@0 {
+ reg = <0>;
+ compatible = "ethernet-phy-id0210.7441";
+ };
+ };
+
+ mdio@1 { // Slot 2
+ reg = <0x01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ };
+
+ mdio@2 { // Slot 3
+ reg = <0x02>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ };
+ };
+ };
+};
+
+/* The parent MDIO bus. */
+emdio2: mdio@0x8B97000 {
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0x0 0x8B97000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ little-endian;
+};
+
+Example 2:
+
+The FPGA node defines a memory mapped FPGA with a register space of 0x100 bytes.
+For the "EMI1" MDIO bus, register 0x54 (BRDCFG4) controls the mux on that bus.
+A bitmask of 0xe0 means that bits 5, 6 and 7 (bit 0 is lsb) are the bits on
+BRDCFG4 that control the actual mux.
+
+ifc: ifc@1530000 {
+ compatible = "fsl,ifc", "simple-bus";
+ reg = <0x0 0x1530000 0x0 0x10000>;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ /* NOR, NAND Flashes and FPGA on board */
+ ranges = <0x0 0x0 0x0 0x60000000 0x08000000
+ 0x2 0x0 0x0 0x7e800000 0x00010000
+ 0x3 0x0 0x0 0x7fb00000 0x00000100>;
+ status = "okay";
+
+ /* The FPGA node */
+ fpga: board-control@3,0 {
+ compatible = "fsl,ls1021aqds-fpga", "fsl,fpga-qixis";
+ reg = <0x3 0x0 0x0000100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-mux-1@54 {
+ mdio-parent-bus = <&emdio1>; /* MDIO bus */
+ reg = <0x54>; /* BRDCFG4 */
+ mux-mask = <0xe0>; /* EMI1_MDIO */
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ mdio@0 { // Onboard PHYs rgmii_phy1
+ reg = <0x00>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@@1 {
+ reg = <1>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ };
+ };
+
+ mdio@20 { // Onboard PHYs rgmii_phy2
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethernet-phy@2 {
+ reg = <0x2>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ };
+ };
+
+ mdio@40 { // Onboard PHYs rgmii_phy3
+ reg = <0x40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethernet-phy@3 {
+ reg = <0x3>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ };
+ };
+ };
+ };
+};
+
+/* The parent MDIO bus. */
+emdio1: mdio@2d24000 {
+ compatible = "gianfar";
+ device_type = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2d24000 0x0 0x4000>,
+ <0x0 0x2d10030 0x0 0x4>;
+};
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/2] add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2019-02-04 8:59 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: netdev@vger.kernel.org, Pankaj Bansal, Varun Sethi
Add support for an MDIO bus multiplexer controlled by a regmap device,
like an FPGA.
These apis is an extension of the existing driver
drivers/net/phy/mdio-mux-mmioreg.c.
The problem with mmioreg driver is that it can operate only on memory
mapped devices.
but if we have a device that controls mdio muxing and that device is
controlled using i2c or spi, then it will not work.
Therefore, added apis that can be used by regmap device to control mdio mux.
Tested on a NXP LX2160AQDS board which uses the "QIXIS" FPGA attached to the
i2c bus.
This is my second attempt at this.
In my previous approach i wrote a separate driver for regmap apis.
But then i realized that it is not meant to control a specific device.
It is meant to control some registers of parent device.
Therefore, IMO this should not be a Platform driver and there should not
be any "compatible" property to which this driver is associated.
The previous approach patches and discussion can be accessed here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg252744.html
Cc: Varun Sethi <V.Sethi@nxp.com>
---
Notes:
V1:
- https://www.spinics.net/lists/netdev/msg548027.html
Pankaj Bansal (2):
dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
netdev/phy: add MDIO bus multiplexer driven by a regmap
.../bindings/net/mdio-mux-regmap.txt | 167 +++++++++++++++++
drivers/net/phy/Kconfig | 14 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-regmap.c | 171 ++++++++++++++++++
include/linux/mdio-mux.h | 34 ++++
5 files changed, 387 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mdio-mux-regmap.txt
create mode 100644 drivers/net/phy/mdio-mux-regmap.c
--
2.17.1
^ permalink raw reply
* [PATCH v2] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Pankaj Bansal @ 2019-02-04 8:51 UTC (permalink / raw)
To: Shawn Guo, Leo Li, Andrew Lunn, Florian Fainelli
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Pankaj Bansal
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:
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 | 115 +++++++++++++++++
.../boot/dts/freescale/fsl-lx2160a.dtsi | 18 +++
2 files changed, 133 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..2c3020a72d41 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
@@ -46,6 +46,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>;
+ };
+ 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..a74045ad22ad 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -762,5 +762,23 @@
<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>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ little-endian; /* force the driver in LE mode */
+ };
+
+ /* WRIOP0: 0x8b8_0000, E-MDIO2: 0x1_7000 */
+ emdio2: mdio@8b97000 {
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0x0 0x8b97000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ little-endian; /* force the driver in LE mode */
+ };
};
};
--
2.17.1
^ permalink raw reply related
* Re: WARNING: refcount bug in nr_release
From: Dmitry Vyukov @ 2019-02-04 8:04 UTC (permalink / raw)
To: syzbot, Cong Wang
Cc: David Miller, linux-hams, LKML, netdev, Ralf Baechle,
syzkaller-bugs
In-Reply-To: <000000000000ea7ffe057edb3156@google.com>
On Mon, Jan 7, 2019 at 10:53 AM syzbot
<syzbot+b0b1952f5864b4009b09@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: f1c2f8857c5a Merge tag 'powerpc-4.21-2' of git://git.kerne..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16af96bb400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=47c29c309c47af16
> dashboard link: https://syzkaller.appspot.com/bug?extid=b0b1952f5864b4009b09
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+b0b1952f5864b4009b09@syzkaller.appspotmail.com
#syz fix: netrom: switch to sock timer API
> ------------[ cut here ]------------
> refcount_t: increment on 0; use-after-free.
> WARNING: CPU: 1 PID: 3768 at lib/refcount.c:153 refcount_inc_checked
> lib/refcount.c:153 [inline]
> WARNING: CPU: 1 PID: 3768 at lib/refcount.c:153
> refcount_inc_checked+0x61/0x70 lib/refcount.c:151
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 1 PID: 3768 Comm: syz-executor5 Not tainted 4.20.0+ #11
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
> panic+0x2cb/0x65c kernel/panic.c:214
> __warn.cold+0x20/0x48 kernel/panic.c:571
> report_bug+0x263/0x2b0 lib/bug.c:186
> fixup_bug arch/x86/kernel/traps.c:178 [inline]
> fixup_bug arch/x86/kernel/traps.c:173 [inline]
> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
> do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
> RIP: 0010:refcount_inc_checked lib/refcount.c:153 [inline]
> RIP: 0010:refcount_inc_checked+0x61/0x70 lib/refcount.c:151
> Code: 1d ec 29 c8 06 31 ff 89 de e8 fb 1a f2 fd 84 db 75 dd e8 b2 19 f2 fd
> 48 c7 c7 e0 98 81 88 c6 05 cc 29 c8 06 01 e8 df 6e bb fd <0f> 0b eb c1 90
> 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 49
> RSP: 0018:ffff8880675af460 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff81684ce6 RDI: 0000000000000005
> RBP: ffff8880675af470 R08: ffff88806164e600 R09: ffffed1015ce5021
> R10: ffffed1015ce5020 R11: ffff8880ae728107 R12: ffff88808cf2a940
> R13: ffff88809669c1a0 R14: ffff88808cf2ac28 R15: ffff88808cf2a940
> sock_hold include/net/sock.h:647 [inline]
> nr_release+0x62/0x3c0 net/netrom/af_netrom.c:523
> __sock_release+0xd3/0x250 net/socket.c:579
> sock_close+0x1b/0x30 net/socket.c:1141
> __fput+0x3c5/0xb10 fs/file_table.c:278
> ____fput+0x16/0x20 fs/file_table.c:309
> task_work_run+0x1f4/0x2b0 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x19d6/0x2650 kernel/exit.c:867
> do_group_exit+0x177/0x430 kernel/exit.c:970
> get_signal+0x8b4/0x19b0 kernel/signal.c:2517
> do_signal+0x91/0x1ea0 arch/x86/kernel/signal.c:816
> exit_to_usermode_loop+0x2f7/0x3b0 arch/x86/entry/common.c:162
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x696/0x800 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457ec9
> Code: 6d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 3b b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fb2e6be7cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
> RAX: fffffffffffffe00 RBX: 000000000073c048 RCX: 0000000000457ec9
> RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000073c048
> RBP: 000000000073c040 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000073c04c
> R13: 00007fffae482f5f R14: 00007fb2e6be89c0 R15: 000000000073c04c
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000ea7ffe057edb3156%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: KASAN: use-after-free Read in selinux_netlbl_socket_setsockopt
From: Dmitry Vyukov @ 2019-02-04 8:04 UTC (permalink / raw)
To: Cong Wang
Cc: Paul Moore, Ralf Baechle, David Miller, linux-hams, netdev,
syzbot, Eric Paris, LKML, Stephen Smalley, selinux,
syzkaller-bugs
In-Reply-To: <CAM_iQpV42EyuUFcxR7kn7WipkTAkvSxMc+-Me_QZCCUziy_wiQ@mail.gmail.com>
On Fri, Feb 1, 2019 at 6:58 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Thu, Jan 31, 2019 at 10:56 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > Hi Paul,
> >
> > Searching for af_netrom across other syzbot bugs:
> > https://groups.google.com/forum/#!searchin/syzkaller-bugs/af_netrom%7Csort:date
> >
> > I see at least:
> > https://syzkaller.appspot.com/bug?extid=b0b1952f5864b4009b09
> > https://syzkaller.appspot.com/bug?extid=febf3c50d4262e578b1c
> > https://syzkaller.appspot.com/bug?extid=defa700d16f1bd1b9a05
> >
> > Which suggests there are some serious lifetime problems in netrom
> > sockets. That would probably explain this crash as well.
>
> This is supposed to be fixed by:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=63346650c1a94a92be61a57416ac88c0a47c4327
>
> Please let me know if it isn't.
syzbot can tell if it's not fixed, but for that we need to mark these
bugs as fixed, otherwise syzbot will just consider any new crashes as
the same old bug so nothing to notify about.
#syz fix: netrom: switch to sock timer API
^ permalink raw reply
* Re: [PATCH iproute2-next] devlink: report cell size
From: Ido Schimmel @ 2019-02-04 7:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: jiri@resnulli.us, dsahern@gmail.com, stephen@networkplumber.org,
oss-drivers@netronome.com, netdev@vger.kernel.org
In-Reply-To: <20190204013919.816-1-jakub.kicinski@netronome.com>
On Sun, Feb 03, 2019 at 05:39:19PM -0800, Jakub Kicinski wrote:
> diff --git a/man/man8/devlink-sb.8 b/man/man8/devlink-sb.8
> index 1882833a3fa7..767c932dd4c1 100644
> --- a/man/man8/devlink-sb.8
> +++ b/man/man8/devlink-sb.8
> @@ -128,6 +128,16 @@ Behaviour of this argument it the same for every command.
> - specifies the devlink device to show pools.
> If this argument is omitted all pools of all devices are listed.
>
> +Display available pools listing their
> +.B type, size, thtype
> +and
> +.B cell_size. cell_size
> +is the allocation granularity of memory within the shared buffer. Drivers
> +may round up, round down or reject
> +.B size
> +passed to the set command if its not multiple of
s/its/it is/
> +.B cell_size.
> +
> .SS devlink sb pool set - set attributes of pool
>
> .PP
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH iproute2-next v2] devlink: add info subcommand
From: Jiri Pirko @ 2019-02-04 7:10 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: dsahern, stephen, netdev, oss-drivers
In-Reply-To: <20190204005456.22912-1-jakub.kicinski@netronome.com>
Mon, Feb 04, 2019 at 01:54:56AM CET, jakub.kicinski@netronome.com wrote:
>Add support for reading the device serial number, driver name
>and various versions. Example:
>
>$ devlink dev info pci/0000:05:00.0
>pci/0000:05:00.0:
> driver nfp
> serial_number 16240145
> versions:
> fixed:
> board.id AMDA0099-0001
> board.rev 07
> board.vendor SMA
> board.model carbon
> running:
> fw.mgmt: 010156.010156.010156
Sometimes you have "x: y" and sometimes you have "x y". Please be
consistent.
Please also include json output here.
Thanks!
> fw.cpld: 0x44
> fw.app: sriov-2.1.16
> stored:
> fw.mgmt: 010158.010158.010158
> fw.cpld: 0x44
> fw.app: sriov-2.1.20
>
>v2 (Jiri):
> - remove filtering;
> - add example in the commit message.
>RFCv2:
> - make info subcommand of dev.
>
[...]
^ permalink raw reply
* Re: [PATCH net-next v7 0/8] devlink: Add configuration parameters support for devlink_port
From: Vasundhara Volam @ 2019-02-04 6:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Michal Kubecek, Netdev, David Miller, michael.chan@broadcom.com,
Jiri Pirko
In-Reply-To: <20190122141842.26908b27@cakuba.netronome.com>
On Wed, Jan 23, 2019 at 3:48 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Fri, 18 Jan 2019 15:33:19 +0100, Michal Kubecek wrote:
> > On Fri, Jan 18, 2019 at 12:39:37PM +0530, Vasundhara Volam wrote:
> > > There is difference of opinion on adding WOL parameter to devlink, between
> > > Jakub Kicinski and Michael Chan.
> > >
> > > Quote from Jakud Kicinski:
> > > ********
> > > As explained previously I think it's a very bad idea to add existing
> > > configuration options to devlink, just because devlink has the ability
> > > to persist the setting in NVM. Especially that for WoL you have to get
> > > the link up so you potentially have all link config stuff as well. And
> > > that n-tuple filters are one of the WoL options, meaning we'd need the
> > > ability to persist n-tuple filters via devlink.
> > >
> > > The effort would be far better spent helping with migrating ethtool to
> > > netlink, and allowing persisting there.
> > >
> > > I have not heard any reason why devlink is a better fit. I can imagine
> > > you're just doing it here because it's less effort for you since
> > > ethtool is not yet migrated.
> > > ********
> > >
> > > Quote from Michael Chan:
> > > ********
> > > The devlink's WoL parameter is a persistent WoL parameter stored in the
> > > NIC's NVRAM. It is different from ethtool's WoL parameter in a number of
> > > ways. ethtool WoL is not persistent over AC power cycle and is considered
> > > OS-present WoL. As such, ethtool WoL can use a more sophisticated pattern
> > > including n-tuple with IP address in addition to the more basic types
> > > (e.g. magic packet). Whereas OS-absent power up WoL should only include
> > > magic packet and other simple types.
> >
> > If I understand correctly, it's that way now. I'm not sure there is a
> > technical reason preventing more complex WoL types in the OS-absent case
> > in the future. Also, even with traditional ethtool WoL setting, most
> > NICs only support some of the types (I'm not sure if there is a NIC
> > which would support all of them.)
> >
> > > The devlink WoL setting does not have to match the ethtool WoL
> > > setting.
> >
> > IMHO this is not really a problem. We can either use an additional flag
> > telling kernel/driver if we are setting runtime or persistent WoL mask
> > or we can pass (up to) two bitmaps.
Jakub, I will add another two bitmask parameters for WoL named as
wake_on_lan_runtime
and wake_on_lan_persistent. This will give information about what
types are runtime and
what types are persistent, does the device support for any given WoL types.
Does that sound good?
>
> I think reusing new netlink ethtool with a special flag would be a nice,
> complete solution. We could also address link settings this way (which
> are a pre-requisite for WoL).
>
> I have no strong preference on the mechanism, but for ease of setting
> as well as dumping would it be workable to use a nesting, like this:
>
> Run time settings:
> [ETHTOOL_SETTINGS_BLA]
> [ETHTOOL_BLA_VAL_1]
> [ETHTOOL_BLA_VAL_2]
> ...
>
> Persistent:
> [ETHTOOL_PERSISTENT]
> [ETHTOOL_SETTINGS_BLA]
> [ETHTOOL_BLA_VAL_1]
> [ETHTOOL_BLA_VAL_2]
>
> IOW encapsulate settings into a "persistent" attribute?
>
> How does that look to you, Michal?
>
> > > The card will autoneg up to the speed supported by Vaux so no special
> > > devlink link setting is needed.
> > > ********
> >
> > Like Jakub, I'm not convinced there is a strong technical reason to have
> > each of the WoL settings handled through a different interface. I don't
> > say, though, that ethtool is necessarily the right one. If there is
> > a consensus that it better fits into devlink, I can imagine that both
> > could be accessible through devlink (for start, in drivers which choose
> > so, e.g. because they want to implement the persistent setting).
> >
> > Michal Kubecek
^ 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