* [PATCH] net:9p: change the p9_error_init and p9_trans_fd_init to be void function
From: zhong jiang @ 2018-08-08 14:02 UTC (permalink / raw)
To: ericvh, rminnich, lucho, davem; +Cc: netdev, linux-kernel
The two functions has return value, but any of the callees do not handle the
return value. So we get out of the return value and make the function to be
void function.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
include/net/9p/9p.h | 4 ++--
net/9p/error.c | 4 +---
net/9p/trans_fd.c | 4 +---
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index b8eb51a..0a9577d 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -571,7 +571,7 @@ struct p9_fcall {
void p9_idpool_put(int id, struct p9_idpool *p);
int p9_idpool_check(int id, struct p9_idpool *p);
-int p9_error_init(void);
-int p9_trans_fd_init(void);
+void p9_error_init(void);
+void p9_trans_fd_init(void);
void p9_trans_fd_exit(void);
#endif /* NET_9P_H */
diff --git a/net/9p/error.c b/net/9p/error.c
index 126fd0d..458e038 100644
--- a/net/9p/error.c
+++ b/net/9p/error.c
@@ -190,7 +190,7 @@ struct errormap {
*
*/
-int p9_error_init(void)
+void p9_error_init(void)
{
struct errormap *c;
int bucket;
@@ -206,8 +206,6 @@ int p9_error_init(void)
INIT_HLIST_NODE(&c->list);
hlist_add_head(&c->list, &hash_errmap[bucket]);
}
-
- return 1;
}
EXPORT_SYMBOL(p9_error_init);
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index e2ef3c7..e0f36c9 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -1121,13 +1121,11 @@ static void p9_poll_workfn(struct work_struct *work)
p9_debug(P9_DEBUG_TRANS, "finish\n");
}
-int p9_trans_fd_init(void)
+void p9_trans_fd_init(void)
{
v9fs_register_trans(&p9_tcp_trans);
v9fs_register_trans(&p9_unix_trans);
v9fs_register_trans(&p9_fd_trans);
-
- return 0;
}
void p9_trans_fd_exit(void)
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH] net: ethernet: cpsw-phy-sel: prefer phandle for phy sel and update binding
From: Andrew Lunn @ 2018-08-08 11:58 UTC (permalink / raw)
To: Tony Lindgren
Cc: David Miller, netdev, linux-omap, devicetree, Grygorii Strashko,
Ivan Khoronzhuk, Mark Rutland, Murali Karicheri, Rob Herring
In-Reply-To: <20180808080354.100146-1-tony@atomide.com>
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -19,6 +19,9 @@ Required properties:
> - slaves : Specifies number for slaves
> - active_slave : Specifies the slave to use for time stamping,
> ethtool and SIOCGMIIPHY
> +- cpsw-phy-sel : Specifies the phandle to the CPSW phy mode selection
> + device. Note that in legacy cases cpsw-phy-sel may be
> + a child device instead of a phandle.
Hi Tony
It would be good to reference cpsw-phy-sel.txt.
> Optional properties:
> - ti,hwmods : Must be "cpgmac0"
> @@ -75,6 +78,7 @@ Examples:
> cpts_clock_mult = <0x80000000>;
> cpts_clock_shift = <29>;
> syscon = <&cm>;
> + cpsw-phy-sel = <&phy_sel>;
> cpsw_emac0: slave@0 {
> phy_id = <&davinci_mdio>, <0>;
> phy-mode = "rgmii-txid";
> @@ -103,6 +107,7 @@ Examples:
> cpts_clock_mult = <0x80000000>;
> cpts_clock_shift = <29>;
> syscon = <&cm>;
> + cpsw-phy-sel = <&phy_sel>;
> cpsw_emac0: slave@0 {
> phy_id = <&davinci_mdio>, <0>;
> phy-mode = "rgmii-txid";
> diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> @@ -170,10 +170,13 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
> struct device_node *node;
> struct cpsw_phy_sel_priv *priv;
>
> - node = of_get_child_by_name(dev->of_node, "cpsw-phy-sel");
> + node = of_parse_phandle(dev->of_node, "cpsw-phy-sel", 0);
> if (!node) {
Do you need to handle EPROBE_DEFER here? The phandle points to a
device which has not yet been loaded? I'm not sure exactly where it
will be returned, maybe it is bus_find_device(), but i expect to see
some handling of it somewhere in this function.
> - dev_err(dev, "Phy mode driver DT not found\n");
> - return;
> + node = of_get_child_by_name(dev->of_node, "cpsw-phy-sel");
> + if (!node) {
> + dev_err(dev, "Phy mode driver DT not found\n");
> + return;
> + }
> }
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/5] net: aquantia: fix hw_atl_utils_fw_upload_dwords
From: Andrew Lunn @ 2018-08-08 12:03 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <7ad5aaa26e9a478fb4d81dd05412c880c048dce8.1533650064.git.igor.russkikh@aquantia.com>
On Wed, Aug 08, 2018 at 01:57:11PM +0300, Igor Russkikh wrote:
> From: Yana Esina <yana.esina@aquantia.com>
>
> This patch fixes the upload function, which worked incorrectly with
> some chips.
Hi Igor
This patch contains a few whitespace changes. It is normal to put them
into a separate patch.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH v6 8/9] net/mlx5: Do not call pcie_print_link_status()
From: Tal Gilboa @ 2018-08-08 14:23 UTC (permalink / raw)
To: Leon Romanovsky, Alexandru Gagniuc
Cc: linux-pci, bhelgaas, jakub.kicinski, keith.busch, alex_gagniuc,
austin_bolen, shyam_iyer, Ariel Elior, everest-linux-l2,
David S. Miller, Michael Chan, Ganesh Goudar, Jeff Kirsher,
Tariq Toukan, Saeed Mahameed, Dirk van der Merwe, netdev,
linux-kernel, intel-wired-lan, linux-rdma, oss-drivers,
Saeed Mahameed
In-Reply-To: <20180808060848.GQ13378@mtr-leonro.mtl.com>
On 8/8/2018 9:08 AM, Leon Romanovsky wrote:
> On Mon, Aug 06, 2018 at 06:25:42PM -0500, Alexandru Gagniuc wrote:
>> This is now done by the PCI core to warn of sub-optimal bandwidth.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>
> Thanks,
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
>
Alex,
I loaded mlx5 driver with and without these series. The report in dmesg
is now missing. From what I understood, the status should be reported at
least once, even if everything is in order. We need this functionality
to stay.
net-next (dmesg output for 07:00.0):
[270498.625351] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
[270498.632130] mlx5_core 0000:07:00.0: 63.008 Gb/s available PCIe
bandwidth (8 GT/s x8 link)
[270499.169533] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
uc(1024) max mc(16384)
[270499.182358] mlx5_core 0000:07:00.0: Port module event: module 0,
Cable plugged
net-next + patches (dmesg output for 07:00.0):
[ 331.608472] mlx5_core 0000:07:00.0: firmware version: 14.22.4020
[ 332.564938] (0000:07:00.0): E-Switch: Total vports 9, per vport: max
uc(1024) max mc(16384)
[ 332.616271] mlx5_core 0000:07:00.0: Port module event: module 0,
Cable plugged
^ permalink raw reply
* [patch net-next] net: sched: fix block->refcnt decrement
From: Jiri Pirko @ 2018-08-08 12:04 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, vladbu, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Currently the refcnt is never decremented in case the value is not 1.
Fix it by adding decrement in case the refcnt is not 1.
Reported-by: Vlad Buslov <vladbu@mellanox.com>
Fixes: f71e0ca4db18 ("net: sched: Avoid implicit chain 0 creation")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 194c2e0b2737..f922ce27ed5e 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -780,6 +780,8 @@ void tcf_block_put_ext(struct tcf_block *block, struct Qdisc *q,
block->refcnt--;
if (list_empty(&block->chain_list))
kfree(block);
+ } else {
+ block->refcnt--;
}
}
EXPORT_SYMBOL(tcf_block_put_ext);
--
2.14.4
^ permalink raw reply related
* Re: [PATCH net-next v6 10/11] net: sched: atomically check-allocate action
From: Vlad Buslov @ 2018-08-08 12:06 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik, Jiri Pirko
In-Reply-To: <CAM_iQpU+tWo4HVmQV+UCcLCmULd=kfsPZg+M+2rVvMbHN=2jww@mail.gmail.com>
On Wed 08 Aug 2018 at 01:20, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Jul 5, 2018 at 7:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>> Implement function that atomically checks if action exists and either takes
>> reference to it, or allocates idr slot for action index to prevent
>> concurrent allocations of actions with same index. Use EBUSY error pointer
>> to indicate that idr slot is reserved.
>
> A dumb question:
>
> How could "concurrent allocations of actions with same index" happen
> as you already take idrinfo->lock for the whole
> tcf_idr_check_alloc()??
I guess my changelog is not precise enough in this description.
Let look into sequence of events of initialization of new action:
1) tcf_idr_check_alloc() is called by action init.
2) idrinfo->lock is taken.
3) Lookup in idr is performed to determine if action with specified
index already exists.
4) EBUSY pointer is inserted to indicate that id is taken.
5) idrinfo->lock is released.
6) tcf_idr_check_alloc() returns to action init code.
7) New action is allocated and initialized.
8) tcf_idr_insert() is called.
9) idrinfo->lock is taken.
10) EBUSY pointer is substituted with pointer to new action.
11) idrinfo->lock is released.
12) tcf_idr_insert() returns.
So in this case "concurrent allocations of actions with same index"
means not the allocation with same index during tcf_idr_check_alloc(),
but during the period when idrinfo->lock was released(6-8).
>
> For me, it should be only one allocation could succeed, all others
> should fail.
Correct! And this change is made specifically to enforce that rule.
Otherwise, multiple processes could try to create new action with same
id at the same time, and all processes that executed 3, before any
process reached 10, will "succeed" by overwriting each others action in
idr. (and leak memory while doing so)
>
> Maybe you are trying to prevent others treat it like existing one,
> but in that case you can just hold the idinfo->lock for all idr operations.
>
> And more importantly, upper layer is able to tell it is a creation or
> just replace, you don't have to check this in this complicated way.
>
> IOW, all of these complicated code should not exist.
Original code was simpler and didn't involve temporary EBUSY pointer.
This change was made according to Jiri's request. He wanted to have
unified API to be used by all actions and suggested this approach
specifically.
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: aquantia: definitions for WOL patch
From: Andrew Lunn @ 2018-08-08 12:06 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <a3e119c80dd7afa6a4622f80eb0d1cc73dabbe81.1533650064.git.igor.russkikh@aquantia.com>
> -struct __packed hw_aq_atl_utils_fw_rpc {
> +struct __packed hw_atl_utils_fw_rpc {
> u32 msg_id;
Hi Igor
There is no explanation given as to why you decided to rename this
structure. Please do the rename as a standalone patch, no
functionality change. That makes it easier to review the new
functionality.
Andrew
^ permalink raw reply
* [PATCH] drivers/net/usb/r8152: change rtl8152_system_suspend to be void function
From: zhong jiang @ 2018-08-08 14:26 UTC (permalink / raw)
To: davem, edumazet; +Cc: netdev, linux-kernel
rtl8152_system_suspend defines the variable "ret", but it is not modified
after initialization. Further, I find that any of the callees do not
handle the return value. So It is safe to drop the variable and make it to
be void function.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/usb/r8152.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 124211a..cc51ac8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4412,10 +4412,9 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
return ret;
}
-static int rtl8152_system_suspend(struct r8152 *tp)
+static void rtl8152_system_suspend(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
- int ret = 0;
netif_device_detach(netdev);
@@ -4429,8 +4428,6 @@ static int rtl8152_system_suspend(struct r8152 *tp)
tp->rtl_ops.down(tp);
napi_enable(napi);
}
-
- return ret;
}
static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
@@ -4443,7 +4440,7 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
if (PMSG_IS_AUTO(message))
ret = rtl8152_runtime_suspend(tp);
else
- ret = rtl8152_system_suspend(tp);
+ rtl8152_system_suspend(tp);
mutex_unlock(&tp->control);
--
1.7.12.4
^ permalink raw reply related
* [PATCH net 1/3] net/smc: no shutdown in state SMC_LISTEN
From: Ursula Braun @ 2018-08-08 12:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
Invoking shutdown for a socket in state SMC_LISTEN does not make
sense. Nevertheless programs like syzbot fuzzing the kernel may
try to do this. For SMC this means a socket refcounting problem.
This patch makes sure a shutdown call for an SMC socket in state
SMC_LISTEN simply returns with -ENOTCONN.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 05e4ffe5aabd..1288c7bf40d5 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1397,8 +1397,7 @@ static int smc_shutdown(struct socket *sock, int how)
lock_sock(sk);
rc = -ENOTCONN;
- if ((sk->sk_state != SMC_LISTEN) &&
- (sk->sk_state != SMC_ACTIVE) &&
+ if ((sk->sk_state != SMC_ACTIVE) &&
(sk->sk_state != SMC_PEERCLOSEWAIT1) &&
(sk->sk_state != SMC_PEERCLOSEWAIT2) &&
(sk->sk_state != SMC_APPCLOSEWAIT1) &&
--
2.16.4
^ permalink raw reply related
* [PATCH net 2/3] net/smc: allow sysctl rmem and wmem defaults for servers
From: Ursula Braun @ 2018-08-08 12:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
Without setsockopt SO_SNDBUF and SO_RCVBUF settings, the sysctl
defaults net.ipv4.tcp_wmem and net.ipv4.tcp_rmem should be the base
for the sizes of the SMC sndbuf and rcvbuf. Any TCP buffer size
optimizations for servers should be ignored.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 1288c7bf40d5..0ee7721afbe5 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1122,6 +1122,8 @@ static void smc_tcp_listen_work(struct work_struct *work)
sock_hold(lsk); /* sock_put in smc_listen_work */
INIT_WORK(&new_smc->smc_listen_work, smc_listen_work);
smc_copy_sock_settings_to_smc(new_smc);
+ new_smc->sk.sk_sndbuf = lsmc->sk.sk_sndbuf;
+ new_smc->sk.sk_rcvbuf = lsmc->sk.sk_rcvbuf;
sock_hold(&new_smc->sk); /* sock_put in passive closing */
if (!schedule_work(&new_smc->smc_listen_work))
sock_put(&new_smc->sk);
--
2.16.4
^ permalink raw reply related
* [PATCH net 3/3] net/smc: move sock lock in smc_ioctl()
From: Ursula Braun @ 2018-08-08 12:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
When an SMC socket is connecting it is decided whether fallback to
TCP is needed. To avoid races between connect and ioctl move the
sock lock before the use_fallback check.
Reported-by: syzbot+5b2cece1a8ecb2ca77d8@syzkaller.appspotmail.com
Reported-by: syzbot+19557374321ca3710990@syzkaller.appspotmail.com
Fixes: 1992d99882af ("net/smc: take sock lock in smc_ioctl()")
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 0ee7721afbe5..e7de5f282722 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1522,12 +1522,16 @@ static int smc_ioctl(struct socket *sock, unsigned int cmd,
smc = smc_sk(sock->sk);
conn = &smc->conn;
+ lock_sock(&smc->sk);
if (smc->use_fallback) {
- if (!smc->clcsock)
+ if (!smc->clcsock) {
+ release_sock(&smc->sk);
return -EBADF;
- return smc->clcsock->ops->ioctl(smc->clcsock, cmd, arg);
+ }
+ answ = smc->clcsock->ops->ioctl(smc->clcsock, cmd, arg);
+ release_sock(&smc->sk);
+ return answ;
}
- lock_sock(&smc->sk);
switch (cmd) {
case SIOCINQ: /* same as FIONREAD */
if (smc->sk.sk_state == SMC_LISTEN) {
--
2.16.4
^ permalink raw reply related
* Re: [PATCH net-next 3/5] net: aquantia: implement WOL support
From: Andrew Lunn @ 2018-08-08 12:16 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <4b6c2d73c19dac481fbf2656f7a24da90966130b.1533650064.git.igor.russkikh@aquantia.com>
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> @@ -889,11 +889,13 @@ void aq_nic_deinit(struct aq_nic_s *self)
> self->aq_vecs > i; ++i, aq_vec = self->aq_vec[i])
> aq_vec_deinit(aq_vec);
>
> - if (self->power_state == AQ_HW_POWER_STATE_D0) {
> - (void)self->aq_fw_ops->deinit(self->aq_hw);
> - } else {
> - (void)self->aq_hw_ops->hw_set_power(self->aq_hw,
> - self->power_state);
> + (void)self->aq_fw_ops->deinit(self->aq_hw);
These void casts look a bit ugly. Are they needed? Is the compiler
complaining? If it is complaining, it suggests you should not be
casting anyway...
> + if (wol_enabled) {
> + rpc_size = sizeof(prpc->msg_id) + sizeof(prpc->msg_wol);
> +
> + prpc->msg_id = HAL_ATLANTIC_UTILS_FW_MSG_WOL_ADD;
> + prpc->msg_wol.priority = 0x10000000; /* normal priority */
> + prpc->msg_wol.pattern_id = 1U;
> + prpc->msg_wol.wol_packet_type = 2U; /* Magic Packet */
Maybe add #defines for these magic numbers?
> +
> + ether_addr_copy((u8 *)&prpc->msg_wol.wol_pattern, mac);
> + } else {
> + rpc_size = sizeof(prpc->msg_id) + sizeof(prpc->msg_del_id);
> +
> + prpc->msg_id = HAL_ATLANTIC_UTILS_FW_MSG_WOL_DEL;
> + prpc->msg_wol.pattern_id = 1U;
> + }
> +
> + err = hw_atl_utils_fw_rpc_call(self, rpc_size);
> +
> +err_exit:
> + return err;
> +}
Andrew
^ permalink raw reply
* RE: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Ben Whitten @ 2018-08-08 12:24 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <e041fa89-9375-b0f2-db4d-8a64793cb78a@suse.de>
> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
> register, bit-fields, and helpers for regmap
>
> Am 07.08.2018 um 19:32 schrieb Ben Whitten:
> > diff --git a/drivers/net/lora/sx1301.c
> b/drivers/net/lora/sx1301.c
> > index 5342b61..49958f0 100644
> > --- a/drivers/net/lora/sx1301.c
> > +++ b/drivers/net/lora/sx1301.c
> [...]
> > @@ -76,8 +287,29 @@ struct sx1301_priv {
> > struct gpio_desc *rst_gpio;
> > u8 cur_page;
> > struct spi_controller *radio_a_ctrl, *radio_b_ctrl;
> > + struct regmap *regmap;
> > + struct regmap_field
> *regmap_fields[ARRAY_SIZE(sx1301_reg_fields)];
> > };
> >
> > +static int sx1301_field_read(struct sx1301_priv *priv,
> > + enum sx1301_fields field_id)
> > +{
> > + int ret;
> > + int val;
> > +
> > + ret = regmap_field_read(priv-
> >regmap_fields[field_id], &val);
> > + if (ret)
> > + return ret;
> > +
> > + return val;
>
> This strikes me as a bad idea. Please keep returning the
> value by
> pointer, so that we can clearly distinguish from error values.
Good point, will change it.
> > +}
> > +
> > +static int sx1301_field_write(struct sx1301_priv *priv,
> > + enum sx1301_fields field_id, u8 val)
> > +{
> > + return regmap_field_write(priv-
> >regmap_fields[field_id], val);
> > +}
> > +
> > static int sx1301_read_burst(struct spi_device *spi, u8
> reg, u8 *val, size_t len)
> > {
> > u8 addr = reg & 0x7f;
> [snip]
>
> It looks to me as if both of those static functions are unused
> in this
> patch? Please keep things bisectable.
Sure, it was a prep patch bit I can include these functions in the
next one along where they are actually used.
Thanks,
Ben
^ permalink raw reply
* Re: [PATCH net-next 4/5] net: aquantia: implement EEE support
From: Andrew Lunn @ 2018-08-08 12:27 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <3e548f24d79bc03a14e3b8cdb6708c5db6a61cc4.1533650064.git.igor.russkikh@aquantia.com>
> +static int aq_ethtool_get_eee(struct net_device *ndev, struct ethtool_eee *eee)
> +{
> + struct aq_nic_s *aq_nic = netdev_priv(ndev);
> + int err = 0;
> +
> + u32 rate, supported_rates;
Please keep all local variables together and sort them as reverse
christmas tree. This should apply to all new code you are adding.
> index 3c94cff..a021dc4 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h
> @@ -62,12 +62,6 @@
> #define HW_ATL_A0_MPI_SPEED_MSK 0xFFFFU
> #define HW_ATL_A0_MPI_SPEED_SHIFT 16U
>
> -#define HW_ATL_A0_RATE_10G BIT(0)
> -#define HW_ATL_A0_RATE_5G BIT(1)
> -#define HW_ATL_A0_RATE_2G5 BIT(3)
> -#define HW_ATL_A0_RATE_1G BIT(4)
> -#define HW_ATL_A0_RATE_100M BIT(5)
> -
> #define HW_ATL_A0_TXBUF_MAX 160U
> #define HW_ATL_A0_RXBUF_MAX 320U
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> index 0ad6ac5..7bd1bea 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> @@ -40,6 +40,11 @@
> #define HW_ATL_FW2X_CTRL_ASYMMETRIC_PAUSE BIT(CTRL_ASYMMETRIC_PAUSE)
> #define HW_ATL_FW2X_CTRL_FORCE_RECONNECT BIT(CTRL_FORCE_RECONNECT)
>
> +#define HW_ATL_FW2X_CAP_EEE_1G_MASK BIT(CAPS_HI_1000BASET_FD_EEE)
> +#define HW_ATL_FW2X_CAP_EEE_2G5_MASK BIT(CAPS_HI_2P5GBASET_FD_EEE)
> +#define HW_ATL_FW2X_CAP_EEE_5G_MASK BIT(CAPS_HI_5GBASET_FD_EEE)
> +#define HW_ATL_FW2X_CAP_EEE_10G_MASK BIT(CAPS_HI_10GBASET_FD_EEE)
Please do this rename as a separate patch, so we can clearly see new
EEE code which needs close review, from the simple renaming which
needs little review.
In general, it is better to have lots of simple patches, which do just
one things, rather than a big patch making lots of unrelated changes.
Andrew
^ permalink raw reply
* [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Anssi Hannula @ 2018-08-08 12:19 UTC (permalink / raw)
To: Nicolas Ferre, David S. Miller; +Cc: netdev
macb_close() calls macb_reset_hw() which zeroes NCR register, including
the MPE (Management Port Enable) bit.
This will prevent accessing any other PHYs for other Ethernet MACs on
the MDIO bus which is still registered.
Fix that by keeping the MPE bit set.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
---
drivers/net/ethernet/cadence/macb_main.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index dc09f9a8a49b..3ca98fc32144 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2030,12 +2030,13 @@ static void macb_reset_hw(struct macb *bp)
unsigned int q;
/* Disable RX and TX (XXX: Should we halt the transmission
- * more gracefully?)
+ * more gracefully?) but keep management port open since there
+ * may be other users of the mdio bus
*/
- macb_writel(bp, NCR, 0);
+ macb_writel(bp, NCR, MACB_BIT(MPE));
/* Clear the stats registers (XXX: Update stats first?) */
- macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
+ macb_writel(bp, NCR, MACB_BIT(CLRSTAT) | MACB_BIT(MPE));
/* Clear all status flags */
macb_writel(bp, TSR, -1);
--
2.16.3
^ permalink raw reply related
* Re: [PATCH net-next 5/5] net: aquantia: bump driver version
From: Andrew Lunn @ 2018-08-08 12:32 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev
In-Reply-To: <5ad3aff3900698f8b27c7bb327427256ae847241.1533650064.git.igor.russkikh@aquantia.com>
On Wed, Aug 08, 2018 at 01:57:15PM +0300, Igor Russkikh wrote:
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> ---
> drivers/net/ethernet/aquantia/atlantic/ver.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/ver.h b/drivers/net/ethernet/aquantia/atlantic/ver.h
> index 94efc64..b482601 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/ver.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/ver.h
> @@ -12,7 +12,7 @@
>
> #define NIC_MAJOR_DRIVER_VERSION 2
> #define NIC_MINOR_DRIVER_VERSION 0
> -#define NIC_BUILD_DRIVER_VERSION 3
> +#define NIC_BUILD_DRIVER_VERSION 4
> #define NIC_REVISION_DRIVER_VERSION 0
>
> #define AQ_CFG_DRV_VERSION_SUFFIX "-kern"
Hi Igor
Driver versions are pretty much useless. Say somebody backports this
driver into a vendor kernel. Vendor kernels are typically based on an
old kernel, plus thousands of patches. Is 2.0.4 on such a kernel the
same as 2.0.4 in 4.19?
You probably want to remove this, just the avoid people thinking is
means something.
Andrew
^ permalink raw reply
* RE: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Ben Whitten @ 2018-08-08 12:32 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <6faee71e-1226-9f24-6e0d-46a9dbb4d6c2@suse.de>
> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
> register, bit-fields, and helpers for regmap
>
> Am 07.08.2018 um 19:32 schrieb Ben Whitten:
> > From: Ben Whitten <ben.whitten@lairdtech.com>
> >
> > The register and bit-field definitions are taken from the
> SX1301
> > datasheet version 2.01 dated June 2014 with the revision
> information
> > 'First released version'.
> >
> > The reset state and RW capability of each field is not
> reflected in this
> > patch however from the datasheet:
> > "Bits and registers that are not documented are reserved.
> They may
> > include calibration values. It is important not to modify
> these bits and
> > registers. If specific bits must be changed in a register with
> reserved
> > bits, the register must be read first, specific bits modified
> while
> > masking reserved bits and then the register can be
> written."
> >
> > Then goes on to state:
> > "Reserved bits should be written with their reset state,
> they may be
> > read different states."
> >
> > Caching is currently disabled.
> >
> > The version is read back using regmap_read to verify
> regmap operation,
> > in doing so needs to be moved after priv and regmap
> allocation.
> >
> > Signed-off-by: Ben Whitten
> <ben.whitten@lairdtech.com>
> > ---
> > drivers/net/lora/Kconfig | 1 +
> > drivers/net/lora/sx1301.c | 282
> +++++++++++++++++++++++++++++++++++++++++++---
> > drivers/net/lora/sx1301.h | 169
> +++++++++++++++++++++++++++
> > 3 files changed, 439 insertions(+), 13 deletions(-)
> > create mode 100644 drivers/net/lora/sx1301.h
>
> My main concern about this patch is its sheer size. Normally
> for
> #defines the rule is not to add unused ones. Here I see for
> example FSK
> RSSI fields that we're surely not using yet. Any chance to
> strip this
> down some more?
Sure, I'll strip the reg_fields down to those only required for
loading firmware and setting clocks that will be used in the
immediate term. This does clutter the driver a bit
unnecessarily at the moment.
I would like to keep the full register dump in the header file
though as its self-contained and gives a full picture of the chip.
Thanks,
Ben
^ permalink raw reply
* Re: [PATCH net-next 13/14] net: core: add new/replace rate estimator lock parameter
From: Vlad Buslov @ 2018-08-08 12:30 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: netdev, davem, jhs, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook
In-Reply-To: <20180808013724.GE14666@localhost.localdomain>
On Wed 08 Aug 2018 at 01:37, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> On Mon, Aug 06, 2018 at 09:54:24AM +0300, Vlad Buslov wrote:
>> Extend rate estimator 'new' and 'replace' APIs with additional spinlock
>> parameter to be used by rtnl-unlocked actions to protect rate_est pointer
>> from concurrent modification.
>
> I'm wondering if this additional parameter is really needed. So far,
> the only case in which it is not NULL, the same lock that is used to
> protect the stats is also used in this new parameter.
>
> ...
>
>> --- a/net/sched/act_police.c
>> +++ b/net/sched/act_police.c
>> @@ -138,7 +138,7 @@ static int tcf_act_police_init(struct net *net, struct nlattr *nla,
>>
>> if (est) {
>> err = gen_replace_estimator(&police->tcf_bstats, NULL,
>> - &police->tcf_rate_est,
>> + &police->tcf_rate_est, NULL,
>> &police->tcf_lock,
>> NULL, est);
>
> Which is here, and this new NULL arg is replaced by &police->tcf_lock
> in the next patch.
>
> Do you foresee a case in which a different lock will be used?
Not in my use-case, no.
> Or maybe it is because the current one is explicitly aimed towards the
> stats?
Yes, stats lock is only taken when fetching counters. You think better
approach would be to rely on the fact that, in case of police action,
same lock is already passed as stats lock? Having it as standalone
argument looked like cleaner approach to me. If you think this change is
too much code for very little benefit, I can reuse stats lock.
>
> Marcelo
Thank you for reviewing my code!
^ permalink raw reply
* [PATCH iproute2] tc: bpf: update list of archs with eBPF support in manpage
From: Tobias Klauser @ 2018-08-08 12:33 UTC (permalink / raw)
To: netdev; +Cc: stephen, daniel
Update the list of architectures supporting eBPF JIT as of Linux 4.18.
Also mention the Linux version where support for a particular
architecture was introduced. Finally, reformat the list of architectures
as a bullet list in order to make it more readable.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
man/man8/tc-bpf.8 | 37 +++++++++++++++++++++++++++++++++----
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8
index d311f295615b..b2f9344f5e28 100644
--- a/man/man8/tc-bpf.8
+++ b/man/man8/tc-bpf.8
@@ -79,10 +79,39 @@ In Linux, it's generally considered that eBPF is the successor of cBPF.
The kernel internally transforms cBPF expressions into eBPF expressions and
executes the latter. Execution of them can be performed in an interpreter
or at setup time, they can be just-in-time compiled (JIT'ed) to run as
-native machine code. Currently, x86_64, ARM64, s390, ppc64 and sparc64
-architectures have eBPF JIT support, whereas PPC, SPARC, ARM and MIPS have
-cBPF, but did not (yet) switch to eBPF JIT support.
-
+native machine code.
+.PP
+Currently, the eBPF JIT compiler is available for the following architectures:
+.IP * 4
+x86_64 (since Linux 3.18)
+.PD 0
+.IP *
+arm64 (since Linux 3.18)
+.IP *
+s390 (since Linux 4.1)
+.IP *
+ppc64 (since Linux 4.8)
+.IP *
+sparc64 (since Linux 4.12)
+.IP *
+mips64 (since Linux 4.13)
+.IP *
+arm32 (since Linux 4.14)
+.IP *
+x86_32 (since Linux 4.18)
+.PD
+.PP
+Whereas the following architectures have cBPF, but did not (yet) switch to eBPF
+JIT support:
+.IP * 4
+ppc32
+.PD 0
+.IP *
+sparc32
+.IP *
+mips32
+.PD
+.PP
eBPF's instruction set has similar underlying principles as the cBPF
instruction set, it however is modelled closer to the underlying
architecture to better mimic native instruction sets with the aim to
--
2.18.0.130.g98da2f6b3e4a
^ permalink raw reply related
* [PATCH] net: dsa: rtl8366rb: Support port 4 (WAN)
From: Linus Walleij @ 2018-08-08 12:38 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli
Cc: netdev, openwrt-devel, LEDE Development List, Linus Walleij
The totally undocumented IO mode needs to be set to enumerator
0 to enable port 4 also known as WAN in most configurations,
for ordinary traffic. The 3 bits in the register come up as
010 after reset, but need to be set to 000.
The Realtek source code contains a name for these bits, but
no explanation of what the 8 different IO modes may be.
Set it to zero for the time being and drop a comment so
people know what is going on if they run into trouble. This
"mode zero" works fine with the D-Link DIR-685 with
RTL8366RB.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/net/dsa/rtl8366rb.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index 1e55b9bf8b56..a4d5049df692 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c
@@ -48,6 +48,23 @@
#define RTL8366RB_SSCR2 0x0004
#define RTL8366RB_SSCR2_DROP_UNKNOWN_DA BIT(0)
+/* Port Mode Control registers */
+#define RTL8366RB_PMC0 0x0005
+#define RTL8366RB_PMC0_SPI BIT(0)
+#define RTL8366RB_PMC0_EN_AUTOLOAD BIT(1)
+#define RTL8366RB_PMC0_PROBE BIT(2)
+#define RTL8366RB_PMC0_DIS_BISR BIT(3)
+#define RTL8366RB_PMC0_ADCTEST BIT(4)
+#define RTL8366RB_PMC0_SRAM_DIAG BIT(5)
+#define RTL8366RB_PMC0_EN_SCAN BIT(6)
+#define RTL8366RB_PMC0_P4_IOMODE_SHIFT 7
+#define RTL8366RB_PMC0_P4_IOMODE_MASK GENMASK(9, 7)
+#define RTL8366RB_PMC0_P5_IOMODE_SHIFT 10
+#define RTL8366RB_PMC0_P5_IOMODE_MASK GENMASK(12, 10)
+#define RTL8366RB_PMC0_SDSMODE_SHIFT 13
+#define RTL8366RB_PMC0_SDSMODE_MASK GENMASK(15, 13)
+#define RTL8366RB_PMC1 0x0006
+
/* Port Mirror Control Register */
#define RTL8366RB_PMCR 0x0007
#define RTL8366RB_PMCR_SOURCE_PORT(a) (a)
@@ -860,6 +877,19 @@ static int rtl8366rb_setup(struct dsa_switch *ds)
if (ret)
return ret;
+ /* Port 4 setup: this enables Port 4, usually the WAN port,
+ * common PHY IO mode is apparently mode 0, and this is not what
+ * the port is initialized to. There is no explanation of the
+ * IO modes in the Realtek source code, if your WAN port is
+ * connected to something exotic such as fiber, then this might
+ * be worth experimenting with.
+ */
+ ret = regmap_update_bits(smi->map, RTL8366RB_PMC0,
+ RTL8366RB_PMC0_P4_IOMODE_MASK,
+ 0 << RTL8366RB_PMC0_P4_IOMODE_SHIFT);
+ if (ret)
+ return ret;
+
/* Discard VLAN tagged packets if the port is not a member of
* the VLAN with which the packets is associated.
*/
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] mlxsw: spectrum_flower: use PTR_ERR_OR_ZERO()
From: Ido Schimmel @ 2018-08-08 15:08 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, jiri, linux-kernel, netdev
In-Reply-To: <20180808122908.13664-1-yuehaibing@huawei.com>
On Wed, Aug 08, 2018 at 08:29:08PM +0800, YueHaibing wrote:
> Fix ptr_ret.cocci warnings:
> drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c:543:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks!
^ permalink raw reply
* Re: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Andreas Färber @ 2018-08-08 12:51 UTC (permalink / raw)
To: Ben Whitten, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <BY1PR02MB11148226468391B114163BDAE7260@BY1PR02MB1114.namprd02.prod.outlook.com>
Am 08.08.2018 um 14:32 schrieb Ben Whitten:
>>> drivers/net/lora/Kconfig | 1 +
>>> drivers/net/lora/sx1301.c | 282
>> +++++++++++++++++++++++++++++++++++++++++++---
>>> drivers/net/lora/sx1301.h | 169
>> +++++++++++++++++++++++++++
>>> 3 files changed, 439 insertions(+), 13 deletions(-)
>>> create mode 100644 drivers/net/lora/sx1301.h
>>
>> My main concern about this patch is its sheer size. Normally
>> for
>> #defines the rule is not to add unused ones. Here I see for
>> example FSK
>> RSSI fields that we're surely not using yet. Any chance to
>> strip this
>> down some more?
>
> Sure, I'll strip the reg_fields down to those only required for
> loading firmware and setting clocks that will be used in the
> immediate term. This does clutter the driver a bit
> unnecessarily at the moment.
> I would like to keep the full register dump in the header file
> though as its self-contained and gives a full picture of the chip.
Could you do that in more steps though? I'm thinking, convert only the
registers in use to regmap (that'll make it easier to review), then add
more registers, then convert to regmap fields?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] net: dsa: rtl8366rb: Support port 4 (WAN)
From: Andrew Lunn @ 2018-08-08 12:57 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, openwrt-devel,
LEDE Development List
In-Reply-To: <20180808123855.18729-1-linus.walleij@linaro.org>
On Wed, Aug 08, 2018 at 02:38:55PM +0200, Linus Walleij wrote:
> The totally undocumented IO mode needs to be set to enumerator
> 0 to enable port 4 also known as WAN in most configurations,
> for ordinary traffic. The 3 bits in the register come up as
> 010 after reset, but need to be set to 000.
>
> The Realtek source code contains a name for these bits, but
> no explanation of what the 8 different IO modes may be.
Hi Linus
I'm guessing this is MII, RMII, GMII, RGMII etc.
If it is, using phy-mode would be good. But that can wait until we
actually know.
> Set it to zero for the time being and drop a comment so
> people know what is going on if they run into trouble. This
> "mode zero" works fine with the D-Link DIR-685 with
> RTL8366RB.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: Is it currently possible to connect SFP to dsa port?
From: Marek Behún @ 2018-08-08 13:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Russell King - ARM Linux
In-Reply-To: <20180807195820.GA7275@lunn.ch>
On Tue, 7 Aug 2018 21:58:20 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> Hi Marek
>
> I'm currently working on exactly this!
>
> My primary aim is to allow SFP on ports 9 and 10. ports 2-7 can also
> be connected to SFPs, but that is a bit harder, so it is going to take
> me a little longer.
>
> I hope i can post patches in the next few days.
>
> Andrew
Hi, this is cool :-) On our board it will be possible to connect
SFP extender board to port 10, and I was afraid it might have been me
to write the support for this :).
Let me know when you have the first version ready, I will try it. Our
router can connect SFP board directly to the CPU board, or there may up
to three mv88e6190 switch boards between SFP board and cpu board.
Do you already have a stable dts binding for how to bind sfp to dsa
port?
Btw: some SFP modules can operate in 2500BASE-X mode. Currently the SFP
driver does not support this, and there even isn't code in the
mainline kernel for mvneta to switch to 2500BASEX. On Armada 3720 this
has to be done by configuring comphy, which is currently done in
u-boot. As a side project I am working on supporting Armada 3720 comphy
in the kernel, so that it will be possible to set 2500BASE-X mode.
The mv88e6190/6390 can configure ports 9 and 10 to either
1000BASE-X/SGMII od 2500BASE-X, but this has to be done by setting a
pin and reseting the switch. Our board is able to configure this pin,
and the plan is to do this in u-boot when SFP board is detected to be
connected to the switch board. In this case the port is configured to
1000BASE-X.
I am wondering how complicated would it be to support changing these
modes for port 9 and 10 in mv88exxxx driver. There could be GPIO port
definitions in devicetree for P9_MODE and P10_MODE (and RESET), and
then the driver would be able to change these modes.
Since the switch has to be reseted to change the mode I think all the
dsa lan ports would have to be unused when doing this, correct?
And still how more complicated would it be if for example the RESET
gpio is shared between multiple switches, while the P9_MODE and
P10_MODE gpios are unique for each switch, like this:
RESET-----+--------+--------+
| | |
+-----+ +--+--+ +--+--+ +--+--+ +-----+
| cpu |==| sw1 |==| sw2 |==| sw3 |==| sfp |
+-----+ +-+-+-+ +-+-+-+ +-+-+-+ +-----+
| | | | | |
P9_MODE[1]--+ | | | | |
P10_MODE[1]----+ | | | | == means SGMII/2500BASE-X
P9_MODE[2]-----------+ | | | connection
P10_MODE[2]-------------+ | |
P9_MODE[3]--------------------+ |
P10_MODE[3]----------------------+
Marek
^ permalink raw reply
* Re: [PATCH iproute2] tc: bpf: update list of archs with eBPF support in manpage
From: Daniel Borkmann @ 2018-08-08 13:10 UTC (permalink / raw)
To: Tobias Klauser, netdev; +Cc: stephen
In-Reply-To: <20180808123340.18446-1-tklauser@distanz.ch>
On 08/08/2018 02:33 PM, Tobias Klauser wrote:
> Update the list of architectures supporting eBPF JIT as of Linux 4.18.
> Also mention the Linux version where support for a particular
> architecture was introduced. Finally, reformat the list of architectures
> as a bullet list in order to make it more readable.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Thanks, Tobias!
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ 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