* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: maowenan @ 2019-02-18 14:04 UTC (permalink / raw)
To: Kalle Valo; +Cc: johannes, linux-wireless, kernel-janitors, netdev
In-Reply-To: <878sydus0p.fsf@kamboji.qca.qualcomm.com>
On 2019/2/18 21:48, Kalle Valo wrote:
> maowenan <maowenan@huawei.com> writes:
>
>> Add kalle Valo in mail list.
>>
>> Hi Kalle Valo,
>> Do you have any comments about this patch?
>
> Why do you ask me? Johannes maintains cfg80211, not me, and he will
> provide comments once he reviews the patch (which might take some time,
> we do have other tasks as well).
I'm sorry for this, my mistake to add wrong maintainer.
>
^ permalink raw reply
* Re: [PATCH] [V2]r8152: Add support for MAC address pass through on RTL8153-BD
From: Jiri Slaby @ 2019-02-18 14:22 UTC (permalink / raw)
To: David Chen, linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, mario.limonciello, bigeasy, edumazet,
f.fainelli, david.chen7, kai.heng.feng, zhongjiang
In-Reply-To: <20190218140057.17030-1-david0813@gmail.com>
On 18. 02. 19, 15:00, David Chen wrote:
> From: David Chen <david.chen7@dell.com>
>
> RTL8153-BD is used in Dell DA300 type-C dongle.
> It should be added to the whitelist of devices to activate MAC address
> pass through.
>
> Per confirming with Realtek all devices containing RTL8153-BD should
> activate MAC pass through and there won't use pass through bit on efuse
> like in RTL8153-AD.
>
> Signed-off-by: David Chen <david.chen7@dell.com>
> ---
> drivers/net/usb/r8152.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 60dd1ec1665f..86c8c64fbb0f 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -557,6 +557,7 @@ enum spd_duplex {
> /* MAC PASSTHRU */
> #define AD_MASK 0xfee0
> #define BND_MASK 0x0004
> +#define BD_MASK 0x0001
> #define EFUSE 0xcfdb
> #define PASS_THRU_MASK 0x1
>
> @@ -1176,9 +1177,9 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
> return -ENODEV;
> }
> } else {
> - /* test for RTL8153-BND */
> + /* test for RTL8153-BND and RTL8153-BD */
> ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
> - if ((ocp_data & BND_MASK) == 0) {
> + if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
Can you ensure that BND won't have the BD's bit set and vice versa? I.e.
should the check be something like:
if (isBND() && (ocp_data & BND_MASK) == 0 ||
isBD() && (ocp_data & BD_MASK) == 0)
instead?
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH] [V2]r8152: Add support for MAC address pass through on RTL8153-BD
From: David Chen @ 2019-02-18 14:00 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, mario.limonciello, bigeasy, edumazet, jslaby,
f.fainelli, david.chen7, kai.heng.feng, zhongjiang
From: David Chen <david.chen7@dell.com>
RTL8153-BD is used in Dell DA300 type-C dongle.
It should be added to the whitelist of devices to activate MAC address
pass through.
Per confirming with Realtek all devices containing RTL8153-BD should
activate MAC pass through and there won't use pass through bit on efuse
like in RTL8153-AD.
Signed-off-by: David Chen <david.chen7@dell.com>
---
drivers/net/usb/r8152.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 60dd1ec1665f..86c8c64fbb0f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -557,6 +557,7 @@ enum spd_duplex {
/* MAC PASSTHRU */
#define AD_MASK 0xfee0
#define BND_MASK 0x0004
+#define BD_MASK 0x0001
#define EFUSE 0xcfdb
#define PASS_THRU_MASK 0x1
@@ -1176,9 +1177,9 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
return -ENODEV;
}
} else {
- /* test for RTL8153-BND */
+ /* test for RTL8153-BND and RTL8153-BD */
ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
- if ((ocp_data & BND_MASK) == 0) {
+ if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
netif_dbg(tp, probe, tp->netdev,
"Invalid variant for MAC pass through\n");
return -ENODEV;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next v2 3/3] net: stmmac: dwxgmac2: Also use TBU interrupt to clean TX path
From: Jose Abreu @ 2019-02-18 13:51 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <b338784c2af1aba885b6822d2ec614774f1f78dd.1550479678.git.joabreu@synopsys.com>
On 2/18/2019 8:49 AM, Jose Abreu wrote:
> #define XGMAC_DMA_INT_DEFAULT_EN (XGMAC_NIE | XGMAC_AIE | XGMAC_RBUE | \
> - XGMAC_RIE | XGMAC_TIE)
> + XGMAC_RIE | XGMAC_TBUE | XGMAC_TIE)
This is wrong and was a left-over from debug. Enabling this will
cause an high volume of interrupts which I just noticed.
We can only look at the status and not enable the int.
I will send v3 without this define change. Sorry.
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: Kalle Valo @ 2019-02-18 13:48 UTC (permalink / raw)
To: maowenan; +Cc: johannes, linux-wireless, kernel-janitors, netdev
In-Reply-To: <927ff17c-c506-734f-fc27-796d4c8fba98@huawei.com>
maowenan <maowenan@huawei.com> writes:
> Add kalle Valo in mail list.
>
> Hi Kalle Valo,
> Do you have any comments about this patch?
Why do you ask me? Johannes maintains cfg80211, not me, and he will
provide comments once he reviews the patch (which might take some time,
we do have other tasks as well).
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] NETWORKING: avoid use IPCB in cipso_v4_error
From: Nazarov Sergey @ 2019-02-18 13:39 UTC (permalink / raw)
To: Paul Moore, David Miller
Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org
In-Reply-To: <CAHC9VhRys7Efm=aQqph2ug9c8Ryra9imEG66avjeEeY8QZWTqw@mail.gmail.com>
I think, it would not be a good solution, if I will analyze all subsystems using icmp_send, because I do not have enough knowledge for this.
I propose to add a new function, for example, ismp_send_safe, something like that:
void icmp_send_safe(struct sk_buff *skb_in, int type, int code, __be32 info)
{
unsigned char optbuf[sizeof(struct ip_options) + 40];
struct ip_options *opt = (struct ip_options *)optbuf;
memset(opt, 0, sizeof(struct ip_options));
opt->optlen = ip_hdr(skb_in)->ihl*4 - sizeof(struct iphdr);
memcpy(opt->__data, (unsigned char *)&(ip_hdr(skb_in)[1]), opt->optlen);
if (ip_options_compile(dev_net(skb_in->dev), opt, NULL))
return;
__icmp_send(skb_in, type, code, info, opt);
}
which could be used when the code works at different network stack layers.
And the subsystems developers, knowing their code well, will decide which one to use.
15.02.2019, 23:04, "Paul Moore" <paul@paul-moore.com>:
> On Fri, Feb 15, 2019 at 3:00 PM David Miller <davem@davemloft.net> wrote:
>> From: Paul Moore <paul@paul-moore.com>
>> Date: Fri, 15 Feb 2019 14:02:31 -0500
>>
>> > On Thu, Feb 14, 2019 at 11:43 AM David Miller <davem@davemloft.net> wrote:
>> >> From: Nazarov Sergey <s-nazarov@yandex.ru>
>> >> Date: Tue, 12 Feb 2019 18:10:03 +0300
>> >>
>> >> > Since cipso_v4_error might be called from different network stack layers, we can't safely use icmp_send there.
>> >> > icmp_send copies IP options with ip_option_echo, which uses IPCB to take access to IP header compiled data.
>> >> > But after commit 971f10ec ("tcp: better TCP_SKB_CB layout to reduce cache line misses"), IPCB can't be used
>> >> > above IP layer.
>> >> > This patch fixes the problem by creating in cipso_v4_error a local copy of compiled IP options and using it with
>> >> > introduced __icmp_send function. This looks some overloaded, but in quite rare error conditions only.
>> >> >
>> >> > The original discussion is here:
>> >> > https://lore.kernel.org/linux-security-module/16659801547571984@sas1-890ba5c2334a.qloud-c.yandex.net/
>> >> >
>> >> > Signed-off-by: Sergey Nazarov <s-nazarov@yandex.ru>
>> >>
>> >> This problem is not unique to Cipso, net/atm/clip.c's error handler
>> >> has the same exact issue.
>> >>
>> >> I didn't scan more of the tree, there are probably a couple more
>> >> locations as well.
>> >
>> > David, are you happy with Sergey's solution as a fix for this?
>> >
>> > If so, would you prefer a respin of this patch to apply the to the
>> > other broken callers (e.g. net/atm/clip.c), or would you rather merge
>> > this patch and deal with the other callers in separate patches?
>>
>> I'd like the other broken callers to be handled.
>
> Sergey, do you think you could fix the other callers too, or do you
> want some help with that?
>
> --
> paul moore
> www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] net: dsa: qca8k: Enable delay for RGMII_ID mode
From: Andrew Lunn @ 2019-02-18 13:36 UTC (permalink / raw)
To: Vinod Koul
Cc: David S Miller, linux-arm-msm, Bjorn Andersson, netdev,
Niklas Cassel, Florian Fainelli, Michal Vokáč
In-Reply-To: <20190218130352.9373-1-vkoul@kernel.org>
On Mon, Feb 18, 2019 at 06:33:51PM +0530, Vinod Koul wrote:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + /* RGMII_ID needs internal delay. This is enabled through
> + * PORT5_PAD_CTRL for all ports, rather than individual port
> + * registers
> + */
> + qca8k_write(priv, reg,
> + QCA8K_PORT_PAD_RGMII_EN |
> + QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
> + QCA8K_PORT_PAD_RGMII_RX_DELAY(3));
Hi Vinod
Could you add some #defines for the delay values?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] net: dsa: qca8k: Enable delay for RGMII_ID mode
From: Michal Vokáč @ 2019-02-18 13:35 UTC (permalink / raw)
To: Vinod Koul, David S Miller
Cc: linux-arm-msm, Bjorn Andersson, netdev, Niklas Cassel,
Andrew Lunn, Florian Fainelli
In-Reply-To: <20190218130352.9373-1-vkoul@kernel.org>
On 18. 02. 19 14:03, Vinod Koul wrote:
> RGMII_ID specifies that we should have internal delay, so resurrect the
> delay addition routine but under the RGMII_ID mode.
>
> Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Fixes the problem on my imx6dl platform with QCA8334 switch.
Thank you!
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
> ---
> drivers/net/dsa/qca8k.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
> index a4b6cda38016..aa1f7f1b20d3 100644
> --- a/drivers/net/dsa/qca8k.c
> +++ b/drivers/net/dsa/qca8k.c
> @@ -443,6 +443,18 @@ qca8k_set_pad_ctrl(struct qca8k_priv *priv, int port, int mode)
> val = QCA8K_PORT_PAD_RGMII_EN;
> qca8k_write(priv, reg, val);
> break;
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + /* RGMII_ID needs internal delay. This is enabled through
> + * PORT5_PAD_CTRL for all ports, rather than individual port
> + * registers
> + */
> + qca8k_write(priv, reg,
> + QCA8K_PORT_PAD_RGMII_EN |
> + QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
> + QCA8K_PORT_PAD_RGMII_RX_DELAY(3));
> + qca8k_write(priv, QCA8K_REG_PORT5_PAD_CTRL,
> + QCA8K_PORT_PAD_RGMII_RX_DELAY_EN);
> + break;
> case PHY_INTERFACE_MODE_SGMII:
> qca8k_write(priv, reg, QCA8K_PORT_PAD_SGMII_EN);
> break;
>
^ permalink raw reply
* [PATCH net] net: stmmac: Fix a race in EEE enable callback
From: Jose Abreu @ 2019-02-18 13:35 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jose Abreu, Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue
We are saving the status of EEE even before we try to enable it. This
leads to a race with XMIT function that tries to arm EEE timer before we
set it up.
Fix this by only saving the EEE parameters after all operations are
performed with success.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Fixes: d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 5d85742a2be0..3c749c327cbd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -696,25 +696,27 @@ static int stmmac_ethtool_op_set_eee(struct net_device *dev,
struct ethtool_eee *edata)
{
struct stmmac_priv *priv = netdev_priv(dev);
+ int ret;
- priv->eee_enabled = edata->eee_enabled;
-
- if (!priv->eee_enabled)
+ if (!edata->eee_enabled) {
stmmac_disable_eee_mode(priv);
- else {
+ } else {
/* We are asking for enabling the EEE but it is safe
* to verify all by invoking the eee_init function.
* In case of failure it will return an error.
*/
- priv->eee_enabled = stmmac_eee_init(priv);
- if (!priv->eee_enabled)
+ edata->eee_enabled = stmmac_eee_init(priv);
+ if (!edata->eee_enabled)
return -EOPNOTSUPP;
-
- /* Do not change tx_lpi_timer in case of failure */
- priv->tx_lpi_timer = edata->tx_lpi_timer;
}
- return phy_ethtool_set_eee(dev->phydev, edata);
+ ret = phy_ethtool_set_eee(dev->phydev, edata);
+ if (ret)
+ return ret;
+
+ priv->eee_enabled = edata->eee_enabled;
+ priv->tx_lpi_timer = edata->tx_lpi_timer;
+ return 0;
}
static u32 stmmac_usec2riwt(u32 usec, struct stmmac_priv *priv)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: dsa: qca8k: Enable delay for RGMII_ID mode
From: Andrew Lunn @ 2019-02-18 13:33 UTC (permalink / raw)
To: Vinod Koul
Cc: David S Miller, linux-arm-msm, Bjorn Andersson, netdev,
Niklas Cassel, Florian Fainelli, Michal Vokáč
In-Reply-To: <20190218130352.9373-1-vkoul@kernel.org>
On Mon, Feb 18, 2019 at 06:33:51PM +0530, Vinod Koul wrote:
> RGMII_ID specifies that we should have internal delay, so resurrect the
> delay addition routine but under the RGMII_ID mode.
>
> Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/net/dsa/qca8k.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
> index a4b6cda38016..aa1f7f1b20d3 100644
> --- a/drivers/net/dsa/qca8k.c
> +++ b/drivers/net/dsa/qca8k.c
> @@ -443,6 +443,18 @@ qca8k_set_pad_ctrl(struct qca8k_priv *priv, int port, int mode)
> val = QCA8K_PORT_PAD_RGMII_EN;
> qca8k_write(priv, reg, val);
> break;
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + /* RGMII_ID needs internal delay. This is enabled through
> + * PORT5_PAD_CTRL for all ports, rather than individual port
> + * registers
> + */
> + qca8k_write(priv, reg,
> + QCA8K_PORT_PAD_RGMII_EN |
> + QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
> + QCA8K_PORT_PAD_RGMII_RX_DELAY(3));
> + qca8k_write(priv, QCA8K_REG_PORT5_PAD_CTRL,
> + QCA8K_PORT_PAD_RGMII_RX_DELAY_EN);
> + break;
Hi Vinod
So i'm still confused if this is global, or per-port. The first
register written looks to be per-port, although only for ports 0 and
6. The second write seems to be global.
Is there a danger that port 0 has PHY_INTERFACE_MODE_RGMII_ID and port
6 has PHY_INTERFACE_MODE_RGMII, and we end up with delays disabled?
Maybe we should try to detect this, and return an error?
> case PHY_INTERFACE_MODE_SGMII:
> qca8k_write(priv, reg, QCA8K_PORT_PAD_SGMII_EN);
> break;
I think it would be good to add the other two PHY_INTERFACE_MODE_RGMII
modes to the default clause so we get an error reported that they are
not implemented.
Andrew
^ permalink raw reply
* Re: [RFC] net: dsa: qca8k: implement rgmii-id mode
From: Michal Vokáč @ 2019-02-18 13:31 UTC (permalink / raw)
To: Vinod Koul
Cc: Andrew Lunn, David S. Miller, netdev,
linux-kernel@vger.kernel.org, Florian Fainelli
In-Reply-To: <20190218130306.GM21884@vkoul-mobl>
On 18. 02. 19 14:03, Vinod Koul wrote:
> On 18-02-19, 12:54, Michal Vokáč wrote:
>> On 18. 02. 19 11:45, Vinod Koul wrote:
>>> On 15-02-19, 16:23, Andrew Lunn wrote:
>>>> On Fri, Feb 15, 2019 at 04:01:08PM +0100, Michal Vokáč wrote:
>>>>> Hi,
>>>>>
>>>>> networking on my boards [1], which are currently in linux-next, suddently
>>>>> stopped working. I tracked it down to this commit 5ecdd77c61c8 ("net: dsa:
>>>>> qca8k: disable delay for RGMII mode") [2].
>>>>>
>>>>> So I think the rgmii-id mode is obviously needed in my case.
>>>>> I was able to find a couple drivers that read tx/rx-delay or
>>>>> tx/rx-internal-delay from device tree. Namely:
>>>>>
>>>>> drivers/net/ethernet/apm/xgene/xgene_enet_main.c
>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
>>>>> drivers/net/phy/dp83867.c
>>>>>
>>>>> I would appreciate any hints how to add similar function to qca8k driver
>>>>> if that is the correct way to go. Can I take some of the above mentioned
>>>>> drivers as a good example for that? How should the binding look like?
>>>>>
>>>>> I would expect something like this:
>>>>>
>>>>> switch@0 {
>>>>> compatible = "qca,qca8334";
>>>>> reg = <0>;
>>>>>
>>>>> switch_ports: ports {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>>
>>>>> ethphy0: port@0 {
>>>>> reg = <0>;
>>>>> label = "cpu";
>>>>> phy-mode = "rgmii-id";
>>>>> qca,tx-delay = <3>;
>>>>> qca,rx-delay = <3>;
>>>>> ethernet = <&fec>;
>>>>> };
>>>>
>>>> Hi Michal
>>>>
>>>> Your submission used:
>>>>
>>>> + ethphy0: port@0 {
>>>> + reg = <0>;
>>>> + label = "cpu";
>>>> + phy-mode = "rgmii";
>>>> + ethernet = <&fec>;
>>>> +
>>>> + fixed-link {
>>>> + speed = <1000>;
>>>> + full-duplex;
>>>> + };
>>>> + };
>>>>
>>>> This is good. If you have a fixed-link you can pass a phy-mode.
>>
>> Yes, I am using fixed-link and the plan was to implement the rgmii-id
>> mode.
>>
>>>>
>>>> The comment that was removed was:
>>>>
>>>> - /* According to the datasheet, RGMII delay is enabled through
>>>> - * PORT5_PAD_CTRL for all ports, rather than individual port
>>>> - * registers
>>>> - */
>>>>
>>>> Is it possible to enable delays per port? Ideally, you want to enable
>>>> delays for just selected ports. Add another case for
>>>> PHY_INTERFACE_MODE_RGMII_ID to enable the delays.
>>
>> I am still trying to collect all the relevant notes and bits from the
>> horrible docs to understand how this is done. The problem is different
>> parts and different versions of the documentation provide diffrerent
>> details.
>>
>> For example the QCA8334 model does not have PORT5 and so that registers
>> are not documented. Though some application note document says:
>>
>> """
>> The MAC0 timing control is in the Port0 PAD Mode Control Register (offset 0x0004):
>>
>> 1. RGMII timing delay for the output path of QCA8337(N) is enabled by 0x8[24].
>> Set 1 to add 2ns delay in 1000 mode for all RGMII interfaces.
>>
>> 2. Bit [21:20]: select the delay time for the output path in 10/100 mode.
>>
>> 3. Bit 25: enable the timing delay for the input path of QCA8337(N) in 1000 mode.
>>
>> 4. Bit [23:22]: select the delay time for the input path in 1000 mode.
>> 00: 0.2ns
>> 01: 1.2ns
>> 10: 2.1ns
>> 11: 3.1ns
>> """
>>
>> That is in line with the removed comment. The bit 24 at address 0x8 is
>> used to enable/disable delays globally. And obviously it is needed on the
>> QCA8334 model as well even though it should not have the PORT5.
>>
>>> In the hindsight I should not have removed the comment, let me ressurect
>>> that as well as add handling of the RGMII modes...
>>
>> OK, thanks.
>
> Since it used to work for you before, you need older code in RGMII_ID
> mode, I have added that along with the comment
Sure, that is OK for me. I just thought about implementing something more
generic with the option to set the delay value, even though I do not really
need it.
Thank you,
Michal
^ permalink raw reply
* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: maowenan @ 2019-02-18 13:25 UTC (permalink / raw)
To: johannes, linux-wireless, kernel-janitors, netdev, kvalo
In-Reply-To: <20190216094710.127182-1-maowenan@huawei.com>
Add kalle Valo in mail list.
Hi Kalle Valo,
Do you have any comments about this patch?
On 2019/2/16 17:47, Mao Wenan wrote:
> This patch is to use eth_broadcast_addr() to assign broadcast address
> insetad of memset().
>
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
> ---
> net/wireless/pmsr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/wireless/pmsr.c b/net/wireless/pmsr.c
> index de9286703280..21139b82749f 100644
> --- a/net/wireless/pmsr.c
> +++ b/net/wireless/pmsr.c
> @@ -258,7 +258,7 @@ int nl80211_pmsr_start(struct sk_buff *skb, struct genl_info *info)
> } else {
> memcpy(req->mac_addr, nla_data(info->attrs[NL80211_ATTR_MAC]),
> ETH_ALEN);
> - memset(req->mac_addr_mask, 0xff, ETH_ALEN);
> + eth_broadcast_addr(req->mac_addr_mask);
> }
>
> idx = 0;
>
^ permalink raw reply
* [PATCH net 2/2] qed: Fix iWARP syn packet mac address validation.
From: Michal Kalderon @ 2019-02-18 13:24 UTC (permalink / raw)
To: michal.kalderon, ariel.elior, davem; +Cc: netdev, linux-rdma
In-Reply-To: <20190218132403.12487-1-michal.kalderon@marvell.com>
The ll2 forwards all syn packets to the driver without validating the mac
address. Add validation check in the driver's iWARP listener flow and drop
the packet if it isn't intended for the device.
Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index e84fb01..ded556b 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -1688,6 +1688,15 @@ qed_iwarp_parse_rx_pkt(struct qed_hwfn *p_hwfn,
eth_hlen = ETH_HLEN + (vlan_valid ? sizeof(u32) : 0);
+ if (!ether_addr_equal(ethh->h_dest,
+ p_hwfn->p_rdma_info->iwarp.mac_addr)) {
+ DP_VERBOSE(p_hwfn,
+ QED_MSG_RDMA,
+ "Got unexpected mac %pM instead of %pM\n",
+ ethh->h_dest, p_hwfn->p_rdma_info->iwarp.mac_addr);
+ return -EINVAL;
+ }
+
ether_addr_copy(remote_mac_addr, ethh->h_source);
ether_addr_copy(local_mac_addr, ethh->h_dest);
--
2.9.5
^ permalink raw reply related
* [PATCH net 1/2] qed: Fix iWARP buffer size provided for syn packet processing.
From: Michal Kalderon @ 2019-02-18 13:24 UTC (permalink / raw)
To: michal.kalderon, ariel.elior, davem; +Cc: netdev, linux-rdma
In-Reply-To: <20190218132403.12487-1-michal.kalderon@marvell.com>
The assumption that the maximum size of a syn packet is 128 bytes
is wrong. Tunneling headers were not accounted for.
Allocate buffers large enough for mtu.
Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 12 ++++++------
drivers/net/ethernet/qlogic/qed/qed_iwarp.h | 1 -
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index beb8e5d..e84fb01 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -2605,7 +2605,7 @@ qed_iwarp_ll2_start(struct qed_hwfn *p_hwfn,
struct qed_iwarp_info *iwarp_info;
struct qed_ll2_acquire_data data;
struct qed_ll2_cbs cbs;
- u32 mpa_buff_size;
+ u32 buff_size;
u16 n_ooo_bufs;
int rc = 0;
int i;
@@ -2632,7 +2632,7 @@ qed_iwarp_ll2_start(struct qed_hwfn *p_hwfn,
memset(&data, 0, sizeof(data));
data.input.conn_type = QED_LL2_TYPE_IWARP;
- data.input.mtu = QED_IWARP_MAX_SYN_PKT_SIZE;
+ data.input.mtu = params->max_mtu;
data.input.rx_num_desc = QED_IWARP_LL2_SYN_RX_SIZE;
data.input.tx_num_desc = QED_IWARP_LL2_SYN_TX_SIZE;
data.input.tx_max_bds_per_packet = 1; /* will never be fragmented */
@@ -2654,9 +2654,10 @@ qed_iwarp_ll2_start(struct qed_hwfn *p_hwfn,
goto err;
}
+ buff_size = QED_IWARP_MAX_BUF_SIZE(params->max_mtu);
rc = qed_iwarp_ll2_alloc_buffers(p_hwfn,
QED_IWARP_LL2_SYN_RX_SIZE,
- QED_IWARP_MAX_SYN_PKT_SIZE,
+ buff_size,
iwarp_info->ll2_syn_handle);
if (rc)
goto err;
@@ -2710,10 +2711,9 @@ qed_iwarp_ll2_start(struct qed_hwfn *p_hwfn,
if (rc)
goto err;
- mpa_buff_size = QED_IWARP_MAX_BUF_SIZE(params->max_mtu);
rc = qed_iwarp_ll2_alloc_buffers(p_hwfn,
data.input.rx_num_desc,
- mpa_buff_size,
+ buff_size,
iwarp_info->ll2_mpa_handle);
if (rc)
goto err;
@@ -2726,7 +2726,7 @@ qed_iwarp_ll2_start(struct qed_hwfn *p_hwfn,
iwarp_info->max_num_partial_fpdus = (u16)p_hwfn->p_rdma_info->num_qps;
- iwarp_info->mpa_intermediate_buf = kzalloc(mpa_buff_size, GFP_KERNEL);
+ iwarp_info->mpa_intermediate_buf = kzalloc(buff_size, GFP_KERNEL);
if (!iwarp_info->mpa_intermediate_buf)
goto err;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.h b/drivers/net/ethernet/qlogic/qed/qed_iwarp.h
index b8f612d..7ac95903 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.h
@@ -46,7 +46,6 @@ enum qed_iwarp_qp_state qed_roce2iwarp_state(enum qed_roce_qp_state state);
#define QED_IWARP_LL2_SYN_TX_SIZE (128)
#define QED_IWARP_LL2_SYN_RX_SIZE (256)
-#define QED_IWARP_MAX_SYN_PKT_SIZE (128)
#define QED_IWARP_LL2_OOO_DEF_TX_SIZE (256)
#define QED_IWARP_MAX_OOO (16)
--
2.9.5
^ permalink raw reply related
* [PATCH net 0/2] qed: iWARP - fix some syn related issues.
From: Michal Kalderon @ 2019-02-18 13:24 UTC (permalink / raw)
To: michal.kalderon, ariel.elior, davem; +Cc: netdev, linux-rdma
This series fixes two bugs related to iWARP syn processing flow.
Michal Kalderon (2):
qed: Fix iWARP buffer size provided for syn packet processing.
qed: Fix iWARP syn packet mac address validation.
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 21 +++++++++++++++------
drivers/net/ethernet/qlogic/qed/qed_iwarp.h | 1 -
2 files changed, 15 insertions(+), 7 deletions(-)
--
2.9.5
^ permalink raw reply
* [ANNOUNCE] Linux IPsec workshop 2019
From: Steffen Klassert @ 2019-02-18 13:15 UTC (permalink / raw)
To: netdev; +Cc: lwn
This is an announce of the Linux IPsec workshop 2019. The workshop
will take place in Prague, Czech Republic, from 18th to 20th March 2019.
The workshop is invitation based and limited to ca. 20 - 25 IPsec
developers from user and kernel space. We almost reached the limit,
but still have a few spare places. If you think you can contribute
with a discussion topic or presentation, please send me a mail with
your proposal.
The main focus of this workshop is IPsec, but also other network
security/crypto related related topics are welcome. This workshop
should bring together userspace and kernel IPsec developers, as well as
hardware vendors that develop hardware with network security offload
capabilities. The aim is to discuss the ongoing IPsec related development.
It should be also a platform to discuss new ideas and to get feedback
from different points of view.
^ permalink raw reply
* [PATCH] net: dsa: qca8k: Enable delay for RGMII_ID mode
From: Vinod Koul @ 2019-02-18 13:03 UTC (permalink / raw)
To: David S Miller
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, netdev, Niklas Cassel,
Andrew Lunn, Florian Fainelli, Michal Vokáč
RGMII_ID specifies that we should have internal delay, so resurrect the
delay addition routine but under the RGMII_ID mode.
Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/net/dsa/qca8k.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
index a4b6cda38016..aa1f7f1b20d3 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -443,6 +443,18 @@ qca8k_set_pad_ctrl(struct qca8k_priv *priv, int port, int mode)
val = QCA8K_PORT_PAD_RGMII_EN;
qca8k_write(priv, reg, val);
break;
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ /* RGMII_ID needs internal delay. This is enabled through
+ * PORT5_PAD_CTRL for all ports, rather than individual port
+ * registers
+ */
+ qca8k_write(priv, reg,
+ QCA8K_PORT_PAD_RGMII_EN |
+ QCA8K_PORT_PAD_RGMII_TX_DELAY(3) |
+ QCA8K_PORT_PAD_RGMII_RX_DELAY(3));
+ qca8k_write(priv, QCA8K_REG_PORT5_PAD_CTRL,
+ QCA8K_PORT_PAD_RGMII_RX_DELAY_EN);
+ break;
case PHY_INTERFACE_MODE_SGMII:
qca8k_write(priv, reg, QCA8K_PORT_PAD_SGMII_EN);
break;
--
2.20.1
^ permalink raw reply related
* Re: [RFC] net: dsa: qca8k: implement rgmii-id mode
From: Vinod Koul @ 2019-02-18 13:03 UTC (permalink / raw)
To: Michal Vokáč
Cc: Andrew Lunn, David S. Miller, netdev,
linux-kernel@vger.kernel.org, Florian Fainelli
In-Reply-To: <40d0e8b0-b16d-85ef-e647-944bc7dbd571@ysoft.com>
On 18-02-19, 12:54, Michal Vokáč wrote:
> On 18. 02. 19 11:45, Vinod Koul wrote:
> > On 15-02-19, 16:23, Andrew Lunn wrote:
> > > On Fri, Feb 15, 2019 at 04:01:08PM +0100, Michal Vokáč wrote:
> > > > Hi,
> > > >
> > > > networking on my boards [1], which are currently in linux-next, suddently
> > > > stopped working. I tracked it down to this commit 5ecdd77c61c8 ("net: dsa:
> > > > qca8k: disable delay for RGMII mode") [2].
> > > >
> > > > So I think the rgmii-id mode is obviously needed in my case.
> > > > I was able to find a couple drivers that read tx/rx-delay or
> > > > tx/rx-internal-delay from device tree. Namely:
> > > >
> > > > drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> > > > drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > > > drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> > > > drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > > > drivers/net/phy/dp83867.c
> > > >
> > > > I would appreciate any hints how to add similar function to qca8k driver
> > > > if that is the correct way to go. Can I take some of the above mentioned
> > > > drivers as a good example for that? How should the binding look like?
> > > >
> > > > I would expect something like this:
> > > >
> > > > switch@0 {
> > > > compatible = "qca,qca8334";
> > > > reg = <0>;
> > > >
> > > > switch_ports: ports {
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > >
> > > > ethphy0: port@0 {
> > > > reg = <0>;
> > > > label = "cpu";
> > > > phy-mode = "rgmii-id";
> > > > qca,tx-delay = <3>;
> > > > qca,rx-delay = <3>;
> > > > ethernet = <&fec>;
> > > > };
> > >
> > > Hi Michal
> > >
> > > Your submission used:
> > >
> > > + ethphy0: port@0 {
> > > + reg = <0>;
> > > + label = "cpu";
> > > + phy-mode = "rgmii";
> > > + ethernet = <&fec>;
> > > +
> > > + fixed-link {
> > > + speed = <1000>;
> > > + full-duplex;
> > > + };
> > > + };
> > >
> > > This is good. If you have a fixed-link you can pass a phy-mode.
>
> Yes, I am using fixed-link and the plan was to implement the rgmii-id
> mode.
>
> > >
> > > The comment that was removed was:
> > >
> > > - /* According to the datasheet, RGMII delay is enabled through
> > > - * PORT5_PAD_CTRL for all ports, rather than individual port
> > > - * registers
> > > - */
> > >
> > > Is it possible to enable delays per port? Ideally, you want to enable
> > > delays for just selected ports. Add another case for
> > > PHY_INTERFACE_MODE_RGMII_ID to enable the delays.
>
> I am still trying to collect all the relevant notes and bits from the
> horrible docs to understand how this is done. The problem is different
> parts and different versions of the documentation provide diffrerent
> details.
>
> For example the QCA8334 model does not have PORT5 and so that registers
> are not documented. Though some application note document says:
>
> """
> The MAC0 timing control is in the Port0 PAD Mode Control Register (offset 0x0004):
>
> 1. RGMII timing delay for the output path of QCA8337(N) is enabled by 0x8[24].
> Set 1 to add 2ns delay in 1000 mode for all RGMII interfaces.
>
> 2. Bit [21:20]: select the delay time for the output path in 10/100 mode.
>
> 3. Bit 25: enable the timing delay for the input path of QCA8337(N) in 1000 mode.
>
> 4. Bit [23:22]: select the delay time for the input path in 1000 mode.
> 00: 0.2ns
> 01: 1.2ns
> 10: 2.1ns
> 11: 3.1ns
> """
>
> That is in line with the removed comment. The bit 24 at address 0x8 is
> used to enable/disable delays globally. And obviously it is needed on the
> QCA8334 model as well even though it should not have the PORT5.
>
> > In the hindsight I should not have removed the comment, let me ressurect
> > that as well as add handling of the RGMII modes...
>
> OK, thanks.
Since it used to work for you before, you need older code in RGMII_ID
mode, I have added that along with the comment
>
> > Please do test
>
> Sure, will do. Just let me know when you have something ready.
> Thank you!
Sending it shortly and ccing you as well
Thanks
--
~Vinod
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Jose Abreu @ 2019-02-18 13:02 UTC (permalink / raw)
To: Simon Huelck, Jose Abreu, Martin Blumenstingl
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <6f25da2b-7f28-b888-3240-7178ac75c90c@synopsys.com>
On 2/18/2019 12:41 PM, Jose Abreu wrote:
> On 2/18/2019 12:33 PM, Simon Huelck wrote:
>> Hi,
>>
>>
>> i recognize the followin on my ethernet stats:
>>
>> threshold: 1
>> tx_pkt_n: 1457325
>> rx_pkt_n: 5022405
>> normal_irq_n: 671738
>> rx_normal_irq_n: 606573
>> napi_poll: 784439
>> tx_normal_irq_n: 61061
>> tx_clean: 784439
>> tx_set_ic_bit: 58293
>> irq_receive_pmt_irq_n: 0
>> mmc_tx_irq_n: 0
>> mmc_rx_irq_n: 0
>> mmc_rx_csum_offload_irq_n: 0
>> -> irq_tx_path_in_lpi_mode_n: 382037
>> -> irq_tx_path_exit_lpi_mode_n: 382021
>>
>>
>> Is this normal ?
>
> Did you try disabling EEE ? ("ethtool --set-eee eth0 eee off")
BTW, do not try to re-enable it. There is a race in the enable
function. I will send a fix ASAP.
>
> Thanks,
> Jose Miguel Abreu
>
^ permalink raw reply
* Re: [PATCH][next] Bluetooth: a2mp: Use struct_size() helper
From: Marcel Holtmann @ 2019-02-18 13:02 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <20190208002817.GA15338@embeddedor>
Hi Gustavo,
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
> instance = alloc(size, GFP_KERNEL)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> net/bluetooth/a2mp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH][next] Bluetooth: hci_event: Use struct_size() helper
From: Marcel Holtmann @ 2019-02-18 13:00 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johan Hedberg, David S. Miller, linux-bluetooth, netdev,
linux-kernel
In-Reply-To: <20190208004033.GA15609@embeddedor>
Hi Gustavo,
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, change the following form:
>
> sizeof(*ev) + ev->num_hndl * sizeof(struct hci_comp_pkts_info)
>
> to :
>
> struct_size(ev, handles, ev->num_hndl)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> net/bluetooth/hci_event.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: dsa: mv88e6xxx: default to multicast and unicast flooding
From: Russell King - ARM Linux admin @ 2019-02-18 12:53 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot
Cc: Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <E1gvPMu-0000Ax-Ba@rmk-PC.armlinux.org.uk>
On Sun, Feb 17, 2019 at 04:32:40PM +0000, Russell King wrote:
> Switches work by learning the MAC address for each attached station by
> monitoring traffic from each station. When a station sends a packet,
> the switch records which port the MAC address is connected to.
>
> With IPv4 networking, before communication commences with a neighbour,
> an ARP packet is broadcasted to all stations asking for the MAC address
> corresponding with the IPv4. The desired station responds with an ARP
> reply, and the ARP reply causes the switch to learn which port the
> station is connected to.
>
> With IPv6 networking, the situation is rather different. Rather than
> broadcasting ARP packets, a "neighbour solicitation" is multicasted
> rather than broadcasted. This multicast needs to reach the intended
> station in order for the neighbour to be discovered.
>
> Once a neighbour has been discovered, and entered into the sending
> stations neighbour cache, communication can restart at a point later
> without sending a new neighbour solicitation, even if the entry in
> the neighbour cache is marked as stale. This can be after the MAC
> address has expired from the forwarding cache of the DSA switch -
> when that occurs, there is a long pause in communication.
>
> Our DSA implementation for mv88e6xxx switches has defaulted to having
> multicast and unicast flooding disabled. As per the above description,
> this is fine for IPv4 networking, since the broadcasted ARP queries
> will be sent to and received by all stations on the same network.
> However, this breaks IPv6 very badly - blocking neighbour solicitations
> and later causing connections to stall.
>
> The defaults that the Linux bridge code expect from bridges are that
> unknown unicast frames and unknown multicast frames are flooded to
> all stations, which is at odds to the defaults adopted by our DSA
> implementation for mv88e6xxx switches.
>
> This commit enables by default flooding of both unknown unicast and
> unknown multicast frames. This means that mv88e6xxx DSA switches now
> behave as per the bridge(8) man page, and IPv6 works flawlessly through
> such a switch.
Thinking about this a bit more, this approach probably isn't the best.
If we have a port that goes through this life-cycle:
1. assigned to a bridge
2. configured not to flood
3. reassigned to a new bridge
the port will retain its settings from the first bridge, which will be
at odds with the settings that the Linux bridge code expects and the
settings visible to the user.
So, how about this, which basically reverts this patch and applies the
flood settings each time a port joins a bridge, and clears them when
the port leaves a bridge.
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5ac2c93b7cee..6f68c35d416f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1962,6 +1962,13 @@ static int mv88e6xxx_port_bridge_join(struct dsa_switch *ds, int port,
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_bridge_map(chip, br);
+ /* Linux bridges are expected to flood unknown multicast and
+ * unicast frames to all ports - as per the defaults specified
+ * in the iproute2 bridge(8) man page. Not doing this causes
+ * stalls and failures with IPv6 over Marvell bridges. */
+ if (err == 0 && chip->info->ops->port_set_egress_floods)
+ err = chip->info->ops->port_set_egress_floods(chip, port,
+ true, true);
mutex_unlock(&chip->reg_lock);
return err;
@@ -1976,6 +1983,9 @@ static void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port,
if (mv88e6xxx_bridge_map(chip, br) ||
mv88e6xxx_port_vlan_map(chip, port))
dev_err(ds->dev, "failed to remap in-chip Port VLAN\n");
+ if (chip->info->ops->port_set_egress_floods &&
+ chip->info->ops->port_set_egress_floods(chip, port, false, false))
+ dev_err(ds->dev, "failed to disable port floods\n");
mutex_unlock(&chip->reg_lock);
}
@@ -2134,13 +2144,14 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port)
static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port)
{
- /* Linux bridges are expected to flood unknown multicast and
- * unicast frames to all ports - as per the defaults specified
- * in the iproute2 bridge(8) man page. Not doing this causes
- * stalls and failures with IPv6 over Marvell bridges. */
+ struct dsa_switch *ds = chip->ds;
+ bool flood;
+
+ /* Upstream ports flood frames with unknown unicast or multicast DA */
+ flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port);
if (chip->info->ops->port_set_egress_floods)
return chip->info->ops->port_set_egress_floods(chip, port,
- true, true);
+ flood, flood);
return 0;
}
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply related
* Re: stmmac / meson8b-dwmac
From: Jose Abreu @ 2019-02-18 12:41 UTC (permalink / raw)
To: Simon Huelck, Jose Abreu, Martin Blumenstingl
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <7afdaa0d-d0ef-b223-1f6e-2b52bfa44784@gmx.de>
On 2/18/2019 12:33 PM, Simon Huelck wrote:
> Hi,
>
>
> i recognize the followin on my ethernet stats:
>
> threshold: 1
> tx_pkt_n: 1457325
> rx_pkt_n: 5022405
> normal_irq_n: 671738
> rx_normal_irq_n: 606573
> napi_poll: 784439
> tx_normal_irq_n: 61061
> tx_clean: 784439
> tx_set_ic_bit: 58293
> irq_receive_pmt_irq_n: 0
> mmc_tx_irq_n: 0
> mmc_rx_irq_n: 0
> mmc_rx_csum_offload_irq_n: 0
> -> irq_tx_path_in_lpi_mode_n: 382037
> -> irq_tx_path_exit_lpi_mode_n: 382021
>
>
> Is this normal ?
Did you try disabling EEE ? ("ethtool --set-eee eth0 eee off")
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH net] iptunnel: NULL pointer deref for ip_md_tunnel_xmit
From: Alan Maguire @ 2019-02-18 12:36 UTC (permalink / raw)
To: netdev, davem; +Cc: kuznet, yoshfuji, ast, daniel, kafai, songliubraving, yhs
Naresh Kamboju noted the following oops during execution of selftest
tools/testing/selftests/bpf/test_tunnel.sh on x86_64:
[ 274.120445] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000000
[ 274.128285] #PF error: [INSTR]
[ 274.131351] PGD 8000000414a0e067 P4D 8000000414a0e067 PUD 3b6334067 PMD 0
[ 274.138241] Oops: 0010 [#1] SMP PTI
[ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted
5.0.0-rc4-next-20190129 #1
[ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 274.156526] RIP: 0010: (null)
[ 274.160280] Code: Bad RIP value.
[ 274.163509] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
[ 274.168726] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
[ 274.175851] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
[ 274.182974] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
[ 274.190098] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
[ 274.197222] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
[ 274.204346] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
knlGS:0000000000000000
[ 274.212424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 274.218162] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
[ 274.225292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 274.232416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 274.239541] Call Trace:
[ 274.241988] ? tnl_update_pmtu+0x296/0x3b0
[ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520
[ 274.250176] gre_fb_xmit+0x330/0x390
[ 274.253754] gre_tap_xmit+0x128/0x180
[ 274.257414] dev_hard_start_xmit+0xb7/0x300
[ 274.261598] sch_direct_xmit+0xf6/0x290
[ 274.265430] __qdisc_run+0x15d/0x5e0
[ 274.269007] __dev_queue_xmit+0x2c5/0xc00
[ 274.273011] ? dev_queue_xmit+0x10/0x20
[ 274.276842] ? eth_header+0x2b/0xc0
[ 274.280326] dev_queue_xmit+0x10/0x20
[ 274.283984] ? dev_queue_xmit+0x10/0x20
[ 274.287813] arp_xmit+0x1a/0xf0
[ 274.290952] arp_send_dst.part.19+0x46/0x60
[ 274.295138] arp_solicit+0x177/0x6b0
[ 274.298708] ? mod_timer+0x18e/0x440
[ 274.302281] neigh_probe+0x57/0x70
[ 274.305684] __neigh_event_send+0x197/0x2d0
[ 274.309862] neigh_resolve_output+0x18c/0x210
[ 274.314212] ip_finish_output2+0x257/0x690
[ 274.318304] ip_finish_output+0x219/0x340
[ 274.322314] ? ip_finish_output+0x219/0x340
[ 274.326493] ip_output+0x76/0x240
[ 274.329805] ? ip_fragment.constprop.53+0x80/0x80
[ 274.334510] ip_local_out+0x3f/0x70
[ 274.337992] ip_send_skb+0x19/0x40
[ 274.341391] ip_push_pending_frames+0x33/0x40
[ 274.345740] raw_sendmsg+0xc15/0x11d0
[ 274.349403] ? __might_fault+0x85/0x90
[ 274.353151] ? _copy_from_user+0x6b/0xa0
[ 274.357070] ? rw_copy_check_uvector+0x54/0x130
[ 274.361604] inet_sendmsg+0x42/0x1c0
[ 274.365179] ? inet_sendmsg+0x42/0x1c0
[ 274.368937] sock_sendmsg+0x3e/0x50
[ 274.372460] ___sys_sendmsg+0x26f/0x2d0
[ 274.376293] ? lock_acquire+0x95/0x190
[ 274.380043] ? __handle_mm_fault+0x7ce/0xb70
[ 274.384307] ? lock_acquire+0x95/0x190
[ 274.388053] ? __audit_syscall_entry+0xdd/0x130
[ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0
[ 274.397461] ? __audit_syscall_entry+0xdd/0x130
[ 274.401989] ? trace_hardirqs_on+0x4c/0x100
[ 274.406173] __sys_sendmsg+0x63/0xa0
[ 274.409744] ? __sys_sendmsg+0x63/0xa0
[ 274.413488] __x64_sys_sendmsg+0x1f/0x30
[ 274.417405] do_syscall_64+0x55/0x190
[ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 274.426113] RIP: 0033:0x7ff4ae0e6e87
[ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00
00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c
24 08
[ 274.448422] RSP: 002b:00007ffcd9b76db8 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 274.455978] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007ff4ae0e6e87
[ 274.463104] RDX: 0000000000000000 RSI: 00000000006092e0 RDI: 0000000000000003
[ 274.470228] RBP: 0000000000000000 R08: 00007ffcd9bc40a0 R09: 00007ffcd9bc4080
[ 274.477349] R10: 000000000000060a R11: 0000000000000246 R12: 0000000000000003
[ 274.484475] R13: 0000000000000016 R14: 00007ffcd9b77fa0 R15: 00007ffcd9b78da4
[ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter
ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded:
test_bpf]
[ 274.504634] CR2: 0000000000000000
[ 274.507976] ---[ end trace 196d18386545eae1 ]---
[ 274.512588] RIP: 0010: (null)
[ 274.516334] Code: Bad RIP value.
[ 274.519557] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
[ 274.524775] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
[ 274.531921] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
[ 274.539082] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
[ 274.546205] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
[ 274.553329] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
[ 274.560456] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
knlGS:0000000000000000
[ 274.568541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 274.574277] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
[ 274.581403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 274.588535] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 274.595658] Kernel panic - not syncing: Fatal exception in interrupt
[ 274.602046] Kernel Offset: 0x14400000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 274.612827] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt ]---
[ 274.620387] ------------[ cut here ]------------
I'm also seeing the same failure on x86_64, and it reproduces
consistently.
From poking around it looks like the skb's dst entry is being used
to calculate the mtu in:
mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
...but because that dst_entry has an "ops" value set to md_dst_ops,
the various ops (including mtu) are not set:
crash> struct sk_buff._skb_refdst ffff928f87447700 -x
_skb_refdst = 0xffffcd6fbf5ea590
crash> struct dst_entry.ops 0xffffcd6fbf5ea590
ops = 0xffffffffa0193800
crash> struct dst_ops.mtu 0xffffffffa0193800
mtu = 0x0
crash>
I confirmed that the dst entry also has dst->input set to
dst_md_discard, so it looks like it's an entry that's been
initialized via __metadata_dst_init alright.
I think the fix here is to use skb_valid_dst(skb) - it checks
for DST_METADATA also, and with that fix in place, the
problem - which was previously 100% reproducible - disappears.
The below patch resolves the panic and all bpf tunnel tests pass
without incident.
Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
net/ipv4/ip_tunnel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 893f013..5dcf50c 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -515,9 +515,10 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
mtu = dst_mtu(&rt->dst) - dev->hard_header_len
- sizeof(struct iphdr) - tunnel_hlen;
else
- mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
+ mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
- skb_dst_update_pmtu(skb, mtu);
+ if (skb_valid_dst(skb))
+ skb_dst_update_pmtu(skb, mtu);
if (skb->protocol == htons(ETH_P_IP)) {
if (!skb_is_gso(skb) &&
@@ -530,9 +531,11 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
}
#if IS_ENABLED(CONFIG_IPV6)
else if (skb->protocol == htons(ETH_P_IPV6)) {
- struct rt6_info *rt6 = (struct rt6_info *)skb_dst(skb);
+ struct rt6_info *rt6;
__be32 daddr;
+ rt6 = skb_valid_dst(skb) ? (struct rt6_info *)skb_dst(skb) :
+ NULL;
daddr = md ? dst : tunnel->parms.iph.daddr;
if (rt6 && mtu < dst_mtu(skb_dst(skb)) &&
--
1.8.3.1
^ permalink raw reply related
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-18 12:33 UTC (permalink / raw)
To: Jose Abreu, Martin Blumenstingl
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <c80c1e5b-fed9-25ce-eb1b-258ac0135ce7@synopsys.com>
Hi,
i recognize the followin on my ethernet stats:
threshold: 1
tx_pkt_n: 1457325
rx_pkt_n: 5022405
normal_irq_n: 671738
rx_normal_irq_n: 606573
napi_poll: 784439
tx_normal_irq_n: 61061
tx_clean: 784439
tx_set_ic_bit: 58293
irq_receive_pmt_irq_n: 0
mmc_tx_irq_n: 0
mmc_rx_irq_n: 0
mmc_rx_csum_offload_irq_n: 0
-> irq_tx_path_in_lpi_mode_n: 382037
-> irq_tx_path_exit_lpi_mode_n: 382021
Is this normal ?
regards,
Simon
Am 18.02.2019 um 09:45 schrieb Jose Abreu:
> On 2/18/2019 8:42 AM, Jose Abreu wrote:
>> On 2/17/2019 2:48 PM, Martin Blumenstingl wrote:
>>> Jose, is my command for disabling offloading correct?
>> Yes, I think so. What about NIC statistics and logs ? ("ethtool
>> -S eth0", "dmesg | grep -i stmmac")
> And, "ifconfig eth0" after running the test.
>
>> Thanks,
>> Jose Miguel Abreu
>>
^ 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