* [PATCH] erspan: remove the incorrect mtu limit for erspan
From: Haishuang Yan @ 2019-09-27 6:58 UTC (permalink / raw)
To: David S. Miller; +Cc: William Tu, netdev, linux-kernel, Haishuang Yan
erspan driver calls ether_setup(), after commit 61e84623ace3
("net: centralize net_device min/max MTU checking"), the range
of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
It causes the dev mtu of the erspan device to not be greater
than 1500, this limit value is not correct for ipgre tap device.
Tested:
Before patch:
# ip link set erspan0 mtu 1600
Error: mtu greater than device maximum.
After patch:
# ip link set erspan0 mtu 1600
# ip -d link show erspan0
21: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1600 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 0
Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv4/ip_gre.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index a53a543..52690bb 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1446,6 +1446,7 @@ static void erspan_setup(struct net_device *dev)
struct ip_tunnel *t = netdev_priv(dev);
ether_setup(dev);
+ dev->max_mtu = 0;
dev->netdev_ops = &erspan_netdev_ops;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
--
1.8.3.1
^ permalink raw reply related
* Re: pull-request: wireless-drivers 2019-09-26
From: David Miller @ 2019-09-27 7:08 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <8736gj5i6a.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 26 Sep 2019 15:57:33 +0300
> here's a pull request to net tree for v5.4. Please let me know if there
> are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH] vhost: introduce mdev based hardware backend
From: Jason Wang @ 2019-09-27 7:14 UTC (permalink / raw)
To: Tiwei Bie
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang,
lingshan.zhu
In-Reply-To: <20190927045438.GA17152@___>
On 2019/9/27 下午12:54, Tiwei Bie wrote:
>>> +
>>> + /*
>>> + * In vhost-mdev, userspace should pass ring addresses
>>> + * in guest physical addresses when IOMMU is disabled or
>>> + * IOVAs when IOMMU is enabled.
>>> + */
>> A question here, consider we're using noiommu mode. If guest physical
>> address is passed here, how can a device use that?
>>
>> I believe you meant "host physical address" here? And it also have the
>> implication that the HPA should be continuous (e.g using hugetlbfs).
> The comment is talking about the virtual IOMMU (i.e. iotlb in vhost).
> It should be rephrased to cover the noiommu case as well. Thanks for
> spotting this.
So the question still, if GPA is passed how can it be used by the
virtio-mdev device?
Thanks
^ permalink raw reply
* Re: [PATCH] vhost: introduce mdev based hardware backend
From: Jason Wang @ 2019-09-27 7:17 UTC (permalink / raw)
To: Tiwei Bie
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang,
lingshan.zhu
In-Reply-To: <20190927045438.GA17152@___>
On 2019/9/27 下午12:54, Tiwei Bie wrote:
>> The name could be confusing, get_queue_max() is to get the maximum number of
>> entries for a virtqueue supported by this device.
> OK. It might be better to rename it to something like:
>
> get_vq_num_max()
>
> which is more consistent with the set_vq_num().
>
Yes, will do in next version.
Thanks
^ permalink raw reply
* Re: Are BPF tail calls only supposed to work with pinned maps?
From: Toke Høiland-Jørgensen @ 2019-09-27 7:27 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, bpf
In-Reply-To: <20190926181457.GA6818@pc-63.home>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On Thu, Sep 26, 2019 at 03:12:30PM +0200, Toke Høiland-Jørgensen wrote:
>> Daniel Borkmann <daniel@iogearbox.net> writes:
>> > On Thu, Sep 26, 2019 at 01:23:38PM +0200, Toke Høiland-Jørgensen wrote:
>> > [...]
>> >> While working on a prototype of the XDP chain call feature, I ran into
>> >> some strange behaviour with tail calls: If I create a userspace program
>> >> that loads two XDP programs, one of which tail calls the other, the tail
>> >> call map would appear to be empty even though the userspace program
>> >> populates it as part of the program loading.
>> >>
>> >> I eventually tracked this down to this commit:
>> >> c9da161c6517 ("bpf: fix clearing on persistent program array maps")
>> >
>> > Correct.
>> >
>> >> Which clears PROG_ARRAY maps whenever the last uref to it disappears
>> >> (which it does when my loader exits after attaching the XDP program).
>> >>
>> >> This effectively means that tail calls only work if the PROG_ARRAY map
>> >> is pinned (or the process creating it keeps running). And as far as I
>> >> can tell, the inner_map reference in bpf_map_fd_get_ptr() doesn't bump
>> >> the uref either, so presumably if one were to create a map-in-map
>> >> construct with tail call pointer in the inner map(s), each inner map
>> >> would also need to be pinned (haven't tested this case)?
>> >
>> > There is no map in map support for tail calls today.
>>
>> Not directly, but can't a program do:
>>
>> tail_call_map = bpf_map_lookup(outer_map, key);
>> bpf_tail_call(tail_call_map, idx);
>
> Nope, that is what I meant, bpf_map_meta_alloc() will bail out in that
> case.
Oohhh, right. Seems I reversed that if statement in my head. Silly me,
thanks for clarifying!
>> >> Is this really how things are supposed to work? From an XDP use case PoV
>> >> this seems somewhat surprising...
>> >>
>> >> Or am I missing something obvious here?
>> >
>> > The way it was done like this back then was in order to break up cyclic
>> > dependencies as otherwise the programs and maps involved would never get
>> > freed as they reference themselves and live on in the kernel forever
>> > consuming potentially large amount of resources, so orchestration tools
>> > like Cilium typically just pin the maps in bpf fs (like most other maps
>> > it uses and accesses from agent side) in order to up/downgrade the agent
>> > while keeping BPF datapath intact.
>>
>> Right. I can see how the cyclic reference thing gets thorny otherwise.
>> However, the behaviour was somewhat surprising to me; is it documented
>> anywhere?
>
> Haven't updated the BPF guide in a while [0], I don't think I
> documented this detail back then, so right now only in the git log.
> Improvements to the reference guide definitely welcome.
Gotcha. I guess we should add something about tail calls (and chain
calls once we get them) to the XDP tutorial as well...
-Toke
^ permalink raw reply
* [question] About triggering a region snapshot through the devlink cmd
From: Yunsheng Lin @ 2019-09-27 7:40 UTC (permalink / raw)
To: jiri, valex; +Cc: davem, netdev@vger.kernel.org, linuxarm@huawei.com
Hi, Jiri & Alex
It seems that a region' snapshot is only created through the
driver when some error is detected, for example:
mlx4_crdump_collect_fw_health() -> devlink_region_snapshot_create()
We want to trigger a region' snapshot creation through devlink
cmd, maybe by adding the "devlink region triger", because we want
to check some hardware register/state when the driver or the hardware
does not detect the error sometimes.
Does about "devlink region triger" make sense?
If yes, is there plan to implement it? or any suggestion to implement
it?
^ permalink raw reply
* [PATCH net 7/8] net: stmmac: xgmac: Disable the Timestamp interrupt by default
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
We don't use it anyway as XGMAC only supports polling for timestamp (in
current SW implementation). This greatly reduces the system load by
reducing the number of interrupts.
Fixes: 2142754f8b9c ("net: stmmac: Add MAC related callbacks for XGMAC2")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index f7eb06f8fb37..99037386080a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -84,7 +84,7 @@
#define XGMAC_TSIE BIT(12)
#define XGMAC_LPIIE BIT(5)
#define XGMAC_PMTIE BIT(4)
-#define XGMAC_INT_DEFAULT_EN (XGMAC_LPIIE | XGMAC_PMTIE | XGMAC_TSIE)
+#define XGMAC_INT_DEFAULT_EN (XGMAC_LPIIE | XGMAC_PMTIE)
#define XGMAC_Qx_TX_FLOW_CTRL(x) (0x00000070 + (x) * 4)
#define XGMAC_PT GENMASK(31, 16)
#define XGMAC_PT_SHIFT 16
--
2.7.4
^ permalink raw reply related
* [PATCH net 5/8] net: stmmac: Correctly take timestamp for PTPv2
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
The case for PTPV2_EVENT requires event packets to be captured so add
this setting to the list of enabled captures.
Fixes: 891434b18ec0 ("stmmac: add IEEE PTPv1 and PTPv2 support.")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d3232738fb25..31a237ec73bc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -629,6 +629,7 @@ static int stmmac_hwtstamp_set(struct net_device *dev, struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
+ ts_event_en = PTP_TCR_TSEVNTENA;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
ptp_over_ethernet = PTP_TCR_TSIPENA;
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/8] net: stmmac: xgmac: Detect Hash Table size dinamically
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
Since commit b8ef7020d6e5 ("net: stmmac: add support for hash table size
128/256 in dwmac4"), we can detect the Hash Table dinamically.
Let's implement this feature in XGMAC cores and fix possible setups that
don't support the maximum size for Hash Table.
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 5923ca62d793..f7eb06f8fb37 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -122,6 +122,7 @@
#define XGMAC_HWFEAT_GMIISEL BIT(1)
#define XGMAC_HW_FEATURE1 0x00000120
#define XGMAC_HWFEAT_L3L4FNUM GENMASK(30, 27)
+#define XGMAC_HWFEAT_HASHTBLSZ GENMASK(25, 24)
#define XGMAC_HWFEAT_RSSEN BIT(20)
#define XGMAC_HWFEAT_TSOEN BIT(18)
#define XGMAC_HWFEAT_SPHEN BIT(17)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 53c4a40d8386..965cbe3e6f51 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -380,6 +380,7 @@ static void dwxgmac2_get_hw_feature(void __iomem *ioaddr,
/* MAC HW feature 1 */
hw_cap = readl(ioaddr + XGMAC_HW_FEATURE1);
dma_cap->l3l4fnum = (hw_cap & XGMAC_HWFEAT_L3L4FNUM) >> 27;
+ dma_cap->hash_tb_sz = (hw_cap & XGMAC_HWFEAT_HASHTBLSZ) >> 24;
dma_cap->rssen = (hw_cap & XGMAC_HWFEAT_RSSEN) >> 20;
dma_cap->tsoen = (hw_cap & XGMAC_HWFEAT_TSOEN) >> 18;
dma_cap->sphen = (hw_cap & XGMAC_HWFEAT_SPHEN) >> 17;
--
2.7.4
^ permalink raw reply related
* [PATCH net 6/8] net: stmmac: Do not stop PHY if WoL is enabled
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
If WoL is enabled we can't really stop the PHY, otherwise we will not
receive the WoL packet. Fix this by telling phylink that only the MAC is
down and only stop the PHY if WoL is not enabled.
Fixes: 74371272f97f ("net: stmmac: Convert to phylink and remove phylib logic")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 31a237ec73bc..843d53e084b7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4718,9 +4718,7 @@ int stmmac_suspend(struct device *dev)
mutex_lock(&priv->lock);
- rtnl_lock();
- phylink_stop(priv->phylink);
- rtnl_unlock();
+ phylink_mac_change(priv->phylink, false);
netif_device_detach(ndev);
stmmac_stop_all_queues(priv);
@@ -4735,6 +4733,10 @@ int stmmac_suspend(struct device *dev)
stmmac_pmt(priv, priv->hw, priv->wolopts);
priv->irq_wake = 1;
} else {
+ rtnl_lock();
+ phylink_stop(priv->phylink);
+ rtnl_unlock();
+
stmmac_mac_set(priv, priv->ioaddr, false);
pinctrl_pm_select_sleep_state(priv->device);
/* Disable clock in case of PWM is off */
@@ -4825,9 +4827,13 @@ int stmmac_resume(struct device *dev)
stmmac_start_all_queues(priv);
- rtnl_lock();
- phylink_start(priv->phylink);
- rtnl_unlock();
+ if (!device_may_wakeup(priv->device)) {
+ rtnl_lock();
+ phylink_start(priv->phylink);
+ rtnl_unlock();
+ }
+
+ phylink_mac_change(priv->phylink, true);
mutex_unlock(&priv->lock);
--
2.7.4
^ permalink raw reply related
* [PATCH net 0/8] net: stmmac: Fixes for -net
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
Misc fixes for -net tree. More info in commit logs.
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (8):
net: stmmac: xgmac: Not all Unicast addresses may be available
net: stmmac: xgmac: Detect Hash Table size dinamically
net: stmmac: selftests: Always use max DMA size in Jumbo Test
net: stmmac: dwmac4: Always update the MAC Hash Filter
net: stmmac: Correctly take timestamp for PTPv2
net: stmmac: Do not stop PHY if WoL is enabled
net: stmmac: xgmac: Disable the Timestamp interrupt by default
net: stmmac: xgmac: Fix RSS not writing all Keys to HW
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 13 +++++++------
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 4 ++--
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++++++++++++------
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 4 ----
6 files changed, 25 insertions(+), 19 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net 8/8] net: stmmac: xgmac: Fix RSS not writing all Keys to HW
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel, Nick Desaulniers
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
The sizeof(cfg->key) is != ARRAY_SIZE(cfg->key). Fix it.
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Fixes: 76067459c686 ("net: stmmac: Implement RSS and enable it in XGMAC core")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Nick Desaulniers <ndesaulniers@google.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 6d8ac2ef4fc2..4a1f52474dbc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -533,7 +533,7 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw,
return 0;
}
- for (i = 0; i < (sizeof(cfg->key) / sizeof(u32)); i++) {
+ for (i = 0; i < (ARRAY_SIZE(cfg->key) / sizeof(u32)); i++) {
ret = dwxgmac2_rss_write_reg(ioaddr, true, i, cfg->key[i]);
if (ret)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net 4/8] net: stmmac: dwmac4: Always update the MAC Hash Filter
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
We need to always update the MAC Hash Filter so that previous entries
are invalidated.
Found out while running stmmac selftests.
Fixes: b8ef7020d6e5 ("net: stmmac: add support for hash table size 128/256 in dwmac4")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 9b4b5f69fc02..2cb9c53f93b8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -401,8 +401,11 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
int numhashregs = (hw->multicast_filter_bins >> 5);
int mcbitslog2 = hw->mcast_bits_log2;
unsigned int value;
+ u32 mc_filter[8];
int i;
+ memset(mc_filter, 0, sizeof(mc_filter));
+
value = readl(ioaddr + GMAC_PACKET_FILTER);
value &= ~GMAC_PACKET_FILTER_HMC;
value &= ~GMAC_PACKET_FILTER_HPF;
@@ -416,16 +419,13 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
/* Pass all multi */
value |= GMAC_PACKET_FILTER_PM;
/* Set all the bits of the HASH tab */
- for (i = 0; i < numhashregs; i++)
- writel(0xffffffff, ioaddr + GMAC_HASH_TAB(i));
+ memset(mc_filter, 0xff, sizeof(mc_filter));
} else if (!netdev_mc_empty(dev)) {
struct netdev_hw_addr *ha;
- u32 mc_filter[8];
/* Hash filter for multicast */
value |= GMAC_PACKET_FILTER_HMC;
- memset(mc_filter, 0, sizeof(mc_filter));
netdev_for_each_mc_addr(ha, dev) {
/* The upper n bits of the calculated CRC are used to
* index the contents of the hash table. The number of
@@ -440,10 +440,11 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
*/
mc_filter[bit_nr >> 5] |= (1 << (bit_nr & 0x1f));
}
- for (i = 0; i < numhashregs; i++)
- writel(mc_filter[i], ioaddr + GMAC_HASH_TAB(i));
}
+ for (i = 0; i < numhashregs; i++)
+ writel(mc_filter[i], ioaddr + GMAC_HASH_TAB(i));
+
value |= GMAC_PACKET_FILTER_HPF;
/* Handle multiple unicast addresses */
--
2.7.4
^ permalink raw reply related
* [PATCH net 3/8] net: stmmac: selftests: Always use max DMA size in Jumbo Test
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
Although some XGMAC setups support frames larger than DMA size, some of
them may not. As we can't know before-hand which ones support let's use
the maximum DMA buffer size in the Jumbo Tests.
User can always reconfigure the MTU to achieve larger frames.
Fixes: 427849e8c37f ("net: stmmac: selftests: Add Jumbo Frame tests")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 5f66f6161629..cc76a42c7466 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1564,10 +1564,6 @@ static int __stmmac_test_jumbo(struct stmmac_priv *priv, u16 queue)
struct stmmac_packet_attrs attr = { };
int size = priv->dma_buf_sz;
- /* Only XGMAC has SW support for multiple RX descs in same packet */
- if (priv->plat->has_xgmac)
- size = priv->dev->max_mtu;
-
attr.dst = priv->dev->dev_addr;
attr.max_size = size - ETH_FCS_LEN;
attr.queue_mapping = queue;
--
2.7.4
^ permalink raw reply related
* [PATCH net 1/8] net: stmmac: xgmac: Not all Unicast addresses may be available
From: Jose Abreu @ 2019-09-27 7:48 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1569569778.git.Jose.Abreu@synopsys.com>
Some setups may not have all Unicast addresses filters available. Let's
check this before trying to setup filters.
Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 2b277b2c586b..6d8ac2ef4fc2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -472,7 +472,7 @@ static void dwxgmac2_set_filter(struct mac_device_info *hw,
dwxgmac2_set_mchash(ioaddr, mc_filter, mcbitslog2);
/* Handle multiple unicast addresses */
- if (netdev_uc_count(dev) > XGMAC_ADDR_MAX) {
+ if (netdev_uc_count(dev) > hw->unicast_filter_entries) {
value |= XGMAC_FILTER_PR;
} else {
struct netdev_hw_addr *ha;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] dimlib: make DIMLIB a hidden symbol
From: David Miller @ 2019-09-27 7:51 UTC (permalink / raw)
To: uwe; +Cc: talgi, saeedm, netdev
In-Reply-To: <20190924160259.10987-1-uwe@kleine-koenig.org>
From: Uwe Kleine-König <uwe@kleine-koenig.org>
Date: Tue, 24 Sep 2019 18:02:59 +0200
> According to Tal Gilboa the only benefit from DIM comes from a driver
> that uses it. So it doesn't make sense to make this symbol user visible,
> instead all drivers that use it should select it (as is already the case
> AFAICT).
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Applied.
^ permalink raw reply
* [PATCH v2] net: phy: micrel: add Asym Pause workaround for KSZ9021
From: Hans Andersson @ 2019-09-27 7:58 UTC (permalink / raw)
To: andrew
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel,
antoine.tenart, Hans Andersson
In-Reply-To: <20190926120922.GD1864@lunn.ch>
From: Hans Andersson <hans.andersson@cellavision.se>
The Micrel KSZ9031 PHY may fail to establish a link when the Asymmetric
Pause capability is set. This issue is described in a Silicon Errata
(DS80000691D or DS80000692D), which advises to always disable the
capability.
Micrel KSZ9021 has no errata, but has the same issue with Asymmetric Pause.
This patch apply the same workaround as the one for KSZ9031.
Fixes: 3aed3e2a143c ("net: phy: micrel: add Asym Pause workaround")
Signed-off-by: Hans Andersson <hans.andersson@cellavision.se>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/micrel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 3c8186f269f9..2fea5541c35a 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -763,6 +763,8 @@ static int ksz9031_get_features(struct phy_device *phydev)
* Whenever the device's Asymmetric Pause capability is set to 1,
* link-up may fail after a link-up to link-down transition.
*
+ * The Errata Sheet is for ksz9031, but ksz9021 has the same issue
+ *
* Workaround:
* Do not enable the Asymmetric Pause capability bit.
*/
@@ -1076,6 +1078,7 @@ static struct phy_driver ksphy_driver[] = {
/* PHY_GBIT_FEATURES */
.driver_data = &ksz9021_type,
.probe = kszphy_probe,
+ .get_features = ksz9031_get_features,
.config_init = ksz9021_config_init,
.ack_interrupt = kszphy_ack_interrupt,
.config_intr = kszphy_config_intr,
--
2.21.0.windows.1
^ permalink raw reply related
* Re: [PATCH net] net: aquantia: Fix aq_vec_isr_legacy() return value
From: David Miller @ 2019-09-27 7:59 UTC (permalink / raw)
To: dan.carpenter; +Cc: igor.russkikh, vomlehn, netdev, kernel-janitors
In-Reply-To: <20190925105430.GA3264@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 25 Sep 2019 13:54:30 +0300
> The irqreturn_t type is an enum or an unsigned int in GCC. That
> creates to problems because it can't detect if the
> self->aq_hw_ops->hw_irq_read() call fails and at the end the function
> always returns IRQ_HANDLED.
>
> drivers/net/ethernet/aquantia/atlantic/aq_vec.c:316 aq_vec_isr_legacy() warn: unsigned 'err' is never less than zero.
> drivers/net/ethernet/aquantia/atlantic/aq_vec.c:329 aq_vec_isr_legacy() warn: always true condition '(err >= 0) => (0-u32max >= 0)'
>
> Fixes: 970a2e9864b0 ("net: ethernet: aquantia: Vector operations")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] cxgb4: Signedness bug in init_one()
From: David Miller @ 2019-09-27 8:00 UTC (permalink / raw)
To: dan.carpenter; +Cc: vishal, ganeshgr, netdev, kernel-janitors
In-Reply-To: <20190925105459.GB3264@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 25 Sep 2019 13:54:59 +0300
> The "chip" variable is an enum, and it's treated as unsigned int by GCC
> in this context so the error handling isn't triggered.
>
> Fixes: e8d452923ae6 ("cxgb4: clean up init_one")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: hisilicon: Fix signedness bug in hix5hd2_dev_probe()
From: David Miller @ 2019-09-27 8:02 UTC (permalink / raw)
To: dan.carpenter
Cc: yisen.zhuang, zhangfei.gao, salil.mehta, netdev, kernel-janitors
In-Reply-To: <20190925105532.GC3264@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 25 Sep 2019 13:55:32 +0300
> The "priv->phy_mode" variable is an enum and in this context GCC will
> treat it as unsigned to the error handling will never trigger.
>
> Fixes: 57c5bc9ad7d7 ("net: hisilicon: add hix5hd2 mac driver")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: netsec: Fix signedness bug in netsec_probe()
From: David Miller @ 2019-09-27 8:04 UTC (permalink / raw)
To: dan.carpenter
Cc: jaswinder.singh, ilias.apalodimas, ast, daniel, jakub.kicinski,
hawk, john.fastabend, kafai, songliubraving, yhs, netdev, bpf,
kernel-janitors
In-Reply-To: <20190925105638.GE3264@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 25 Sep 2019 13:56:38 +0300
> The "priv->phy_interface" variable is an enum and in this context GCC
> will treat it as an unsigned int so the error handling is never
> triggered.
>
> Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] enetc: Fix a signedness bug in enetc_of_get_phy()
From: David Miller @ 2019-09-27 8:04 UTC (permalink / raw)
To: dan.carpenter; +Cc: claudiu.manoil, netdev, kernel-janitors
In-Reply-To: <20190925105714.GF3264@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 25 Sep 2019 13:57:14 +0300
> The "priv->if_mode" is type phy_interface_t which is an enum. In this
> context GCC will treat the enum as an unsigned int so this error
> handling is never triggered.
>
> Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH] vhost: introduce mdev based hardware backend
From: Tiwei Bie @ 2019-09-27 8:04 UTC (permalink / raw)
To: Jason Wang
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang,
lingshan.zhu
In-Reply-To: <49bb0777-3761-3737-8e5b-568957f9a935@redhat.com>
On Fri, Sep 27, 2019 at 03:14:42PM +0800, Jason Wang wrote:
> On 2019/9/27 下午12:54, Tiwei Bie wrote:
> > > > +
> > > > + /*
> > > > + * In vhost-mdev, userspace should pass ring addresses
> > > > + * in guest physical addresses when IOMMU is disabled or
> > > > + * IOVAs when IOMMU is enabled.
> > > > + */
> > > A question here, consider we're using noiommu mode. If guest physical
> > > address is passed here, how can a device use that?
> > >
> > > I believe you meant "host physical address" here? And it also have the
> > > implication that the HPA should be continuous (e.g using hugetlbfs).
> > The comment is talking about the virtual IOMMU (i.e. iotlb in vhost).
> > It should be rephrased to cover the noiommu case as well. Thanks for
> > spotting this.
>
>
> So the question still, if GPA is passed how can it be used by the
> virtio-mdev device?
Sorry if I didn't make it clear..
Of course, GPA can't be passed in noiommu mode.
>
> Thanks
>
^ permalink raw reply
* Re: [question] About triggering a region snapshot through the devlink cmd
From: Jiri Pirko @ 2019-09-27 8:13 UTC (permalink / raw)
To: Yunsheng Lin
Cc: jiri, valex, davem, netdev@vger.kernel.org, linuxarm@huawei.com
In-Reply-To: <f1436c35-e8be-7b9d-c2f5-b6403348f87a@huawei.com>
Fri, Sep 27, 2019 at 09:40:47AM CEST, linyunsheng@huawei.com wrote:
>Hi, Jiri & Alex
>
> It seems that a region' snapshot is only created through the
>driver when some error is detected, for example:
>mlx4_crdump_collect_fw_health() -> devlink_region_snapshot_create()
>
> We want to trigger a region' snapshot creation through devlink
>cmd, maybe by adding the "devlink region triger", because we want
>to check some hardware register/state when the driver or the hardware
>does not detect the error sometimes.
>
>Does about "devlink region triger" make sense?
>
>If yes, is there plan to implement it? or any suggestion to implement
>it?
Actually, the plan is co convert mlx4 to "devlink health" api. Mlx5
already uses that.
You should look into "devlink health".
>
^ permalink raw reply
* Re: [PATCH net] net: socionext: Fix a signedness bug in ave_probe()
From: David Miller @ 2019-09-27 8:14 UTC (permalink / raw)
To: dan.carpenter; +Cc: hayashi.kunihiko, netdev, kernel-janitors
In-Reply-To: <20190925105750.GG3264@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 25 Sep 2019 13:57:50 +0300
> The "phy_mode" variable is an enum and in this context GCC treats it as
> an unsigned int so the error handling is never triggered.
>
> Fixes: 4c270b55a5af ("net: ethernet: socionext: add AVE ethernet driver")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox