* Re: [PATCH net-next v2 1/1] net/mlx5: Fix code style issue in mlx driver
From: David Miller @ 2019-02-05 2:02 UTC (permalink / raw)
To: saeedm; +Cc: xiangxia.m.yue, netdev
In-Reply-To: <CALzJLG_uLE5c-yHYPGXV5Pp2w4nEYGBU9tzJwNMABNiC1V6HTg@mail.gmail.com>
From: Saeed Mahameed <saeedm@dev.mellanox.co.il>
Date: Mon, 4 Feb 2019 15:26:51 -0800
> On Thu, Jan 31, 2019 at 5:20 PM <xiangxia.m.yue@gmail.com> wrote:
>>
>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>>
>> Add the tab before '}' and keep the code style consistent.
>>
>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Dave, you can take this patch to net-next.
Great, applied.
^ permalink raw reply
* Re: [PATCH v2] net: dsa: mv88e6xxx: Revise irq setup ordering
From: Andrew Lunn @ 2019-02-05 2:21 UTC (permalink / raw)
To: John David Anglin; +Cc: Russell King, Vivien Didelot, Florian Fainelli, netdev
In-Reply-To: <8d8123cc-60f0-e236-e496-0aacf735fceb@bell.net>
> The problem is INTn can go low before the interrupt handler for it is
> registered and enabled.
> This can't happen. The domain is setup immediately after registering
> the GPIO interrupt.
> The interrupt can't fire until one of the enables is set.
These two statement seem to contradict each other?
> These are set
> by mv88e6xxx_g2_irq_setup(),
> mv88e6xxx_g1_atu_prob_irq_setup() and
> mv88e6xxx_g1_vtu_prob_irq_setup(). These irqs
> are setup after mv88e6xxx_g1_irq_setup()/mv88e6xxx_irq_poll_setup() is
> called. Thus, the
> irq domain is setup before the GPIO interrupt can fire.
At what point is INTn going low, causing you all these problems? I've
yet to see a real description of the race. Please give us a blow by
blow of how the race happens. And then explain how your fix actually
fixes this.
Also, i'm not yet convinced this hardware can actually work correctly
with edge interrupts. You can probably reduce the size of the race
window, but i don't think you can eliminate it. And if you cannot
eliminate it, at some point it is going to hit you.
Andrew
^ permalink raw reply
* Re: [PATCH v1] net: dsa: qca8k: implement DT-based ports <-> phy translation
From: Andrew Lunn @ 2019-02-05 2:45 UTC (permalink / raw)
To: Christian Lamparter; +Cc: netdev, Florian Fainelli, Vivien Didelot
In-Reply-To: <20190204213555.26054-1-chunkeey@gmail.com>
On Mon, Feb 04, 2019 at 10:35:55PM +0100, Christian Lamparter wrote:
> The QCA8337 enumerates 5 PHYs on the MDC/MDIO access: PHY0-PHY4.
> Based on the System Block Diagram in Section 1.2 of the
> QCA8337's datasheet. These PHYs are internally connected
> to MACs of PORT 1 - PORT 5. However, neither qca8k's slave
> mdio access functions qca8k_phy_read()/qca8k_phy_write()
> nor the dsa framework is set up for that.
>
> This version of the patch uses the existing phy-handle
> properties of each specified DSA Port in the DT to map
> each PORT/MAC to its exposed PHY on the MDIO bus. This
> is supported by the current binding document qca8k.txt
> as well.
Hi Christian
Looking at Documentation/devicetree/bindings/net/dsa/qca8k.txt
I think everything you need is already implemented. What problem do
you actually have?
Thanks
Andrew
^ permalink raw reply
* Re: Compiler warning - ipv4 fib_trie
From: David Ahern @ 2019-02-05 2:53 UTC (permalink / raw)
To: Koen Vandeputte, netdev
In-Reply-To: <ba46f918-243d-c106-6166-28caecdfd81d@ncentric.com>
On 2/4/19 3:55 AM, Koen Vandeputte wrote:
> 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
>
I believe that is a false positive. If you analyze the loop, local_tp is
set when local_l is NULL and it is set before the first use. I am
surprised the compiler can not track that. fib_find_node has 1 return
point and local_tp is set right before.
^ permalink raw reply
* Re: Compiler warning
From: David Ahern @ 2019-02-05 2:55 UTC (permalink / raw)
To: Koen Vandeputte, netdev
In-Reply-To: <60f98697-952d-aa39-765f-29736de0c4a2@ncentric.com>
On 2/4/19 3:43 AM, Koen Vandeputte wrote:
> 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
>
same with this one - false positive. head is initialized to NULL. tail
is set on the first pass through the loop.
What compiler / version is this?
^ permalink raw reply
* Re: [PATCH net-next v7 0/8] devlink: Add configuration parameters support for devlink_port
From: Jakub Kicinski @ 2019-02-05 2:56 UTC (permalink / raw)
To: Vasundhara Volam
Cc: Michal Kubecek, Netdev, David Miller, michael.chan@broadcom.com,
Jiri Pirko
In-Reply-To: <CAACQVJpVHLCeeE1KhJanYv_kDXzE=KX_OAPiCnFfjotf3K1+TA@mail.gmail.com>
On Mon, 4 Feb 2019 12:25:13 +0530, Vasundhara Volam wrote:
> > > 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?
No? We were talking about using the soon-too-come ethtool netlink
API with additional indication that given configuration request is
supposed to be persisted. Adding more devlink parameters is exactly
the opposite of what you should be doing.
^ permalink raw reply
* [PATCH] ipmr: ip6mr: Create new sockopt to clear mfc cache only
From: Callum Sinclair @ 2019-02-05 2:58 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel; +Cc: Callum Sinclair
In-Reply-To: <20190205025800.17185-1-callum.sinclair@alliedtelesis.co.nz>
Currently the only way to clear the mfc cache was to delete the entries
one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which will clear the multicast forwarding
cache on the socket without destroying the socket.
Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
---
include/uapi/linux/mroute.h | 3 ++-
include/uapi/linux/mroute6.h | 3 ++-
net/ipv4/ipmr.c | 40 +++++++++++++++++++++----------
net/ipv6/ip6mr.c | 46 +++++++++++++++++++++++-------------
4 files changed, 61 insertions(+), 31 deletions(-)
diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index 5d37a9ccce63..8a0beb885cd9 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -28,7 +28,8 @@
#define MRT_TABLE (MRT_BASE+9) /* Specify mroute table ID */
#define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT_MAX (MRT_BASE+11)
+#define MRT_DEL_MFC_ALL (MRT_BASE+12) /* Del all multicast entries */
+#define MRT_MAX (MRT_BASE+12)
#define SIOCGETVIFCNT SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index 9999cc006390..7def70cdf571 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -31,7 +31,8 @@
#define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID */
#define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT6_MAX (MRT6_BASE+11)
+#define MRT6_DEL_MFC_ALL (MRT6_BASE+12) /* Del all multicast entries */
+#define MRT6_MAX (MRT6_BASE+12)
#define SIOCGETMIFCNT_IN6 SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index ddbf8c9a1abb..ccfeebd38e1a 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1298,22 +1298,12 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
return 0;
}
-/* Close the multicast socket, and clear the vif tables etc */
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+/* Clear the vif tables */
+static void mroute_clean_cache(struct mr_table *mrt, bool all)
{
struct net *net = read_pnet(&mrt->net);
- struct mr_mfc *c, *tmp;
struct mfc_cache *cache;
- LIST_HEAD(list);
- int i;
-
- /* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- vif_delete(mrt, i, 0, &list);
- }
- unregister_netdevice_many(&list);
+ struct mr_mfc *c, *tmp;
/* Wipe the cache */
list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
@@ -1340,6 +1330,23 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
}
}
+/* Close the multicast socket, and clear the vif tables etc */
+static void mroute_clean_tables(struct mr_table *mrt, bool all)
+{
+ LIST_HEAD(list);
+ int i;
+
+ /* Shut down all active vif entries */
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
+ continue;
+ vif_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
+
+ mroute_clean_cache(mrt, all);
+}
+
/* called from ip_ra_control(), before an RCU grace period,
* we dont need to call synchronize_rcu() here
*/
@@ -1482,6 +1489,13 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
sk == rtnl_dereference(mrt->mroute_sk),
parent);
break;
+ case MRT_DEL_MFC_ALL:
+ rtnl_lock();
+ ipmr_for_each_table(mrt, net) {
+ mroute_clean_cache(mrt, true);
+ }
+ rtnl_unlock();
+ break;
/* Control PIM assert. */
case MRT_ASSERT:
if (optlen != sizeof(val)) {
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 30337b38274b..0168420d217b 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1492,25 +1492,11 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
return 0;
}
-/*
- * Close the multicast socket, and clear the vif tables etc
- */
-
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+/* Clear the vif tables */
+static void mroute_clean_cache(struct mr_table *mrt, bool all)
{
struct mr_mfc *c, *tmp;
- LIST_HEAD(list);
- int i;
-
- /* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- mif6_delete(mrt, i, 0, &list);
- }
- unregister_netdevice_many(&list);
- /* Wipe the cache */
list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
if (!all && (c->mfc_flags & MFC_STATIC))
continue;
@@ -1536,6 +1522,27 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
}
}
+/*
+ * Close the multicast socket, and clear the vif tables etc
+ */
+
+static void mroute_clean_tables(struct mr_table *mrt, bool all)
+{
+ LIST_HEAD(list);
+ int i;
+
+ /* Shut down all active vif entries */
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
+ continue;
+ mif6_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
+
+ /* Wipe the cache */
+ mroute_clean_cache(mrt, all);
+}
+
static int ip6mr_sk_init(struct mr_table *mrt, struct sock *sk)
{
int err = 0;
@@ -1703,6 +1710,13 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
parent);
rtnl_unlock();
return ret;
+ case MRT6_DEL_MFC_ALL:
+ rtnl_lock();
+ ip6mr_for_each_table(mrt, net) {
+ mroute_clean_cache(mrt, true);
+ }
+ rtnl_unlock();
+ return 0;
/*
* Control PIM assert (to activate pim will activate assert)
--
2.20.1
^ permalink raw reply related
* [PATCH] ipmr: ip6mr: Create new sockopt to clear mfc cache only
From: Callum Sinclair @ 2019-02-05 2:57 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel; +Cc: Callum Sinclair
Created a way to clear the multicast forwarding cache on a socket
without having to either remove the entries manually using the delete
entry socket option or destroy and recreate the multicast socket.
Patch Set 2:
- Fix Compile Errors
Patch Set 3:
- Fix Style Errors
Callum Sinclair (1):
ipmr: ip6mr: Create new sockopt to clear mfc cache only
include/uapi/linux/mroute.h | 3 ++-
include/uapi/linux/mroute6.h | 3 ++-
net/ipv4/ipmr.c | 40 +++++++++++++++++++++----------
net/ipv6/ip6mr.c | 46 +++++++++++++++++++++++-------------
4 files changed, 61 insertions(+), 31 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames
From: David Ahern @ 2019-02-05 3:13 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, mst, makita.toshiaki, jasowang, netdev,
virtualization, hawk, Toke Høiland-Jørgensen,
Jakub Kicinski, John Fastabend, Daniel Borkmann, Saeed Mahameed,
Tariq Toukan
In-Reply-To: <20190204125307.08492005@redhat.com>
On 2/4/19 3:53 AM, Jesper Dangaard Brouer wrote:
> 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.
mlx5 needs some work. As I recall it still has the bug/panic removing
xdp programs - at least I don't recall seeing a patch for it.
>
>
>> 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.
>
Understood. Hopefully in March I will get some time to come back to this
and propose an idea on what I would like to see - namely, the admin has
a config option at load time to enable driver counters versus custom map
counters. (meaning the operator of the node chooses standard stats over
strict performance.) But of course that means the drivers have the code
to collect those stats.
^ permalink raw reply
* Re: [PATCH] net: fix IPv6 prefix route residue
From: David Ahern @ 2019-02-05 3:21 UTC (permalink / raw)
To: David Miller, liuzhiqiang26
Cc: kuznet, yoshfuji, 0xeffeff, edumazet, netdev, mingfangsen,
zhangwenhao8, wangxiaogang3, zhoukang7
In-Reply-To: <20190203.090411.1685970814345088903.davem@redhat.com>
On 2/3/19 9:04 AM, David Miller wrote:
> From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
> Date: Sun, 3 Feb 2019 14:10:31 +0800
>
>> @@ -1165,7 +1165,8 @@ enum cleanup_prefix_rt_t {
>> list_for_each_entry(ifa, &idev->addr_list, if_list) {
>> if (ifa == ifp)
>> continue;
>> - if (!ipv6_prefix_equal(&ifa->addr, &ifp->addr,
>> + if (ifa->prefix_len != ifp->prefix_len ||
>> + !ipv6_prefix_equal(&ifa->addr, &ifp->addr,
>> ifp->prefix_len))
>
> Please fix the indentation of this conditional, it should be:
>
> if (ifa->prefix_len != ifp->prefix_len ||
> !ipv6_prefix_equal(&ifa->addr, &ifp->addr,
> ifp->prefix_len))
>
> Thank you.
>
Needs a Fixes tag too.
Fixes: 5b84efecb7d9 ("ipv6 addrconf: don't cleanup prefix route for
IFA_F_NOPREFIXROUTE")
and cc to that author Thomas Haller <thaller@redhat.com>
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: fix libbpf_print
From: Yonghong Song @ 2019-02-05 3:23 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Stanislav Fomichev, netdev@vger.kernel.org, davem@davemloft.net,
ast@kernel.org, daniel@iogearbox.net
In-Reply-To: <20190205015133.cv23h2hkz6pym4dw@ast-mbp.dhcp.thefacebook.com>
On 2/4/19 5:51 PM, Alexei Starovoitov wrote:
> On Tue, Feb 05, 2019 at 12:37:29AM +0000, Yonghong Song wrote:
>>
>>
>> On 2/4/19 4:20 PM, Stanislav Fomichev wrote:
>>> With the recent print rework we now have the following problem:
>>> pr_{warning,info,debug} expand to __pr which calls libbpf_print.
>>> libbpf_print does va_start and calls __libbpf_pr with va_list argument.
>>> In __base_pr we again do va_start. Because the next argument is a
>>> va_list, we don't get correct pointer to the argument (and print noting
>>> in my case, I don't know why it doesn't crash tbh).
>>>
>>> Fix this by changing libbpf_print_fn_t signature to accept va_list and
>>> remove unneeded calls to va_start in the existing users.
>>>
>>> Alternatively, this can we solved by exporting __libbpf_pr and
>>> changing __pr macro to (and killing libbpf_print):
>>> {
>>> if (__libbpf_pr)
>>> __libbpf_pr(level, "libbpf: " fmt, ##__VA_ARGS__)
>>> }
>>>
>>> Signed-off-by: Stanislav Fomichev <sdf@google.com>
>>
>> It is my mistake. My early version did passed correctly and later
>> on I made some changes and did not test properly. Thanks for the fix!
>>
>> Acked-by: Yonghong Song <yhs@fb.com>
>
> argh.
> Applied. Thanks for the fix.
> Yonghong, how was the earlier patch set tested?
Before the global function patch set, I have a global variable version,
which I tested and worked. Later on when changing to global
libbpf_print approach, I tested it through test_btf. That is why
I found a missing check for LIBBPF_DEBUG level in default __base_pr.
But I have to admit that I probably did not pay attention to contents
somehow so I missed the garbled output.
> It sounds that nothing should have worked.
> How perf changes were tested?
I only tested compilation. The context is similar to a few other
bpf selftests programs and I assume with similar implementation, the
result should be similar. But really badly, they are all incorrect :-(
^ permalink raw reply
* RE: [PATCH v2 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2019-02-05 3:52 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org
In-Reply-To: <201902042228.ePAd4m5Y%fengguang.wu@intel.com>
Hi Andrew,
I am getting this compilation error when the mdio-mux-regmap.ko is built as standalone module.
This error doesn't come when the mdio-mux-regmap is built as part of linux kernel.
I don't understand the reason for it. Inline definitions of functions are only defined if CONFIG_MDIO_BUS_MUX_REGMAP
Is NOT defined.
BUT it is defined as " CONFIG_MDIO_BUS_MUX_REGMAP = m"
Can you please help me to solve this?
Regards,
Pankaj Bansal
> -----Original Message-----
> From: kbuild test robot [mailto:lkp@intel.com]
> Sent: Monday, 4 February, 2019 08:22 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: kbuild-all@01.org; Andrew Lunn <andrew@lunn.ch>; Florian Fainelli
> <f.fainelli@gmail.com>; netdev@vger.kernel.org; Pankaj Bansal
> <pankaj.bansal@nxp.com>
> Subject: Re: [PATCH v2 2/2] netdev/phy: add MDIO bus multiplexer driven by a
> regmap
>
> Hi Pankaj,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on net/master]
> [also build test ERROR on v5.0-rc4]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system]
>
> url:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2F0day-ci%2Flinux%2Fcommits%2FPankaj-Bansal%2Fadd-MDIO-bus-
> multiplexer-driven-by-a-regmap-device%2F20190204-
> 213429&data=02%7C01%7Cpankaj.bansal%40nxp.com%7Caabb2bdecd8a4
> 2c19f8108d68ab053d6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C636848890628820621&sdata=WLP4yuLXqfoNLfrPSIWhNkfg24YdR6Ny8jb
> cUgvcrDQ%3D&reserved=0
> config: sh-allmodconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> reproduce:
> wget
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.git
> hubusercontent.com%2Fintel%2Flkp-
> tests%2Fmaster%2Fsbin%2Fmake.cross&data=02%7C01%7Cpankaj.bansal
> %40nxp.com%7Caabb2bdecd8a42c19f8108d68ab053d6%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C636848890628820621&sdata=pGqb5xq
> RsWH6fXd8NWLUKX86qQ0ZO8OOy8nj9rckqV8%3D&reserved=0 -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=8.2.0 make.cross ARCH=sh
>
> All errors (new ones prefixed by >>):
>
> >> drivers/net/phy/mdio-mux-regmap.c:72:5: error: redefinition of
> 'mdio_mux_regmap_init'
> int mdio_mux_regmap_init(struct device *dev,
> ^~~~~~~~~~~~~~~~~~~~
> In file included from drivers/net/phy/mdio-mux-regmap.c:18:
> include/linux/mdio-mux.h:53:19: note: previous definition of
> 'mdio_mux_regmap_init' was here
> static inline int mdio_mux_regmap_init(struct device *dev,
> ^~~~~~~~~~~~~~~~~~~~
> >> drivers/net/phy/mdio-mux-regmap.c:158:5: error: redefinition of
> 'mdio_mux_regmap_uninit'
> int mdio_mux_regmap_uninit(void *data)
> ^~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/net/phy/mdio-mux-regmap.c:18:
> include/linux/mdio-mux.h:60:19: note: previous definition of
> 'mdio_mux_regmap_uninit' was here
> static inline int mdio_mux_regmap_uninit(void *data)
> ^~~~~~~~~~~~~~~~~~~~~~
>
> vim +/mdio_mux_regmap_init +72 drivers/net/phy/mdio-mux-regmap.c
>
> 62
> 63 /**
> 64 * mdio_mux_regmap_init - control MDIO bus muxing using regmap
> constructs.
> 65 * @dev: device with which regmap construct is associated.
> 66 * @mux_node: mdio bus mux node that contains parent mdio bus
> phandle.
> 67 * This node also contains sub nodes, where each subnode
> denotes
> 68 * a child mdio bus. All the child mdio buses are muxed, i.e. at a
> 69 * time only one of the child mdio buses can be used.
> 70 * @data: to store the address of data allocated by this function
> 71 */
> > 72 int mdio_mux_regmap_init(struct device *dev,
> 73 struct device_node *mux_node,
> 74 void **data)
> 75 {
> 76 struct device_node *child;
> 77 struct mdio_mux_regmap_state *s;
> 78 int ret;
> 79 u32 val;
> 80
> 81 dev_dbg(dev, "probing node %pOF\n", mux_node);
> 82
> 83 s = devm_kzalloc(dev, sizeof(*s), GFP_KERNEL);
> 84 if (!s)
> 85 return -ENOMEM;
> 86
> 87 s->regmap = dev_get_regmap(dev, NULL);
> 88 if (IS_ERR(s->regmap)) {
> 89 dev_err(dev, "Failed to get parent regmap\n");
> 90 return PTR_ERR(s->regmap);
> 91 }
> 92
> 93 ret = of_property_read_u32(mux_node, "reg", &s->mux_reg);
> 94 if (ret) {
> 95 dev_err(dev, "missing or invalid reg property\n");
> 96 return -ENODEV;
> 97 }
> 98
> 99 /* Test Register read write */
> 100 ret = regmap_read(s->regmap, s->mux_reg, &val);
> 101 if (ret) {
> 102 dev_err(dev, "error while reading reg\n");
> 103 return ret;
> 104 }
> 105
> 106 ret = regmap_write(s->regmap, s->mux_reg, val);
> 107 if (ret) {
> 108 dev_err(dev, "error while writing reg\n");
> 109 return ret;
> 110 }
> 111
> 112 ret = of_property_read_u32(mux_node, "mux-mask", &s-
> >mask);
> 113 if (ret) {
> 114 dev_err(dev, "missing or invalid mux-mask property\n");
> 115 return -ENODEV;
> 116 }
> 117
> 118 /* Verify that the 'reg' property of each child MDIO bus does
> not
> 119 * set any bits outside of the 'mask'.
> 120 */
> 121 for_each_available_child_of_node(mux_node, child) {
> 122 ret = of_property_read_u32(child, "reg", &val);
> 123 if (ret) {
> 124 dev_err(dev, "%pOF is missing a 'reg'
> property\n",
> 125 child);
> 126 of_node_put(child);
> 127 return -ENODEV;
> 128 }
> 129 if (val & ~s->mask) {
> 130 dev_err(dev,
> 131 "%pOF has a 'reg' value with unmasked
> bits\n",
> 132 child);
> 133 of_node_put(child);
> 134 return -ENODEV;
> 135 }
> 136 }
> 137
> 138 ret = mdio_mux_init(dev, mux_node,
> mdio_mux_regmap_switch_fn,
> 139 &s->mux_handle, s, NULL);
> 140 if (ret) {
> 141 if (ret != -EPROBE_DEFER)
> 142 dev_err(dev, "failed to register mdio-mux
> bus %pOF\n",
> 143 mux_node);
> 144 return ret;
> 145 }
> 146
> 147 *data = s;
> 148
> 149 return 0;
> 150 }
> 151 EXPORT_SYMBOL_GPL(mdio_mux_regmap_init);
> 152
> 153 /**
> 154 * mdio_mux_regmap_uninit - relinquish the control of MDIO bus
> muxing using
> 155 * regmap constructs.
> 156 * @data: address of data allocated by mdio_mux_regmap_init
> 157 */
> > 158 int mdio_mux_regmap_uninit(void *data)
> 159 {
> 160 struct mdio_mux_regmap_state *s = data;
> 161
> 162 mdio_mux_uninit(s->mux_handle);
> 163
> 164 return 0;
> 165 }
> 166 EXPORT_SYMBOL_GPL(mdio_mux_regmap_uninit);
> 167
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fpipermail%2Fkbuild-
> all&data=02%7C01%7Cpankaj.bansal%40nxp.com%7Caabb2bdecd8a42c19
> f8108d68ab053d6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 848890628820621&sdata=P7RrlnHYStMpoDpwIDMmlRiDTCemyEE3bxuUrq
> d0uxY%3D&reserved=0 Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v7 0/8] devlink: Add configuration parameters support for devlink_port
From: Vasundhara Volam @ 2019-02-05 4:23 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Michal Kubecek, Netdev, David Miller, michael.chan@broadcom.com,
Jiri Pirko
In-Reply-To: <20190204185626.3c7a162b@cakuba.netronome.com>
On Tue, Feb 5, 2019 at 8:26 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Mon, 4 Feb 2019 12:25:13 +0530, Vasundhara Volam wrote:
> > > > 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?
>
> No? We were talking about using the soon-too-come ethtool netlink
> API with additional indication that given configuration request is
> supposed to be persisted. Adding more devlink parameters is exactly
> the opposite of what you should be doing.
Okay. So, till then can we have the devlink wake_on_lan parameter or
you want this to be removed? Could you please clarify?
Once ethtool netlink API is available with persisted support, I can remove
this wake_on_lan parameter from devlink. Thanks.
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the net tree
From: Stephen Rothwell @ 2019-02-05 5:25 UTC (permalink / raw)
To: Andrew Morton, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Kent Overstreet, Xin Long
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
net/sctp/stream.c
between commit:
cfe4bd7a257f ("sctp: check and update stream->out_curr when allocating stream_out")
from the net tree and commit:
2bd3fbb3ff23 ("sctp: convert to genradix")
from the akpm-current tree.
I fixed it up (the latter removed the code modified by the former, so I
did that) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Is advertising of 2500Mbps support must from phy device to set phy at 2500Mbps link speed
From: abhijit @ 2019-02-05 6:09 UTC (permalink / raw)
To: netdev
Hi All,
We are using Ethernet MAC which has integrated Phy. This phy supports
speed up to 10000Mbps. The phy has, 1000Base-X PCS(Physical Coding
Sub-layer) followed by SerDes interface to support 10Mbps to 10000Mbps.
Currently we are trying to get this phy at 2500Mbps. This device has 16
registers that corresponds to Clause 37, which can be used to advertise
speed till 1000Mbps.
So my question is,
1. Without phy advertising its capability of 2500Mbps, is there any way
I can set phy speed at 2500Mbps?
2. I tried disabling auto-negotiation and setting speed at 2500Mbps with
ethtool (ethtool -s eth0 speed 2500 autoneg off), but the ethtool
reported this configuration as invalid?
3. At the end we are targeting print of "link up (2500/Full)"
Regards,
Abhijit
^ permalink raw reply
* Re: [PATCH mlx5-next 12/12] net/mlx5: Set ODP SRQ support in firmware
From: Leon Romanovsky @ 2019-02-05 6:27 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Jason Gunthorpe, dledford@redhat.com, Majd Dibbiny, Moni Shoua,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <19e67f214aca4424e0e373d782c4c7e6bc25dcef.camel@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Mon, Feb 04, 2019 at 11:47:23PM +0000, Saeed Mahameed wrote:
> On Tue, 2019-01-22 at 08:48 +0200, Leon Romanovsky wrote:
> > From: Moni Shoua <monis@mellanox.com>
> >
> > To avoid compatibility issue with older kernels the firmware doesn't
> > allow SRQ to work with ODP unless kernel asks for it.
> >
> > Signed-off-by: Moni Shoua <monis@mellanox.com>
> > Reviewed-by: Majd Dibbiny <majd@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > .../net/ethernet/mellanox/mlx5/core/main.c | 53
> > +++++++++++++++++++
> > include/linux/mlx5/device.h | 3 ++
> > include/linux/mlx5/mlx5_ifc.h | 1 +
> > 3 files changed, 57 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > index be81b319b0dc..b3a76df0cf6c 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > @@ -459,6 +459,53 @@ static int handle_hca_cap_atomic(struct
> > mlx5_core_dev *dev)
> > return err;
> > }
> >
> > +static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
> > +{
> > + void *set_ctx;
> > + void *set_hca_cap;
> > + int set_sz = MLX5_ST_SZ_BYTES(set_hca_cap_in);
> > + int err;
> > +
>
> reversed xmas tree.
I'll send followup to address your comments.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/7] sh_eth: implement simple RX checksum offload
From: Sergei Shtylyov @ 2019-02-05 8:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-renesas-soc, linux-sh
In-Reply-To: <20190204.133136.1764517040498341680.davem@davemloft.net>
On 05.02.2019 0:31, David Miller wrote:
>> Here's a set of 7 patches against DaveM's 'net-next.git' repo. I'm implemeting
>> the simple RX checksum offload (like was done for the 'ravb' driver by Simon
>> Horman); it has been only tested on the R8A7740 and R8A77980 SoCs, the other
>> SoCs should just work (according to their manuals)...
>
> Series applied, thanks.
>
> There was a "tha" --> "the" typo in one of your commit messages which I
> fixed up.
Indeed! Thank you. :-)
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net v5 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: Or Gerlitz @ 2019-02-05 9:03 UTC (permalink / raw)
To: davem@davemloft.net
Cc: xiangxia.m.yue@gmail.com, netdev@vger.kernel.org, Hadar Hen Zion,
Saeed Mahameed
In-Reply-To: <6170db12d80e727169dca2d00a0226b91f8f87f0.camel@mellanox.com>
On Wed, Jan 30, 2019 at 12:20 AM Saeed Mahameed <saeedm@mellanox.com> wrote:
>
> On Mon, 2019-01-28 at 15:28 -0800, xiangxia.m.yue@gmail.com wrote:
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > When we offload tc filters to hardware, hardware flows can
> > be updated when mac of encap destination ip is changed.
> > But we ignore one case, that the mac of local encap ip can
> > be changed too, so we should also update them.
> >
> > To fix it, add route_dev in mlx5e_encap_entry struct to save
> > the local encap netdevice, and when mac changed, kernel will
> > flush all the neighbour on the netdevice and send
> > NETEVENT_NEIGH_UPDATE
> > event. The mlx5 driver will delete the flows and add them when
> > neighbour
> > available again.
> >
> > Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update
> > flow")
> > Cc: Hadar Hen Zion <hadarh@mellanox.com>
> > Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
> >
> >
>
> Thank you Tonghao and Or.
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Dave, I see a copy of the patch on patchworks [1] with status being
not applicable, what is missing here? the patch should apply AFAIK.
There was also another patch reviewed here by me and Saeed [2], not
sure where it stands from your side.
[1] https://patchwork.ozlabs.org/patch/1023844/
[2] https://marc.info/?l=linux-netdev&m=154878514916414&w=2
^ permalink raw reply
* Re: [PATCH net-next 1/4] dpaa2-eth: Use a single page per Rx buffer
From: Ilias Apalodimas @ 2019-02-05 9:35 UTC (permalink / raw)
To: Ioana Ciocoi Radulescu
Cc: netdev@vger.kernel.org, davem@davemloft.net, Ioana Ciornei,
brouer@redhat.com
In-Reply-To: <1549299625-28399-2-git-send-email-ruxandra.radulescu@nxp.com>
Hi Ioana,
Can you share any results on XDP (XDP_DROP is usually useful for the hardware
capabilities).
> Instead of allocating page fragments via the network stack,
> use the page allocator directly. For now, we consume one page
> for each Rx buffer.
>
> With the new memory model we are free to consider adding more
> XDP support.
>
> Performance decreases slightly in some IP forwarding cases.
> No visible effect on termination traffic. The driver memory
> footprint increases as a result of this change, but it is
> still small enough to not really matter.
>
> Another side effect is that now Rx buffer alignment requirements
> are naturally satisfied without any additional actions needed.
> Remove alignment related code, except in the buffer layout
> information conveyed to MC, as hardware still needs to know the
> alignment value we guarantee.
>
> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
> ---
> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 61 +++++++++++++-----------
> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h | 21 +++-----
> 2 files changed, 38 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> index 04925c7..6e58de6 100644
> --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
> @@ -86,16 +86,16 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv,
> for (i = 1; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) {
> addr = dpaa2_sg_get_addr(&sgt[i]);
> sg_vaddr = dpaa2_iova_to_virt(priv->iommu_domain, addr);
> - dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
> - DMA_BIDIRECTIONAL);
> + dma_unmap_page(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
> + DMA_BIDIRECTIONAL);
>
> - skb_free_frag(sg_vaddr);
> + free_pages((unsigned long)sg_vaddr, 0);
> if (dpaa2_sg_is_final(&sgt[i]))
> break;
> }
>
> free_buf:
> - skb_free_frag(vaddr);
> + free_pages((unsigned long)vaddr, 0);
> }
>
> /* Build a linear skb based on a single-buffer frame descriptor */
> @@ -109,7 +109,7 @@ static struct sk_buff *build_linear_skb(struct dpaa2_eth_channel *ch,
>
> ch->buf_count--;
>
> - skb = build_skb(fd_vaddr, DPAA2_ETH_SKB_SIZE);
> + skb = build_skb(fd_vaddr, DPAA2_ETH_RX_BUF_RAW_SIZE);
> if (unlikely(!skb))
> return NULL;
>
> @@ -144,19 +144,19 @@ static struct sk_buff *build_frag_skb(struct dpaa2_eth_priv *priv,
> /* Get the address and length from the S/G entry */
> sg_addr = dpaa2_sg_get_addr(sge);
> sg_vaddr = dpaa2_iova_to_virt(priv->iommu_domain, sg_addr);
> - dma_unmap_single(dev, sg_addr, DPAA2_ETH_RX_BUF_SIZE,
> - DMA_BIDIRECTIONAL);
> + dma_unmap_page(dev, sg_addr, DPAA2_ETH_RX_BUF_SIZE,
> + DMA_BIDIRECTIONAL);
>
> sg_length = dpaa2_sg_get_len(sge);
>
> if (i == 0) {
> /* We build the skb around the first data buffer */
> - skb = build_skb(sg_vaddr, DPAA2_ETH_SKB_SIZE);
> + skb = build_skb(sg_vaddr, DPAA2_ETH_RX_BUF_RAW_SIZE);
> if (unlikely(!skb)) {
> /* Free the first SG entry now, since we already
> * unmapped it and obtained the virtual address
> */
> - skb_free_frag(sg_vaddr);
> + free_pages((unsigned long)sg_vaddr, 0);
>
> /* We still need to subtract the buffers used
> * by this FD from our software counter
> @@ -211,9 +211,9 @@ static void free_bufs(struct dpaa2_eth_priv *priv, u64 *buf_array, int count)
>
> for (i = 0; i < count; i++) {
> vaddr = dpaa2_iova_to_virt(priv->iommu_domain, buf_array[i]);
> - dma_unmap_single(dev, buf_array[i], DPAA2_ETH_RX_BUF_SIZE,
> - DMA_BIDIRECTIONAL);
> - skb_free_frag(vaddr);
> + dma_unmap_page(dev, buf_array[i], DPAA2_ETH_RX_BUF_SIZE,
> + DMA_BIDIRECTIONAL);
> + free_pages((unsigned long)vaddr, 0);
I got some hardware/XDP related questions since i have no idea how the hardware
works. From what i understand on the code, you are trying to manage the buffer
from the hw buffer manager and if the fails you unmap and free the pages.
Since XDP relies on recycling for speed (hint check xdp_return_buff()), is it
possible to recycle the buffer if the hw fails ?
> }
> }
>
> @@ -378,16 +378,16 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
> return;
> }
>
> - dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
> - DMA_BIDIRECTIONAL);
> + dma_unmap_page(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
> + DMA_BIDIRECTIONAL);
> skb = build_linear_skb(ch, fd, vaddr);
> } else if (fd_format == dpaa2_fd_sg) {
> WARN_ON(priv->xdp_prog);
>
> - dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
> - DMA_BIDIRECTIONAL);
> + dma_unmap_page(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
> + DMA_BIDIRECTIONAL);
> skb = build_frag_skb(priv, ch, buf_data);
> - skb_free_frag(vaddr);
> + free_pages((unsigned long)vaddr, 0);
> percpu_extras->rx_sg_frames++;
> percpu_extras->rx_sg_bytes += dpaa2_fd_get_len(fd);
> } else {
> @@ -903,7 +903,7 @@ static int add_bufs(struct dpaa2_eth_priv *priv,
> {
> struct device *dev = priv->net_dev->dev.parent;
> u64 buf_array[DPAA2_ETH_BUFS_PER_CMD];
> - void *buf;
> + struct page *page;
> dma_addr_t addr;
> int i, err;
>
> @@ -911,14 +911,16 @@ static int add_bufs(struct dpaa2_eth_priv *priv,
> /* Allocate buffer visible to WRIOP + skb shared info +
> * alignment padding
> */
> - buf = napi_alloc_frag(dpaa2_eth_buf_raw_size(priv));
> - if (unlikely(!buf))
> + /* allocate one page for each Rx buffer. WRIOP sees
> + * the entire page except for a tailroom reserved for
> + * skb shared info
> + */
> + page = dev_alloc_pages(0);
> + if (!page)
> goto err_alloc;
>
> - buf = PTR_ALIGN(buf, priv->rx_buf_align);
> -
> - addr = dma_map_single(dev, buf, DPAA2_ETH_RX_BUF_SIZE,
> - DMA_BIDIRECTIONAL);
> + addr = dma_map_page(dev, page, 0, DPAA2_ETH_RX_BUF_SIZE,
> + DMA_BIDIRECTIONAL);
> if (unlikely(dma_mapping_error(dev, addr)))
> goto err_map;
>
> @@ -926,7 +928,7 @@ static int add_bufs(struct dpaa2_eth_priv *priv,
>
> /* tracing point */
> trace_dpaa2_eth_buf_seed(priv->net_dev,
> - buf, dpaa2_eth_buf_raw_size(priv),
> + page, DPAA2_ETH_RX_BUF_RAW_SIZE,
> addr, DPAA2_ETH_RX_BUF_SIZE,
> bpid);
> }
> @@ -948,7 +950,7 @@ static int add_bufs(struct dpaa2_eth_priv *priv,
> return i;
>
> err_map:
> - skb_free_frag(buf);
> + __free_pages(page, 0);
> err_alloc:
> /* If we managed to allocate at least some buffers,
> * release them to hardware
> @@ -2134,6 +2136,7 @@ static int set_buffer_layout(struct dpaa2_eth_priv *priv)
> {
> struct device *dev = priv->net_dev->dev.parent;
> struct dpni_buffer_layout buf_layout = {0};
> + u16 rx_buf_align;
> int err;
>
> /* We need to check for WRIOP version 1.0.0, but depending on the MC
> @@ -2142,9 +2145,9 @@ static int set_buffer_layout(struct dpaa2_eth_priv *priv)
> */
> if (priv->dpni_attrs.wriop_version == DPAA2_WRIOP_VERSION(0, 0, 0) ||
> priv->dpni_attrs.wriop_version == DPAA2_WRIOP_VERSION(1, 0, 0))
> - priv->rx_buf_align = DPAA2_ETH_RX_BUF_ALIGN_REV1;
> + rx_buf_align = DPAA2_ETH_RX_BUF_ALIGN_REV1;
> else
> - priv->rx_buf_align = DPAA2_ETH_RX_BUF_ALIGN;
> + rx_buf_align = DPAA2_ETH_RX_BUF_ALIGN;
>
> /* tx buffer */
> buf_layout.private_data_size = DPAA2_ETH_SWA_SIZE;
> @@ -2184,7 +2187,7 @@ static int set_buffer_layout(struct dpaa2_eth_priv *priv)
> /* rx buffer */
> buf_layout.pass_frame_status = true;
> buf_layout.pass_parser_result = true;
> - buf_layout.data_align = priv->rx_buf_align;
> + buf_layout.data_align = rx_buf_align;
> buf_layout.data_head_room = dpaa2_eth_rx_head_room(priv);
> buf_layout.private_data_size = 0;
> buf_layout.options = DPNI_BUF_LAYOUT_OPT_PARSER_RESULT |
> diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> index 31fe486..da3d039 100644
> --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
> @@ -63,9 +63,11 @@
> /* Hardware requires alignment for ingress/egress buffer addresses */
> #define DPAA2_ETH_TX_BUF_ALIGN 64
>
> -#define DPAA2_ETH_RX_BUF_SIZE 2048
> -#define DPAA2_ETH_SKB_SIZE \
> - (DPAA2_ETH_RX_BUF_SIZE + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
> +#define DPAA2_ETH_RX_BUF_RAW_SIZE PAGE_SIZE
> +#define DPAA2_ETH_RX_BUF_TAILROOM \
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
> +#define DPAA2_ETH_RX_BUF_SIZE \
> + (DPAA2_ETH_RX_BUF_RAW_SIZE - DPAA2_ETH_RX_BUF_TAILROOM)
>
> /* Hardware annotation area in RX/TX buffers */
> #define DPAA2_ETH_RX_HWA_SIZE 64
> @@ -343,7 +345,6 @@ struct dpaa2_eth_priv {
> bool rx_tstamp; /* Rx timestamping enabled */
>
> u16 tx_qdid;
> - u16 rx_buf_align;
> struct fsl_mc_io *mc_io;
> /* Cores which have an affine DPIO/DPCON.
> * This is the cpu set on which Rx and Tx conf frames are processed
> @@ -418,15 +419,6 @@ enum dpaa2_eth_rx_dist {
> DPAA2_ETH_RX_DIST_CLS
> };
>
> -/* Hardware only sees DPAA2_ETH_RX_BUF_SIZE, but the skb built around
> - * the buffer also needs space for its shared info struct, and we need
> - * to allocate enough to accommodate hardware alignment restrictions
> - */
> -static inline unsigned int dpaa2_eth_buf_raw_size(struct dpaa2_eth_priv *priv)
> -{
> - return DPAA2_ETH_SKB_SIZE + priv->rx_buf_align;
> -}
> -
> static inline
> unsigned int dpaa2_eth_needed_headroom(struct dpaa2_eth_priv *priv,
> struct sk_buff *skb)
> @@ -451,8 +443,7 @@ unsigned int dpaa2_eth_needed_headroom(struct dpaa2_eth_priv *priv,
> */
> static inline unsigned int dpaa2_eth_rx_head_room(struct dpaa2_eth_priv *priv)
> {
> - return priv->tx_data_offset + DPAA2_ETH_TX_BUF_ALIGN -
> - DPAA2_ETH_RX_HWA_SIZE;
> + return priv->tx_data_offset - DPAA2_ETH_RX_HWA_SIZE;
> }
>
> int dpaa2_eth_set_hash(struct net_device *net_dev, u64 flags);
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net-next v3 04/16] net: sched: traverse chains in block with tcf_get_next_chain()
From: Jiri Pirko @ 2019-02-05 9:35 UTC (permalink / raw)
To: Vlad Buslov; +Cc: netdev, jhs, xiyou.wangcong, davem, ast, daniel
In-Reply-To: <20190204123301.4223-5-vladbu@mellanox.com>
Mon, Feb 04, 2019 at 01:32:49PM CET, vladbu@mellanox.com wrote:
>All users of block->chain_list rely on rtnl lock and assume that no new
>chains are added when traversing the list. Use tcf_get_next_chain() to
>traverse chain list without relying on rtnl mutex. This function iterates
>over chains by taking reference to current iterator chain only and doesn't
>assume external synchronization of chain list.
>
>Don't take reference to all chains in block when flushing and use
>tcf_get_next_chain() to safely iterate over chain list instead. Remove
>tcf_block_put_all_chains() that is no longer used.
>
>Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v3 05/16] net: sched: protect chain template accesses with block lock
From: Jiri Pirko @ 2019-02-05 9:42 UTC (permalink / raw)
To: Vlad Buslov; +Cc: netdev, jhs, xiyou.wangcong, davem, ast, daniel
In-Reply-To: <20190204123301.4223-6-vladbu@mellanox.com>
Mon, Feb 04, 2019 at 01:32:50PM CET, vladbu@mellanox.com wrote:
>When cls API is called without protection of rtnl lock, parallel
>modification of chain is possible, which means that chain template can be
>changed concurrently in certain circumstances. For example, when chain is
>'deleted' by new user-space chain API, the chain might continue to be used
>if it is referenced by actions, and can be 're-created' again by user. In
>such case same chain structure is reused and its template is changed. To
>protect from described scenario, cache chain template while holding block
>lock. Introduce standalone tc_chain_notify_delete() function that works
>with cached template values, instead of chains themselves.
>
>Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: net: add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2019-02-05 10:05 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org, Pankaj Bansal
In-Reply-To: <20190205153014.3807-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:
V3:
- No change
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 v3 0/2] add MDIO bus multiplexer driven by a regmap device
From: Pankaj Bansal @ 2019-02-05 10:05 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:
V2:
- https://www.mail-archive.com/netdev@vger.kernel.org/msg282176.html
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 | 169 ++++++++++++++++++
include/linux/mdio-mux.h | 34 ++++
5 files changed, 385 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 v3 2/2] netdev/phy: add MDIO bus multiplexer driven by a regmap
From: Pankaj Bansal @ 2019-02-05 10:05 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev@vger.kernel.org, Pankaj Bansal
In-Reply-To: <20190205153014.3807-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:
V3:
- make the return type of uninit function to void
- reorder the Make file change to be alphabetically sorted
- fix the compilation error when mdio-mux-regmap is built as module
by adding CONFIG_MDIO_BUS_MUX_REGMAP_MODULE macro in mdio-mux.h
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 | 169 ++++++++++++++++++++++++++++
include/linux/mdio-mux.h | 34 ++++++
4 files changed, 218 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..99737128de8a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.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
+obj-$(CONFIG_MDIO_BUS_MUX_REGMAP) += mdio-mux-regmap.o
obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.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..bbec43b30f3c
--- /dev/null
+++ b/drivers/net/phy/mdio-mux-regmap.c
@@ -0,0 +1,169 @@
+// 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
+ */
+void mdio_mux_regmap_uninit(void *data)
+{
+ struct mdio_mux_regmap_state *s = data;
+
+ mdio_mux_uninit(s->mux_handle);
+}
+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..bb5d0e2774bf 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);
+#if defined(CONFIG_MDIO_BUS_MUX_REGMAP) || \
+ defined(CONFIG_MDIO_BUS_MUX_REGMAP_MODULE)
+/**
+ * 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
+ */
+void mdio_mux_regmap_uninit(void *data);
+#else /* CONFIG_MDIO_BUS_MUX_REGMAP(_MODULE) */
+static inline int mdio_mux_regmap_init(struct device *dev,
+ struct device_node *mux_node,
+ void **data)
+{
+ return -ENODEV;
+}
+
+static inline void mdio_mux_regmap_uninit(void *data)
+{
+}
+#endif /* CONFIG_MDIO_BUS_MUX_REGMAP(_MODULE) */
+
#endif /* __LINUX_MDIO_MUX_H */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v3 06/16] net: sched: protect filter_chain list with filter_chain_lock mutex
From: Jiri Pirko @ 2019-02-05 10:04 UTC (permalink / raw)
To: Vlad Buslov; +Cc: netdev, jhs, xiyou.wangcong, davem, ast, daniel
In-Reply-To: <20190204123301.4223-7-vladbu@mellanox.com>
Mon, Feb 04, 2019 at 01:32:51PM CET, vladbu@mellanox.com wrote:
>Extend tcf_chain with new filter_chain_lock mutex. Always lock the chain
>when accessing filter_chain list, instead of relying on rtnl lock.
>Dereference filter_chain with tcf_chain_dereference() lockdep macro to
>verify that all users of chain_list have the lock taken.
>
>Rearrange tp insert/remove code in tc_new_tfilter/tc_del_tfilter to execute
>all necessary code while holding chain lock in order to prevent
>invalidation of chain_info structure by potential concurrent change. This
>also serializes calls to tcf_chain0_head_change(), which allows head change
>callbacks to rely on filter_chain_lock for synchronization instead of rtnl
>mutex.
>
>Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox