* Re: [PATCH] net: phy: sftp: print debug message with text, not numbers
From: Andrew Lunn @ 2018-08-09 1:31 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <20180808221657.GO30658@n2100.armlinux.org.uk>
On Wed, Aug 08, 2018 at 11:16:57PM +0100, Russell King - ARM Linux wrote:
> You might want to fix the subject line.
Ah, yes, s/sftp/sfp/
Thanks
Andrew
^ permalink raw reply
* [PATCH bpf] bpf: fix bpffs non-array map seq_show issue
From: Yonghong Song @ 2018-08-09 1:25 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In function map_seq_next() of kernel/bpf/inode.c,
the first key will be the "0" regardless of the map type.
This works for array. But for hash type, if it happens
key "0" is in the map, the bpffs map show will miss
some items if the key "0" is not the first element of
the first bucket.
This patch fixed the issue by guaranteeing to get
the first element, if the seq_show is just started,
by passing NULL pointer key to map_get_next_key() callback.
This way, no missing elements will occur for
bpffs hash table show even if key "0" is in the map.
Fixes: a26ca7c982cb5 ("bpf: btf: Add pretty print support to the basic arraymap")
Signed-off-by: Yonghong Song <yhs@fb.com>
---
kernel/bpf/inode.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c
index 76efe9a183f5..794d06186e93 100644
--- a/kernel/bpf/inode.c
+++ b/kernel/bpf/inode.c
@@ -196,14 +196,17 @@ static void *map_seq_next(struct seq_file *m, void *v, loff_t *pos)
{
struct bpf_map *map = seq_file_to_map(m);
void *key = map_iter(m)->key;
+ void *prev_key;
if (map_iter(m)->done)
return NULL;
if (unlikely(v == SEQ_START_TOKEN))
- goto done;
+ prev_key = NULL;
+ else
+ prev_key = key;
- if (map->ops->map_get_next_key(map, key, key)) {
+ if (map->ops->map_get_next_key(map, prev_key, key)) {
map_iter(m)->done = true;
return NULL;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] drivers/net/usb/r8152: change rtl8152_system_suspend to be void function
From: kbuild test robot @ 2018-08-09 3:47 UTC (permalink / raw)
To: zhong jiang; +Cc: kbuild-all, davem, edumazet, netdev, linux-kernel
In-Reply-To: <1533738407-10495-1-git-send-email-zhongjiang@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]
Hi zhong,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.18-rc8 next-20180808]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/zhong-jiang/drivers-net-usb-r8152-change-rtl8152_system_suspend-to-be-void-function/20180809-111737
config: i386-randconfig-x017-201831 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/net//usb/r8152.c: In function 'rtl8152_suspend':
>> drivers/net//usb/r8152.c:4447:9: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
return ret;
^~~
vim +/ret +4447 drivers/net//usb/r8152.c
8fb280616 hayeswang 2017-01-10 4432
8fb280616 hayeswang 2017-01-10 4433 static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
8fb280616 hayeswang 2017-01-10 4434 {
8fb280616 hayeswang 2017-01-10 4435 struct r8152 *tp = usb_get_intfdata(intf);
8fb280616 hayeswang 2017-01-10 4436 int ret;
8fb280616 hayeswang 2017-01-10 4437
8fb280616 hayeswang 2017-01-10 4438 mutex_lock(&tp->control);
8fb280616 hayeswang 2017-01-10 4439
8fb280616 hayeswang 2017-01-10 4440 if (PMSG_IS_AUTO(message))
a9c54ad2c hayeswang 2017-01-25 4441 ret = rtl8152_runtime_suspend(tp);
8fb280616 hayeswang 2017-01-10 4442 else
31b61d6a0 zhong jiang 2018-08-08 4443 rtl8152_system_suspend(tp);
8fb280616 hayeswang 2017-01-10 4444
b54032736 hayeswang 2014-10-09 4445 mutex_unlock(&tp->control);
b54032736 hayeswang 2014-10-09 4446
6cc69f2a4 hayeswang 2014-10-17 @4447 return ret;
ac718b693 hayeswang 2013-05-02 4448 }
ac718b693 hayeswang 2013-05-02 4449
:::::: The code at line 4447 was first introduced by commit
:::::: 6cc69f2a404dea8641d6cf97c0fbe8d24579e259 r8152: return -EBUSY for runtime suspend
:::::: TO: hayeswang <hayeswang@realtek.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33626 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/r8152: remove the unneeded variable "ret" in rtl8152_system_suspend
From: zhong jiang @ 2018-08-09 3:30 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: davem, netdev, linux-kernel
In-Reply-To: <7544eca5-bbca-06eb-462e-fca036fe1beb@embeddedor.com>
On 2018/8/9 10:28, Gustavo A. R. Silva wrote:
> Hi Zhong,
>
> On 8/8/18 8:39 PM, zhong jiang wrote:
>> rtl8152_system_suspend defines the variable "ret", but it is not modified
>> after initialization. So just remove it.
>>
> Thanks for working on this.
>
> I wonder if you are using any tool like Coccinelle to spot these sort
> of issues. If so, it'd be nice to mention that in the changelog.
Yes, I use the returnval.cocci to spot it. I will remember for next time.
Thanks,
zhong jiang
> The above is important for two reasons, one is to give credit to the people
> behind such tools, and the second one is to add support for metrics collection.
>
> Thanks
> --
> Gustavo
>
>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> drivers/net/usb/r8152.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index 124211a..9774270 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -4415,7 +4415,6 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
>> static int rtl8152_system_suspend(struct r8152 *tp)
>> {
>> struct net_device *netdev = tp->netdev;
>> - int ret = 0;
>>
>> netif_device_detach(netdev);
>>
>> @@ -4430,7 +4429,7 @@ static int rtl8152_system_suspend(struct r8152 *tp)
>> napi_enable(napi);
>> }
>>
>> - return ret;
>> + return 0;
>> }
>>
>> static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
>>
>
^ permalink raw reply
* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Andreas Färber @ 2018-08-09 0:50 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko,
Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora,
Alexander Graf, Michal Kubeček, Rob Herring
In-Reply-To: <92ee4016-1da9-826b-3674-b2d604a64848@suse.de>
Am 05.08.2018 um 02:11 schrieb Andreas Färber:
> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan:
>> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>:
>>> 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK.
>>> Lacking a LoRaWAN implementation, I am currently switching them into LoRa
>>> mode at probe time wherever possible. How do we deal with that properly?
[...]
> Independently of what LoRaWAN does, the
> user needs to be able to send on the physical layer from a selection of
> LoRa, GFSK, FSK, OOK, GMSK and MSK.
> Supposedly Wireless M-Bus and IEEE 802.15.4 can be implemented via those
> according to the SX1276 datasheet.
>
> This opens a can of worms...
>
> SX127x has a single channel, so I don't think there should be six
> network interfaces lora0, gfsk0, fsk0, ook0, gmsk0 and msk0 exposed to
> the user.
> Having a lora0 interface speak non-LoRa modulations may be confusing,
> but since the chip is sold as LoRa transceiver it might be acceptable.
>
> SX130x has 8+2 channels, with IF9 dedicated to GFSK/FSK. It appears to
> use one FIFO for receiving (up to 16 packets) and can only transmit one
> packet at a time. So I think this should be one lora0 interface, too.
>
> With a view to supporting non-LoRa RF chipsets such as Si4xxx (GFSK,
> FSK, OOK) or nRF905 and nRF24L01+ (both GFSK) at a later date, I don't
> think those modulations should be some netlink option on a PF_LORA
> interface but cleanly distinguished as ETH_P_GFSK or something.
> For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module.
Answering myself here: MSK is a special case of FSK, and GMSK a special
case of GFSK. SX1276 allows to switch between LoRa and FSK/OOK modes,
and in FSK/OOK mode between FSK and OOK modulation types and for FSK
modulation allows to set Gaussian filter values. I assume (G)MSK is
selected indirectly through BitRate and Fdev settings or something.
So we would just need ETH_P_FSK and ETH_P_OOK plus some skb fields for
ETH_P_FSK.
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] drivers/net/usb/r8152: remove the unneeded variable "ret" in rtl8152_system_suspend
From: Gustavo A. R. Silva @ 2018-08-09 2:28 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: netdev, linux-kernel
In-Reply-To: <1533778753-38089-1-git-send-email-zhongjiang@huawei.com>
Hi Zhong,
On 8/8/18 8:39 PM, zhong jiang wrote:
> rtl8152_system_suspend defines the variable "ret", but it is not modified
> after initialization. So just remove it.
>
Thanks for working on this.
I wonder if you are using any tool like Coccinelle to spot these sort
of issues. If so, it'd be nice to mention that in the changelog.
The above is important for two reasons, one is to give credit to the people
behind such tools, and the second one is to add support for metrics collection.
Thanks
--
Gustavo
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/net/usb/r8152.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 124211a..9774270 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -4415,7 +4415,6 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
> static int rtl8152_system_suspend(struct r8152 *tp)
> {
> struct net_device *netdev = tp->netdev;
> - int ret = 0;
>
> netif_device_detach(netdev);
>
> @@ -4430,7 +4429,7 @@ static int rtl8152_system_suspend(struct r8152 *tp)
> napi_enable(napi);
> }
>
> - return ret;
> + return 0;
> }
>
> static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
>
^ permalink raw reply
* Re: [PATCH net 0/3] net/smc: fixes 2018-08-08
From: David Miller @ 2018-08-09 2:14 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Wed, 8 Aug 2018 14:13:18 +0200
> here are small fixes for SMC: The first patch makes sure, shutdown code
> is not executed for sockets in state SMC_LISTEN. The second patch resets
> send and receive buffer values for accepted sockets, since TCP buffer size
> optimizations for the internal CLC socket should not be forwarded to the
> outer SMC socket. The third patch solves a race between connect and ioctl
> reported by syzbot.
Series applied, thank you.
^ 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 23:37 UTC (permalink / raw)
To: Ben Whitten, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org, Xue Liu, Sebastian Heß
In-Reply-To: <BY1PR02MB111463339FBF342834170C99E7260@BY1PR02MB1114.namprd02.prod.outlook.com>
+ Xue Liu + Sebastian
Am 08.08.2018 um 17:52 schrieb Ben Whitten:
>> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
>> register, bit-fields, and helpers for regmap
>>
>> 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?
>
> I split the conversion function by function but we can probably go
> further if you think it helpful.
That split feels wrong...
> Is it more the addition of the replacement register defines that you
> would like to correlate with what's being removed, so you can see
> in one patch that this register has the same page and the same
> address in the new system?
I am looking for patches that are trivial to review. One aspect only.
So I would much rather get a large patch with a consistent series of
-my_read
+your_read
-my_write
+your_write
that's quick to review than lots of different refactorings mixed into
one patch, grouped by their file location.
So I am suggesting that if, for example, you want to pass fw to helpers,
which looks like a great idea, that should be a small patch of its own,
at the very beginning of your series. (git rebase -i is your friend.)
Converting to regmap_read/write I imagine to be a trivial
search-and-replace type refactoring, leaving my |= and &= operations in
place, to minimize the diff and avoid it mis-detecting the patch context.
Without caching I'd expect regmap to work up to here - if it doesn't,
then we can't apply it to my tree and need to prioritize other cleanups
while we review/debug further.
Once all registers use regmap successfully, we can optimize that code by
introducing regmap fields. This could be split by location, if desired.
Finally in the end you can introduce more registers and fields for
future use.
Does that make sense now?
> The problem I face is that these conversions are almost blind as
> when I run on my hardware I either oops with the sx1301_read
> or the cal firmware doesn't verify so I can't finish probe. I only
> get a full sx1301 module probe pass on physical hardware when
> I get right to the end of the series where it's all replaced with
> regmap.
If patches don't build or don't work then I can't apply them. Otherwise
the 0-day bots will spam us with error reports, as you've seen before.
BTW we'll need this regmap conversion for the picoGW_hal, so once we
have a working SPI regmap driver, we'll need to split out the SPI bits,
similar to sx125x.
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
* [PATCH mlx5-next 5/6] net/mlx5: Unexport functions that need not be exported
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Eli Cohen, Saeed Mahameed
In-Reply-To: <20180808232353.15514-1-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
mlx5_query_vport_state() and mlx5_modify_vport_admin_state() are used
only from within mlx5_core - unexport them.
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 7ec85747c450..702e235962aa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -62,7 +62,6 @@ u8 mlx5_query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport)
return MLX5_GET(query_vport_state_out, out, state);
}
-EXPORT_SYMBOL_GPL(mlx5_query_vport_state);
int mlx5_modify_vport_admin_state(struct mlx5_core_dev *mdev, u8 opmod,
u16 vport, u8 state)
@@ -80,7 +79,6 @@ int mlx5_modify_vport_admin_state(struct mlx5_core_dev *mdev, u8 opmod,
return mlx5_cmd_exec(mdev, in, sizeof(in), out, sizeof(out));
}
-EXPORT_SYMBOL_GPL(mlx5_modify_vport_admin_state);
static int mlx5_query_nic_vport_context(struct mlx5_core_dev *mdev, u16 vport,
u32 *out, int outlen)
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 6/6] net/mlx5: Reduce command polling interval
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Eli Cohen, Saeed Mahameed
In-Reply-To: <20180808232353.15514-1-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
Use cond_resched() instead of usleep_range() to decrease the time
between polling attempts thus reducing overall driver load time.
Below is a comparison before and after the change, of loading eight
virtual functions.
Before:
real 0m8.785s
user 0m0.093s
sys 0m0.090s
After:
real 0m5.730s
user 0m0.097s
sys 0m0.087s
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index 041c18faea46..fac5dd04578c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -211,7 +211,7 @@ static void poll_timeout(struct mlx5_cmd_work_ent *ent)
ent->ret = 0;
return;
}
- usleep_range(5000, 10000);
+ cond_resched();
} while (time_before(jiffies, poll_end));
ent->ret = -ETIMEDOUT;
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 4/6] net/mlx5: Remove unused mlx5_query_vport_admin_state
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Eli Cohen, Saeed Mahameed
In-Reply-To: <20180808232353.15514-1-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
mlx5_query_vport_admin_state() is not used anywhere. Remove it.
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 10 ----------
include/linux/mlx5/vport.h | 2 --
2 files changed, 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 719cecb182c6..7ec85747c450 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -64,16 +64,6 @@ u8 mlx5_query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport)
}
EXPORT_SYMBOL_GPL(mlx5_query_vport_state);
-u8 mlx5_query_vport_admin_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport)
-{
- u32 out[MLX5_ST_SZ_DW(query_vport_state_out)] = {0};
-
- _mlx5_query_vport_state(mdev, opmod, vport, out, sizeof(out));
-
- return MLX5_GET(query_vport_state_out, out, admin_state);
-}
-EXPORT_SYMBOL_GPL(mlx5_query_vport_admin_state);
-
int mlx5_modify_vport_admin_state(struct mlx5_core_dev *mdev, u8 opmod,
u16 vport, u8 state)
{
diff --git a/include/linux/mlx5/vport.h b/include/linux/mlx5/vport.h
index 9208cb8809ac..7e7c6dfcfb09 100644
--- a/include/linux/mlx5/vport.h
+++ b/include/linux/mlx5/vport.h
@@ -43,8 +43,6 @@ enum {
};
u8 mlx5_query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport);
-u8 mlx5_query_vport_admin_state(struct mlx5_core_dev *mdev, u8 opmod,
- u16 vport);
int mlx5_modify_vport_admin_state(struct mlx5_core_dev *mdev, u8 opmod,
u16 vport, u8 state);
int mlx5_query_nic_vport_mac_address(struct mlx5_core_dev *mdev,
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 2/6] net/mlx5: Rename modify/query_vport state related enums
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Eran Ben Elisha, Saeed Mahameed
In-Reply-To: <20180808232353.15514-1-saeedm@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Modify and query vport state commands share the same admin_state and
op_mod values, rename the enums to fit them both.
In addition, remove the esw prefix from the admin state enum as this
also applied for vnic.
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 12 ++++++------
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++++----
.../net/ethernet/mellanox/mlx5/core/en_selftest.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 10 +++++-----
include/linux/mlx5/device.h | 6 +++---
include/linux/mlx5/mlx5_ifc.h | 4 ++--
6 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 56c1b6f5593e..4708b82e1695 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -222,7 +222,7 @@ static void mlx5e_update_carrier(struct mlx5e_priv *priv)
u8 port_state;
port_state = mlx5_query_vport_state(mdev,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_VNIC_VPORT,
+ MLX5_VPORT_STATE_OP_MOD_VNIC_VPORT,
0);
if (port_state == VPORT_STATE_UP) {
@@ -3873,9 +3873,9 @@ static int mlx5e_set_vf_rate(struct net_device *dev, int vf, int min_tx_rate,
static int mlx5_vport_link2ifla(u8 esw_link)
{
switch (esw_link) {
- case MLX5_ESW_VPORT_ADMIN_STATE_DOWN:
+ case MLX5_VPORT_ADMIN_STATE_DOWN:
return IFLA_VF_LINK_STATE_DISABLE;
- case MLX5_ESW_VPORT_ADMIN_STATE_UP:
+ case MLX5_VPORT_ADMIN_STATE_UP:
return IFLA_VF_LINK_STATE_ENABLE;
}
return IFLA_VF_LINK_STATE_AUTO;
@@ -3885,11 +3885,11 @@ static int mlx5_ifla_link2vport(u8 ifla_link)
{
switch (ifla_link) {
case IFLA_VF_LINK_STATE_DISABLE:
- return MLX5_ESW_VPORT_ADMIN_STATE_DOWN;
+ return MLX5_VPORT_ADMIN_STATE_DOWN;
case IFLA_VF_LINK_STATE_ENABLE:
- return MLX5_ESW_VPORT_ADMIN_STATE_UP;
+ return MLX5_VPORT_ADMIN_STATE_UP;
}
- return MLX5_ESW_VPORT_ADMIN_STATE_AUTO;
+ return MLX5_VPORT_ADMIN_STATE_AUTO;
}
static int mlx5e_set_vf_link_state(struct net_device *dev, int vf,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 57987f6546e8..ea0fb36dbacf 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -698,8 +698,8 @@ static int mlx5e_rep_open(struct net_device *dev)
goto unlock;
if (!mlx5_modify_vport_admin_state(priv->mdev,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
- rep->vport, MLX5_ESW_VPORT_ADMIN_STATE_UP))
+ MLX5_VPORT_STATE_OP_MOD_ESW_VPORT,
+ rep->vport, MLX5_VPORT_ADMIN_STATE_UP))
netif_carrier_on(dev);
unlock:
@@ -716,8 +716,8 @@ static int mlx5e_rep_close(struct net_device *dev)
mutex_lock(&priv->state_lock);
mlx5_modify_vport_admin_state(priv->mdev,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
- rep->vport, MLX5_ESW_VPORT_ADMIN_STATE_DOWN);
+ MLX5_VPORT_STATE_OP_MOD_ESW_VPORT,
+ rep->vport, MLX5_VPORT_ADMIN_STATE_DOWN);
ret = mlx5e_close_locked(dev);
mutex_unlock(&priv->state_lock);
return ret;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c
index 4d316cc9b008..35ded91203f5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_selftest.c
@@ -74,7 +74,7 @@ static int mlx5e_test_link_state(struct mlx5e_priv *priv)
if (!netif_carrier_ok(priv->netdev))
return 1;
- port_state = mlx5_query_vport_state(priv->mdev, MLX5_QUERY_VPORT_STATE_IN_OP_MOD_VNIC_VPORT, 0);
+ port_state = mlx5_query_vport_state(priv->mdev, MLX5_VPORT_STATE_OP_MOD_VNIC_VPORT, 0);
return port_state == VPORT_STATE_UP ? 0 : 1;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index f63dfbcd29fe..4e5305106695 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1469,7 +1469,7 @@ static void esw_apply_vport_conf(struct mlx5_eswitch *esw,
return;
mlx5_modify_vport_admin_state(esw->dev,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
+ MLX5_VPORT_STATE_OP_MOD_ESW_VPORT,
vport_num,
vport->info.link_state);
mlx5_modify_nic_vport_mac_address(esw->dev, vport_num, vport->info.mac);
@@ -1582,9 +1582,9 @@ static void esw_disable_vport(struct mlx5_eswitch *esw, int vport_num)
esw_vport_disable_qos(esw, vport_num);
if (vport_num && esw->mode == SRIOV_LEGACY) {
mlx5_modify_vport_admin_state(esw->dev,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
+ MLX5_VPORT_STATE_OP_MOD_ESW_VPORT,
vport_num,
- MLX5_ESW_VPORT_ADMIN_STATE_DOWN);
+ MLX5_VPORT_ADMIN_STATE_DOWN);
esw_vport_disable_egress_acl(esw, vport);
esw_vport_disable_ingress_acl(esw, vport);
esw_vport_destroy_drop_counters(vport);
@@ -1738,7 +1738,7 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
struct mlx5_vport *vport = &esw->vports[vport_num];
vport->vport = vport_num;
- vport->info.link_state = MLX5_ESW_VPORT_ADMIN_STATE_AUTO;
+ vport->info.link_state = MLX5_VPORT_ADMIN_STATE_AUTO;
vport->dev = dev;
INIT_WORK(&vport->vport_change_handler,
esw_vport_change_handler);
@@ -1862,7 +1862,7 @@ int mlx5_eswitch_set_vport_state(struct mlx5_eswitch *esw,
evport = &esw->vports[vport];
err = mlx5_modify_vport_admin_state(esw->dev,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT,
+ MLX5_VPORT_STATE_OP_MOD_ESW_VPORT,
vport, link_state);
if (err) {
mlx5_core_warn(esw->dev,
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index 0566c6a94805..4de9ac023e6e 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -939,9 +939,9 @@ enum {
};
enum {
- MLX5_ESW_VPORT_ADMIN_STATE_DOWN = 0x0,
- MLX5_ESW_VPORT_ADMIN_STATE_UP = 0x1,
- MLX5_ESW_VPORT_ADMIN_STATE_AUTO = 0x2,
+ MLX5_VPORT_ADMIN_STATE_DOWN = 0x0,
+ MLX5_VPORT_ADMIN_STATE_UP = 0x1,
+ MLX5_VPORT_ADMIN_STATE_AUTO = 0x2,
};
enum {
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 2b0b6a8550bf..b2d9f0ecb897 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -3763,8 +3763,8 @@ struct mlx5_ifc_query_vport_state_out_bits {
};
enum {
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_VNIC_VPORT = 0x0,
- MLX5_QUERY_VPORT_STATE_IN_OP_MOD_ESW_VPORT = 0x1,
+ MLX5_VPORT_STATE_OP_MOD_VNIC_VPORT = 0x0,
+ MLX5_VPORT_STATE_OP_MOD_ESW_VPORT = 0x1,
};
struct mlx5_ifc_query_vport_state_in_bits {
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 3/6] net/mlx5: E-Switch, Remove unused argument when creating legacy FDB
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Eli Cohen, Saeed Mahameed
In-Reply-To: <20180808232353.15514-1-saeedm@mellanox.com>
From: Eli Cohen <eli@mellanox.com>
Remove unused nvports argument.
Signed-off-by: Eli Cohen <eli@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 4e5305106695..d9ba5a7452c3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -246,7 +246,7 @@ esw_fdb_set_vport_promisc_rule(struct mlx5_eswitch *esw, u32 vport)
return __esw_fdb_set_vport_rule(esw, vport, true, mac_c, mac_v);
}
-static int esw_create_legacy_fdb_table(struct mlx5_eswitch *esw, int nvports)
+static int esw_create_legacy_fdb_table(struct mlx5_eswitch *esw)
{
int inlen = MLX5_ST_SZ_BYTES(create_flow_group_in);
struct mlx5_flow_table_attr ft_attr = {};
@@ -1620,7 +1620,7 @@ int mlx5_eswitch_enable_sriov(struct mlx5_eswitch *esw, int nvfs, int mode)
esw->mode = mode;
if (mode == SRIOV_LEGACY) {
- err = esw_create_legacy_fdb_table(esw, nvfs + 1);
+ err = esw_create_legacy_fdb_table(esw);
} else {
mlx5_reload_interface(esw->dev, MLX5_INTERFACE_PROTOCOL_IB);
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 1/6] net/mlx5: Use max_num_eqs for calculation of required MSIX vectors
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Denis Drozdov, Saeed Mahameed
In-Reply-To: <20180808232353.15514-1-saeedm@mellanox.com>
From: Denis Drozdov <denisd@mellanox.com>
New firmware has defined new HCA capability field called "max_num_eqs",
that is the number of available EQs after subtracting reserved FW EQs.
Before this capability the FW reported the EQ number in "log_max_eqs",
the reported value also contained FW reserved EQs, but the driver might
be failing to load on 320 cpus systems due to the fact that FW
reserved EQs were not available to the driver.
Now the driver has to obtain max_num_eqs value from new FW to get real
number of EQs available.
Signed-off-by: Denis Drozdov <denisd@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 +++-
include/linux/mlx5/mlx5_ifc.h | 5 ++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index f9b950e1bd85..ad958b9b1b9b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -321,7 +321,9 @@ static int mlx5_alloc_irq_vectors(struct mlx5_core_dev *dev)
{
struct mlx5_priv *priv = &dev->priv;
struct mlx5_eq_table *table = &priv->eq_table;
- int num_eqs = 1 << MLX5_CAP_GEN(dev, log_max_eq);
+ int num_eqs = MLX5_CAP_GEN(dev, max_num_eqs) ?
+ MLX5_CAP_GEN(dev, max_num_eqs) :
+ 1 << MLX5_CAP_GEN(dev, log_max_eq);
int nvec;
int err;
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index c14b81559505..2b0b6a8550bf 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -1131,7 +1131,10 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 general_obj_types[0x40];
- u8 reserved_at_440[0x40];
+ u8 reserved_at_440[0x20];
+
+ u8 reserved_at_460[0x10];
+ u8 max_num_eqs[0x10];
u8 reserved_at_480[0x3];
u8 log_max_l2_table[0x5];
--
2.17.0
^ permalink raw reply related
* [PATCH mlx5-next 0/6] Mellanox, mlx5 next updates 2018-08-09
From: Saeed Mahameed @ 2018-08-08 23:23 UTC (permalink / raw)
To: netdev, linux-rdma
Cc: Leon Romanovsky, Jason Gunthorpe, David S. Miller, Doug Ledford,
Saeed Mahameed
Hi All,
This series includes mlx5 core driver updates and mostly simple
cleanups.
>From Denis: Use max #EQs reported by firmware to request MSIX vectors.
>From Eli: Trivial cleanups, unused arguments/functions and reduce
command polling interval when command interface is in polling mode.
>From Eran: Rename vport state enums, to better reflect their actual
usage.
Thanks,
Saeed.
---
Denis Drozdov (1):
net/mlx5: Use max_num_eqs for calculation of required MSIX vectors
Eli Cohen (4):
net/mlx5: E-Switch, Remove unused argument when creating legacy FDB
net/mlx5: Remove unused mlx5_query_vport_admin_state
net/mlx5: Unexport functions that need not be exported
net/mlx5: Reduce command polling interval
Eran Ben Elisha (1):
net/mlx5: Rename modify/query_vport state related enums
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 12 ++++++------
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 8 ++++----
.../net/ethernet/mellanox/mlx5/core/en_selftest.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 14 +++++++-------
drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 +++-
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 12 ------------
include/linux/mlx5/device.h | 6 +++---
include/linux/mlx5/mlx5_ifc.h | 9 ++++++---
include/linux/mlx5/vport.h | 2 --
10 files changed, 31 insertions(+), 40 deletions(-)
--
2.17.0
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/r8152: change rtl8152_system_suspend to be void function
From: zhong jiang @ 2018-08-09 1:42 UTC (permalink / raw)
To: davem, edumazet; +Cc: netdev, linux-kernel
In-Reply-To: <1533738407-10495-1-git-send-email-zhongjiang@huawei.com>
Igore the patch, will repost, Thanks
On 2018/8/8 22:26, zhong jiang wrote:
> 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);
>
^ permalink raw reply
* [PATCH] drivers/net/usb/r8152: remove the unneeded variable "ret" in rtl8152_system_suspend
From: zhong jiang @ 2018-08-09 1:39 UTC (permalink / raw)
To: davem, gustavo; +Cc: netdev, linux-kernel
rtl8152_system_suspend defines the variable "ret", but it is not modified
after initialization. So just remove it.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/usb/r8152.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 124211a..9774270 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4415,7 +4415,6 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
static int rtl8152_system_suspend(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
- int ret = 0;
netif_device_detach(netdev);
@@ -4430,7 +4429,7 @@ static int rtl8152_system_suspend(struct r8152 *tp)
napi_enable(napi);
}
- return ret;
+ return 0;
}
static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH net-next] rds: avoid lock hierarchy violation between m_rs_lock and rs_recv_lock
From: Santosh Shilimkar @ 2018-08-08 22:37 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: netdev, davem, rds-devel
In-Reply-To: <20180808221811.GA16895@oracle.com>
On 8/8/2018 3:18 PM, Sowmini Varadhan wrote:
> On (08/08/18 14:51), Santosh Shilimkar wrote:
>> This bug doesn't make sense since two different transports are using
>> same socket (Loop and rds_tcp) and running together.
>> For same transport, such race can't happen with MSG_ON_SOCK flag.
>> CPU1-> rds_loop_inc_free
>> CPU0 -> rds_tcp_cork ...
>>
>
> The test is just reporting a lock hierarchy violation
>
> As far as I can tell, this wasn't an actual deadlock that happened
> because as you point out, either a socket has the rds_tcp transport
> or the rds_loop transport, so this particular pair of stack traces
> would not happen with the code as it exists today.
>
Exactly.
> but there is a valid lock hierachy violation here, and
> imho it's a good idea to get that cleaned up.
>
The lock hierarchy violation is protected for the same transport.
I don't see this violation possible for legitimate use and hence
the comment. If we start supporting two different transport on
same socket then we have many more cases to fix and as such lock
violation will be just one of those.
Loop transport seems to keep throwing surprises. Need to
confirm but looks like it can co-exist with another transport
on same socket if those traces to be believed. If its the case,
then definitely that need to be plugged.
Regards,
Santosh
^ permalink raw reply
* [PATCH net 2/2] net/mlx5e: Cleanup of dcbnl related fields
From: Saeed Mahameed @ 2018-08-08 22:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Huy Nguyen, Yuval Shaia, Saeed Mahameed
In-Reply-To: <20180808224808.12600-1-saeedm@mellanox.com>
From: Huy Nguyen <huyn@mellanox.com>
Remove unused netdev_registered_init/remove in en.h
Return ENOSUPPORT if the check MLX5_DSCP_SUPPORTED fails.
Remove extra white space
Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
Signed-off-by: Huy Nguyen <huyn@mellanox.com>
Cc: Yuval Shaia <yuval.shaia@oracle.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 --
.../ethernet/mellanox/mlx5/core/en_dcbnl.c | 30 +++++++------------
2 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index eb9eb7aa953a..405236cf0b04 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -858,8 +858,6 @@ struct mlx5e_profile {
mlx5e_fp_handle_rx_cqe handle_rx_cqe;
mlx5e_fp_handle_rx_cqe handle_rx_cqe_mpwqe;
} rx_handlers;
- void (*netdev_registered_init)(struct mlx5e_priv *priv);
- void (*netdev_registered_remove)(struct mlx5e_priv *priv);
int max_tc;
};
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
index e33afa8d2417..722998d68564 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -443,16 +443,12 @@ static int mlx5e_dcbnl_ieee_setapp(struct net_device *dev, struct dcb_app *app)
bool is_new;
int err;
- if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
- return -EINVAL;
-
- if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
- return -EINVAL;
-
- if (!MLX5_DSCP_SUPPORTED(priv->mdev))
- return -EINVAL;
+ if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
+ !MLX5_DSCP_SUPPORTED(priv->mdev))
+ return -EOPNOTSUPP;
- if (app->protocol >= MLX5E_MAX_DSCP)
+ if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
+ (app->protocol >= MLX5E_MAX_DSCP))
return -EINVAL;
/* Save the old entry info */
@@ -500,16 +496,12 @@ static int mlx5e_dcbnl_ieee_delapp(struct net_device *dev, struct dcb_app *app)
struct mlx5e_priv *priv = netdev_priv(dev);
int err;
- if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
- return -EINVAL;
-
- if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
- return -EINVAL;
-
- if (!MLX5_DSCP_SUPPORTED(priv->mdev))
- return -EINVAL;
+ if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
+ !MLX5_DSCP_SUPPORTED(priv->mdev))
+ return -EOPNOTSUPP;
- if (app->protocol >= MLX5E_MAX_DSCP)
+ if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
+ (app->protocol >= MLX5E_MAX_DSCP))
return -EINVAL;
/* Skip if no dscp app entry */
@@ -1146,7 +1138,7 @@ static int mlx5e_set_trust_state(struct mlx5e_priv *priv, u8 trust_state)
{
int err;
- err = mlx5_set_trust_state(priv->mdev, trust_state);
+ err = mlx5_set_trust_state(priv->mdev, trust_state);
if (err)
return err;
priv->dcbx_dp.trust_state = trust_state;
--
2.17.0
^ permalink raw reply related
* [PATCH net 1/2] net/mlx5e: Properly check if hairpin is possible between two functions
From: Saeed Mahameed @ 2018-08-08 22:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Or Gerlitz, Saeed Mahameed
In-Reply-To: <20180808224808.12600-1-saeedm@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
The current check relies on function BDF addresses and can get
us wrong e.g when two VFs are assigned into a VM and the PCI
v-address is set by the hypervisor.
Fixes: 5c65c564c962 ('net/mlx5e: Support offloading TC NIC hairpin flows')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reported-by: Alaa Hleihel <alaa@mellanox.com>
Tested-by: Alaa Hleihel <alaa@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 3a2c4e548226..dfbcda0d0e08 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1970,15 +1970,15 @@ static bool actions_match_supported(struct mlx5e_priv *priv,
static bool same_hw_devs(struct mlx5e_priv *priv, struct mlx5e_priv *peer_priv)
{
struct mlx5_core_dev *fmdev, *pmdev;
- u16 func_id, peer_id;
+ u64 fsystem_guid, psystem_guid;
fmdev = priv->mdev;
pmdev = peer_priv->mdev;
- func_id = (u16)((fmdev->pdev->bus->number << 8) | PCI_SLOT(fmdev->pdev->devfn));
- peer_id = (u16)((pmdev->pdev->bus->number << 8) | PCI_SLOT(pmdev->pdev->devfn));
+ mlx5_query_nic_vport_system_image_guid(fmdev, &fsystem_guid);
+ mlx5_query_nic_vport_system_image_guid(pmdev, &psystem_guid);
- return (func_id == peer_id);
+ return (fsystem_guid == psystem_guid);
}
static int parse_tc_nic_actions(struct mlx5e_priv *priv, struct tcf_exts *exts,
--
2.17.0
^ permalink raw reply related
* [PATCH net 0/2] Mellanox, mlx5e fixes 2018-08-07
From: Saeed Mahameed @ 2018-08-08 22:48 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed
Hi Dave,
I know it is late into 4.18 release, and this is why I am submitting
only two mlx5e ethernet fixes.
The first one from Or, is needed for -stable and it fixes hairpin
for "same device" check.
The second fix is a non risk fix from Huy which cleans up and improves
error return value reporting for dcbnl_ieee_setapp.
For -stable v4.16
- net/mlx5e: Properly check if hairpin is possible between two functions
Thanks,
Saeed.
---
Huy Nguyen (1):
net/mlx5e: Cleanup of dcbnl related fields
Or Gerlitz (1):
net/mlx5e: Properly check if hairpin is possible between two functions
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 --
.../ethernet/mellanox/mlx5/core/en_dcbnl.c | 30 +++++++------------
.../net/ethernet/mellanox/mlx5/core/en_tc.c | 8 ++---
3 files changed, 15 insertions(+), 25 deletions(-)
--
2.17.0
^ permalink raw reply
* Question about inode_permission() check in unix_find_other()
From: TongZhang @ 2018-08-09 1:09 UTC (permalink / raw)
To: davem, garsilva, matthew, willemb, netdev, linux-kernel
Cc: wenbo.s, ahmedmoneeb
Hi Networking Subsystem Maintainers,
I have a quick question about inode_permission() check in unix_find_other(),
I was doing a code review on net/unix/af_unix.c and found out that the inode_permission() check is confusing here.
Since the unix socket is presented as a file, and will be permission checked by VFS when user open it,
why do we still need the inode_permission() check in unix_find_other() anyway?
Thank you,
- Tong
^ permalink raw reply
* Re: [RFC net-next 00/15] net: A socket API for LoRa
From: Andreas Färber @ 2018-08-08 22:42 UTC (permalink / raw)
To: Alan Cox
Cc: Jian-Hong Pan, netdev, linux-arm-kernel, linux-kernel, Jiri Pirko,
Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, contact, Ben Whitten, Brian Ray, lora,
Alexander Graf
In-Reply-To: <20180808213640.10a1d76f@alans-desktop>
Am 08.08.2018 um 22:36 schrieb Alan Cox:
> On Sun, 5 Aug 2018 02:11:25 +0200
> Andreas Färber <afaerber@suse.de> wrote:
>> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan:
>>> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>:
>> LoRa radio channels being half-duplex, we'd need to stop receiving in
>> ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU.
>> Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet.
>
> Why - the signal is still floating around in the air, you can't unhear it
> at the antenna.
Why what? :)
> If a given piece of hardware needs to flip between RX
> and TX mode then it should be handled by that driver.
Yes, and we are talking about that concrete sx1276 driver here, whose
chipset has a state machine that only allows either rx or tx and also
has standby and sleep modes with differing levels of data retention.
The sx1301 is a different beast (and driver) and may allow both.
In any case, the ndo_start_xmit hook is in each device driver. But the
recvmsg hook I mentioned is at protocol layer, which exactly is the
layering problem I see.
> (Some ancient ethernet cards do this btw.. they can't listen and transmit
> at the same time)
So when do they start receiving?
The issue here was that my original description, which you appear to
have cut, suggested a continuous listen mode, interrupted by transmit.
Jian-Hong didn't like that, with reference to the LoRaWAN spec that
supposedly asks for only being in receive mode when expecting a message,
likely to save on battery. So the question is, could we cleanly
implement receiving only when the user asks us to, or is that a no-go?
>>> - We can have a pre-defined table according to LoRaWAN Regional Parameters.
>>> - Device driver declares the hardware's capability, for example
>>> frequency, TX power. And then registers as a LoRaWAN compatible
>>> device.
>>
>> That sounds like a layering violation. We rather need to expose all
>> these tunable parameters individually at the LoRa layer, allowing the
>> LoRaWAN layer to configure them as it pleases. Not the other direction.
>> That still leaves my above question 4) open of how to implement each.
>
> Wifi already has the general policy database for the various existing
> protocols. Please take a look at the CRDA agent and how it hooks into
> wireless.It might need to some tweaking but it would be odd to have
> different configuration schemes for different wifi protocols.
CRDA/wireless-regdb had been brought up and I've been pointed to nl80211
and nl802154, which I've tried to make sense of for my initial nllora.
Admittedly with limited success, as that code is slightly complex.
We also seemed to have consensus here that we _should_ be reusing
wireless-regdb but would need to extend it 1.) with sub-GHz frequency
bands and 2.) duty-cycle limits for some of those bands. No maintainer
commented on that so far. Thus I am working in tiny steps on providing
netlink-layer commands in nllora that can dispatch the individual radio
settings to drivers, which then upper layers can instrument as needed.
And making my very first steps with netlink here, it appeared as if each
technology has its own enums of commands and attributes, so I don't see
how to reuse anything from Wifi here apart from some design inspiration.
>> The use case I have in mind is this: User A opens a LoRaWAN socket and
>> using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters
>> and LoRaWAN Sync Word need to be applied.
>> User B then opens a pure LoRa socket and transmits a packet P1' with
>> different Sync Word, SF, BW, CR, etc.
>> Afterwards user A wants to send another packet P2 via LoRaWAN - this
>> needs to use the same LoRaWAN settings as before, not those used for
>> LoRa in between. Therefore I was thinking about socket-level options, as
>> netlink operations would be device-wide, with undesired side-effects.
>
> Agreed
>
>> Obviously in that scenario not both users can receive at the same time.
>
> That's a hardware question. Imagine a software defined radio. If your
> limitation wouldn't exist in a pure software defined radio then it's
> almost certainly a device level detal.
An SDR would not be using this sx1276 device driver, I imagine.
In fact I would expect an SDR device not to be in drivers/net/lora/ at
all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs
and just do the right thing for them depending on their type...
>> interface but cleanly distinguished as ETH_P_GFSK or something.
>> For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module.
>
> Agreed if you can flip per packet.
The SX127x can - it might involve delays of course.
The SX130x doesn't even need to flip for sending AFAICT, it's just
metadata after the payload in the FIFO.
>> The next question arising is how the user would create such an skb. Just
>> like I was hesitant about PF_LORAWAN originally, I'd like to avoid
>> polluting the PF_ number space for each of these. Maybe have one PF_FSK
>> as equivalent to PF_LORA and then have either a socket option or
>> sockaddr field to select the modulation variants? Not sure how exactly
>> those others differ from each other, that's why I tried to postpone the
>> FSK topic and to focus on LoRa first - b) below.
>>
>> At this point we could also argue whether we need a PF_LORA at all or
>> rather just some generic PF_RADIO with lots of options stored in its
>> sockaddr.
>
> What matters most is mux/demux.
>
> If you've got something listening to data but without the structure
> needed to identify multiple listeners and split out the data meaningfully
> to those listeners according to parts of the packet then you've got no
> reason to make it a protocol just use SOCK_PACKET and if need be BPF.
Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some
PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of
SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's
some generic implementation that we can reuse and scratch mine?
> The reason we have a socket layer not /dev/ethernet0 is that it's
> meaningful to divide messages up into flows, and to partition those flows
> securely amongst multiple consumers/generators.
For me the distinction is that a /dev/whatever0 would seem more suited
for a stream of data to read/write, whereas sockets give us a bounded
skb for packets at device driver level.
These PHYs all broadcast something over the antenna when sending, with
any addressing of listeners or senders being optional and MAC-specific,
apart from the LoRa/FSK SyncWord as well as the various frequency etc.
settings that determine what the receiver listens for.
None of these PHYs define any mechanism like EtherType through which to
identify upper-layer protocols.
So in a way, listening is always in a promiscuous mode, and I guess we
would need to try to parse each incoming packet as e.g. a LoRaWAN packet
and just give up if it's too short or checksums don't match. Only at the
layer of LoRaWAN and competing proprietary or custom protocols can we
split received packets out to individual listeners.
Does that give us any further clues for the design discussion here?
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-next] rds: avoid lock hierarchy violation between m_rs_lock and rs_recv_lock
From: Sowmini Varadhan @ 2018-08-08 22:18 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: netdev, davem, rds-devel
In-Reply-To: <392e9286-e98c-1dbe-d598-9afca1818cf6@oracle.com>
On (08/08/18 14:51), Santosh Shilimkar wrote:
> This bug doesn't make sense since two different transports are using
> same socket (Loop and rds_tcp) and running together.
> For same transport, such race can't happen with MSG_ON_SOCK flag.
> CPU1-> rds_loop_inc_free
> CPU0 -> rds_tcp_cork ...
>
The test is just reporting a lock hierarchy violation
As far as I can tell, this wasn't an actual deadlock that happened
because as you point out, either a socket has the rds_tcp transport
or the rds_loop transport, so this particular pair of stack traces
would not happen with the code as it exists today.
but there is a valid lock hierachy violation here, and
imho it's a good idea to get that cleaned up.
It also avoids needlessly holding down the rs_recv_lock
when doing an rds_inc_put.
--Sowmini
^ permalink raw reply
* Re: [PATCH] net: phy: sftp: print debug message with text, not numbers
From: Russell King - ARM Linux @ 2018-08-08 22:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <1533754452-1633-1-git-send-email-andrew@lunn.ch>
You might want to fix the subject line.
On Wed, Aug 08, 2018 at 08:54:12PM +0200, Andrew Lunn wrote:
> Convert the state numbers, device state, etc from numbers to strings
> when printing debug messages.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/phy/sfp.c | 76 ++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index 5661226cf75b..4637d980310e 100644
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -60,6 +60,69 @@ enum {
> SFP_S_TX_DISABLE,
> };
>
> +static const char * const mod_state_strings[] = {
> + [SFP_MOD_EMPTY] = "empty",
> + [SFP_MOD_PROBE] = "probe",
> + [SFP_MOD_HPOWER] = "hpower",
> + [SFP_MOD_PRESENT] = "present",
> + [SFP_MOD_ERROR] = "error",
> +};
> +
> +static const char *mod_state_to_str(unsigned short mod_state)
> +{
> + if (mod_state >= ARRAY_SIZE(mod_state_strings))
> + return "Unknown module state";
> + return mod_state_strings[mod_state];
> +}
> +
> +static const char * const dev_state_strings[] = {
> + [SFP_DEV_DOWN] = "down",
> + [SFP_DEV_UP] = "up",
> +};
> +
> +static const char *dev_state_to_str(unsigned short dev_state)
> +{
> + if (dev_state >= ARRAY_SIZE(dev_state_strings))
> + return "Unknown device state";
> + return dev_state_strings[dev_state];
> +}
> +
> +static const char * const event_strings[] = {
> + [SFP_E_INSERT] = "insert",
> + [SFP_E_REMOVE] = "remove",
> + [SFP_E_DEV_DOWN] = "dev_down",
> + [SFP_E_DEV_UP] = "dev_up",
> + [SFP_E_TX_FAULT] = "tx_fault",
> + [SFP_E_TX_CLEAR] = "tx_clear",
> + [SFP_E_LOS_HIGH] = "los_high",
> + [SFP_E_LOS_LOW] = "los_low",
> + [SFP_E_TIMEOUT] = "timeout",
> +};
> +
> +static const char *event_to_str(unsigned short event)
> +{
> + if (event >= ARRAY_SIZE(event_strings))
> + return "Unknown event";
> + return event_strings[event];
> +}
> +
> +static const char * const sm_state_strings[] = {
> + [SFP_S_DOWN] = "down",
> + [SFP_S_INIT] = "init",
> + [SFP_S_WAIT_LOS] = "wait_los",
> + [SFP_S_LINK_UP] = "link_up",
> + [SFP_S_TX_FAULT] = "tx_fault",
> + [SFP_S_REINIT] = "reinit",
> + [SFP_S_TX_DISABLE] = "rx_disable",
> +};
> +
> +static const char *sm_state_to_str(unsigned short sm_state)
> +{
> + if (sm_state >= ARRAY_SIZE(sm_state_strings))
> + return "Unknown state";
> + return sm_state_strings[sm_state];
> +}
> +
> static const char *gpio_of_names[] = {
> "mod-def0",
> "los",
> @@ -1388,8 +1451,11 @@ static void sfp_sm_event(struct sfp *sfp, unsigned int event)
> {
> mutex_lock(&sfp->sm_mutex);
>
> - dev_dbg(sfp->dev, "SM: enter %u:%u:%u event %u\n",
> - sfp->sm_mod_state, sfp->sm_dev_state, sfp->sm_state, event);
> + dev_dbg(sfp->dev, "SM: enter %s:%s:%s event %s\n",
> + mod_state_to_str(sfp->sm_mod_state),
> + dev_state_to_str(sfp->sm_dev_state),
> + sm_state_to_str(sfp->sm_state),
> + event_to_str(event));
>
> /* This state machine tracks the insert/remove state of
> * the module, and handles probing the on-board EEPROM.
> @@ -1520,8 +1586,10 @@ static void sfp_sm_event(struct sfp *sfp, unsigned int event)
> break;
> }
>
> - dev_dbg(sfp->dev, "SM: exit %u:%u:%u\n",
> - sfp->sm_mod_state, sfp->sm_dev_state, sfp->sm_state);
> + dev_dbg(sfp->dev, "SM: exit %s:%s:%s\n",
> + mod_state_to_str(sfp->sm_mod_state),
> + dev_state_to_str(sfp->sm_dev_state),
> + sm_state_to_str(sfp->sm_state));
>
> mutex_unlock(&sfp->sm_mutex);
> }
> --
> 2.18.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ 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