* Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake
From: Kai Heng Feng @ 2019-02-18 15:30 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Rafael J. Wysocki, Len Brown, jeffrey.t.kirsher, intel-wired-lan,
netdev, linux-acpi, linux-pci, linux-kernel
In-Reply-To: <20190204172057.GB9160@google.com>
> On Feb 4, 2019, at 6:20 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Sun, Feb 03, 2019 at 01:46:50AM +0800, Kai Heng Feng wrote:
>>> On Jan 28, 2019, at 3:51 PM, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
>>
>>>> If I understand correctly, the bugzilla lspci
>>>> (https://bugzilla.kernel.org/attachment.cgi?id=280691) was collected
>>>> at point 8, and it shows PME_Status=1 when it should be 0.
>>>>
>>>> If we write a 1 to PME_Status to clear it, and it remains set, that's
>>>> obviously a hardware defect, and Intel should document that in an
>>>> erratum, and a quirk would be the appropriate way to work around it.
>>>> But I doubt that's what's happening.
>>>
>>> I’ll ask them if they can provide an erratum.
>>
>> Got confirmed with e1000e folks, I219 (the device in question) doesn’t
>> really support runtime D3.
>
> Did you get a reference, e.g., an intel.com URL for that? Intel
> usually publishes errata for hardware defects, which is nice because
> it means every customer doesn't have to experimentally rediscover
> them.
Unfortunately no.
>
>> I also checked the behavior of the device under Windows, and it
>> stays at D0 all the time even when it’s not in use.
>
> I think there are two possible explanations for this:
>
> 1) This device requires a Windows or a driver update with a
> device-specific quirk similar to what you're proposing for Linux.
I am sure the latest driver is loaded under Windows.
>
> 2) Windows correctly detects that this device doesn't support D3,
> and Linux has a bug and does not detect that.
I think that’s the case.
>
> Obviously nobody wants to require OS or driver updates just for minor
> device changes, and the PCI and ACPI specs are designed to allow
> generic, non device-specific code to detect D3 support, so the first
> case should be a result of a hardware defect.
Yea, that’s why my original idea is to workaround it in PCI/ACPI.
>
>> So I sent a patch [1] to disable it.
>>
>> [1] https://lkml.org/lkml/2019/2/2/200
>
> OK. Since that's in drivers/net/..., I have no objection and the
> e1000e maintainers would deal with that.
Thanks.
Kai-Heng
>
> Bjorn
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-18 15:29 UTC (permalink / raw)
To: Jose Abreu, Martin Blumenstingl
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <84fb981c-75ab-ef9e-edd6-cd0c52d9dc36@synopsys.com>
Hi,
i tried your command and tested afterwards, no change in behaviour .
Can i reset the ethtool statistics for better overview ?
regards,
Simon
Am 18.02.2019 um 14:02 schrieb Jose Abreu:
> 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
* pull-request: wireless-drivers 2019-02-18
From: Kalle Valo @ 2019-02-18 15:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's one more pull request to net tree for 5.0. Please let me know if
you have any problems.
Kalle
The following changes since commit 8c22d81d55353209f8976074ffa9fb1085da0830:
MAINTAINERS: add entry for redpine wireless driver (2019-02-03 21:41:51 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2019-02-18
for you to fetch changes up to d04ca383860bef90a0dab4eb397907f7f05e839e:
mt76x0u: fix suspend/resume (2019-02-07 18:32:16 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 5.0
Hopefully the last set of fixes for 5.0, only fix this time.
mt76
* fix regression with resume on mt76x0u USB devices
----------------------------------------------------------------
Stanislaw Gruszka (1):
mt76x0u: fix suspend/resume
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 46 ++++++++++++++++---------
1 file changed, 29 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [PATCH] net/mlx4_en: fix spelling mistake: "quiting" -> "quitting"
From: Tariq Toukan @ 2019-02-18 14:54 UTC (permalink / raw)
To: Dan Carpenter, Tariq Toukan
Cc: Colin King, David S . Miller, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190218102557.GC17104@kadam>
On 2/18/2019 12:25 PM, Dan Carpenter wrote:
> On Mon, Feb 18, 2019 at 09:37:22AM +0000, Tariq Toukan wrote:
>>
>>
>> On 2/18/2019 1:03 AM, Colin King wrote:
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> There is a spelling mistake in a en_err error message. Fix it.
>>>
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>> ---
>>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>>> index 6b88881b8e35..c1438ae52a11 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>>> @@ -3360,7 +3360,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
>>> dev->addr_len = ETH_ALEN;
>>> mlx4_en_u64_to_mac(dev->dev_addr, mdev->dev->caps.def_mac[priv->port]);
>>> if (!is_valid_ether_addr(dev->dev_addr)) {
>>> - en_err(priv, "Port: %d, invalid mac burned: %pM, quiting\n",
>>> + en_err(priv, "Port: %d, invalid mac burned: %pM, quitting\n",
>>> priv->port, dev->dev_addr);
>>> err = -EINVAL;
>>> goto out;
>>>
>>
>> Hi Colin, thanks for your patch.
>>
>> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
>>
>> I would suggest adding a Fixes line, but looking into the history of the
>> typo, it went through many patches that modified this line but preserved
>> the typo.
>> Actually, it dates back to the very first commit that introduces mlx4
>> driver:
>>
>> Patches history:
>> 2b3ddf27f48c net/mlx4_core: Replace VF zero mac with random mac in mlx4_core
>> ef96f7d46ad8 net/mlx4_en: Handle unassigned VF MAC address correctly
>> 6bbb6d99f3d2 net/mlx4_en: Optimize Rx fast path filter checks
>> 453a60827735 mlx4_en: Giving interface name in debug messages
>> c27a02cd94d6 mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC
>>
>> I'm not sure what the "Fixes:" policy is in these cases.
>
> I wouldn't necessarily put a Fixes tag on this, because does fixing the
> spelling really count as a bugfix? It's borderline whether it's a fix
> or a cleanup.
>
> regards,
> daan carpenter
>
Thanks Dan, I'm fine with that.
^ permalink raw reply
* Re: [PATCH 0/2] ARM: dts: am335x-evm/evmsk: Fix PHY mode for ethernet
From: Tony Lindgren @ 2019-02-18 14:44 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: bcousson, linux-omap, devicetree, linux-arm-kernel, nsekhar,
grygorii.strashko, vkoul, netdev, f.fainelli, marc.w.gonzalez,
niklas.cassel
In-Reply-To: <20190218143629.28392-1-peter.ujfalusi@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [190218 14:36]:
> Hi,
>
> cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the
> ethernet networking on evmsk (and most likely on the evm as well):
> https://patchwork.ozlabs.org/patch/1028527/
>
> v1 patch to fix the situation:
> https://patchwork.ozlabs.org/patch/1040617/
>
> It turned out that the at803x driver is actually broken and need to be fixed
> along with the DT data.
>
> The following series is proposed to fix the driver:
> https://patchwork.ozlabs.org/project/netdev/list/?series=92611
>
> but the PHT mode needs to be switched to rgmii-id from rgmii-txid:
> The rx delay is enabled by default and the driver never disabled it so when
> asking rgmii-txid it actually got rgmii-id.
>
> The patch can be backported to stable, I have tested that it is not causing
> regression with the old, broken driver.
Can the dts changes be merged before the driver changes or
does it cause the phy to stop working?
Regards,
Tony
^ permalink raw reply
* RE: [PATCH net-next] bnx2x: Remove set but not used variable 'mfw_vn'
From: Sudarsana Reddy Kalluru @ 2019-02-18 14:40 UTC (permalink / raw)
To: YueHaibing, Ariel Elior, David S . Miller
Cc: GR-everest-linux-l2, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20190218121954.78928-1-yuehaibing@huawei.com>
>-----Original Message-----
>From: YueHaibing [mailto:yuehaibing@huawei.com]
>Sent: 18 February 2019 17:50
>To: Ariel Elior <aelior@marvell.com>; Sudarsana Reddy Kalluru
><skalluru@marvell.com>; David S . Miller <davem@davemloft.net>
>Cc: YueHaibing <yuehaibing@huawei.com>; GR-everest-linux-l2 <GR-everest-
>linux-l2@marvell.com>; netdev@vger.kernel.org; kernel-
>janitors@vger.kernel.org
>Subject: [PATCH net-next] bnx2x: Remove set but not used variable 'mfw_vn'
>
>Fixes gcc '-Wunused-but-set-variable' warning:
>
>drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function
>'bnx2x_get_hwinfo':
>drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11940:10: warning:
> variable 'mfw_vn' set but not used [-Wunused-but-set-variable]
>
>It's never used since introduction.
>
>Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>index 3b5b47e98c73..7c47be215a34 100644
>--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>@@ -11998,7 +11998,7 @@ static void validate_set_si_mode(struct bnx2x
>*bp) static int bnx2x_get_hwinfo(struct bnx2x *bp) {
> int /*abs*/func = BP_ABS_FUNC(bp);
>- int vn, mfw_vn;
>+ int vn;
> u32 val = 0, val2 = 0;
> int rc = 0;
>
>@@ -12083,12 +12083,10 @@ static int bnx2x_get_hwinfo(struct bnx2x *bp)
> /*
> * Initialize MF configuration
> */
>-
> bp->mf_ov = 0;
> bp->mf_mode = 0;
> bp->mf_sub_mode = 0;
> vn = BP_VN(bp);
>- mfw_vn = BP_FW_MB_IDX(bp);
>
> if (!CHIP_IS_E1(bp) && !BP_NOMCP(bp)) {
> BNX2X_DEV_INFO("shmem2base 0x%x, size %d, mfcfg offset
>%d\n",
>
>
Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: at803x: disable delay only for RGMII mode
From: Peter Ujfalusi @ 2019-02-18 14:40 UTC (permalink / raw)
To: Vinod Koul, David S Miller
Cc: linux-arm-msm, Bjorn Andersson, netdev, Niklas Cassel,
Andrew Lunn, Florian Fainelli, Nori, Sekhar, Marc Gonzalez
In-Reply-To: <20190218101853.4290-2-vkoul@kernel.org>
Hi Vinod,
On 18/02/2019 12.18, Vinod Koul wrote:
> Per "Documentation/devicetree/bindings/net/ethernet.txt" RGMII mode
> should not have delay in PHY wheras RGMII_ID and RGMII_RXID/RGMII_TXID
> can have delay in phy.
>
> So disable the delay only for RGMII mode and enable for other modes.
> Also treat the default case as disabled delays.
With https://patchwork.ozlabs.org/project/netdev/list/?series=92672
ethernet is working on am335x-evmsk. thank you:
Tested-by: Peter Ujfalusi <peter.ujflausi@ti.com>
> Fixes: cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode")
> Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/net/phy/at803x.c | 47 ++++++++++++++++++++++++++++++----------
> 1 file changed, 36 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index c6e7d800fd7a..dc1b13f7fc12 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -110,6 +110,18 @@ static int at803x_debug_reg_mask(struct phy_device *phydev, u16 reg,
> return phy_write(phydev, AT803X_DEBUG_DATA, val);
> }
>
> +static int at803x_enable_rx_delay(struct phy_device *phydev)
> +{
> + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0, 0,
> + AT803X_DEBUG_RX_CLK_DLY_EN);
> +}
> +
> +static int at803x_enable_tx_delay(struct phy_device *phydev)
> +{
> + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5, 0,
> + AT803X_DEBUG_TX_CLK_DLY_EN);
> +}
> +
> static int at803x_disable_rx_delay(struct phy_device *phydev)
> {
> return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0,
> @@ -255,23 +267,36 @@ static int at803x_config_init(struct phy_device *phydev)
> if (ret < 0)
> return ret;
>
> - if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
> - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> - phydev->interface == PHY_INTERFACE_MODE_RGMII) {
> - ret = at803x_disable_rx_delay(phydev);
> + /* The hardware register default is RX and TX delay enabled, so lets
> + * first disable the RX and TX delays in phy and enable them based
> + * on the mode selected
> + */
> + ret = at803x_disable_rx_delay(phydev);
> + if (ret < 0)
> + return ret;
> + ret = at803x_disable_tx_delay(phydev);
> + if (ret < 0)
> + return ret;
> +
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> + /* If RGMII_ID or RGMII_RXID are specified enable RX delay,
> + * otherwise keep it disabled
> + */
> + ret = at803x_enable_rx_delay(phydev);
> if (ret < 0)
> return ret;
> }
>
> - if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> - phydev->interface == PHY_INTERFACE_MODE_RGMII) {
> - ret = at803x_disable_tx_delay(phydev);
> - if (ret < 0)
> - return ret;
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> + /* If RGMII_ID or RGMII_TXID are specified enable TX delay,
> + * otherwise keep it disabled
> + */
> + ret = at803x_enable_tx_delay(phydev);
> }
>
> - return 0;
> + return ret;
> }
>
> static int at803x_ack_interrupt(struct phy_device *phydev)
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH 2/2] ARM: dts: am335x-evm: Fix PHY mode for ethernet
From: Peter Ujfalusi @ 2019-02-18 14:36 UTC (permalink / raw)
To: tony
Cc: bcousson, linux-omap, devicetree, linux-arm-kernel, nsekhar,
grygorii.strashko, vkoul, netdev, f.fainelli, marc.w.gonzalez,
niklas.cassel
In-Reply-To: <20190218143629.28392-1-peter.ujfalusi@ti.com>
The PHY must add both tx and rx delay and not only on the tx clock.
The board uses AR8031_AL1A PHY where the rx delay is enabled by default,
the tx dealy is disabled.
The reason why rgmii-txid worked because the rx delay was not disabled by
the driver so essentially we ended up with rgmii-id PHY mode.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/am335x-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index b67f5fee1469..dce5be5df97b 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -729,7 +729,7 @@
&cpsw_emac0 {
phy-handle = <ðphy0>;
- phy-mode = "rgmii-txid";
+ phy-mode = "rgmii-id";
};
&tscadc {
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: am335x-evm/evmsk: Fix PHY mode for ethernet
From: Peter Ujfalusi @ 2019-02-18 14:36 UTC (permalink / raw)
To: tony
Cc: bcousson, linux-omap, devicetree, linux-arm-kernel, nsekhar,
grygorii.strashko, vkoul, netdev, f.fainelli, marc.w.gonzalez,
niklas.cassel
Hi,
cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode") broke the
ethernet networking on evmsk (and most likely on the evm as well):
https://patchwork.ozlabs.org/patch/1028527/
v1 patch to fix the situation:
https://patchwork.ozlabs.org/patch/1040617/
It turned out that the at803x driver is actually broken and need to be fixed
along with the DT data.
The following series is proposed to fix the driver:
https://patchwork.ozlabs.org/project/netdev/list/?series=92611
but the PHT mode needs to be switched to rgmii-id from rgmii-txid:
The rx delay is enabled by default and the driver never disabled it so when
asking rgmii-txid it actually got rgmii-id.
The patch can be backported to stable, I have tested that it is not causing
regression with the old, broken driver.
Regards,
Peter
---
Peter Ujfalusi (2):
ARM: dts: am335x-evmsk: Fix PHY mode for ethernet
ARM: dts: am335x-evm: Fix PHY mode for ethernet
arch/arm/boot/dts/am335x-evm.dts | 2 +-
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH net-next] cfg80211: pmsr: use eth_broadcast_addr() to assign broadcast address
From: Dan Carpenter @ 2019-02-18 14:36 UTC (permalink / raw)
To: maowenan; +Cc: johannes, linux-wireless, kernel-janitors, netdev, kvalo
In-Reply-To: <927ff17c-c506-734f-fc27-796d4c8fba98@huawei.com>
On Mon, Feb 18, 2019 at 09:25:06PM +0800, maowenan wrote:
> Add kalle Valo in mail list.
>
> Hi Kalle Valo,
> Do you have any comments about this patch?
>
It's not done against a recent net-next so it doesn't apply.
Please give people a few days to reply for networking changes.
regards,
dan caprenter
^ permalink raw reply
* [PATCH 1/2] ARM: dts: am335x-evmsk: Fix PHY mode for ethernet
From: Peter Ujfalusi @ 2019-02-18 14:36 UTC (permalink / raw)
To: tony
Cc: bcousson, linux-omap, devicetree, linux-arm-kernel, nsekhar,
grygorii.strashko, vkoul, netdev, f.fainelli, marc.w.gonzalez,
niklas.cassel
In-Reply-To: <20190218143629.28392-1-peter.ujfalusi@ti.com>
The PHY must add both tx and rx delay and not only on the tx clock.
The board uses AR8031_AL1A PHY where the rx delay is enabled by default,
the tx dealy is disabled.
The reason why rgmii-txid worked because the rx delay was not disabled by
the driver so essentially we ended up with rgmii-id PHY mode.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 172c0224e7f6..b128998097ce 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -651,13 +651,13 @@
&cpsw_emac0 {
phy-handle = <ðphy0>;
- phy-mode = "rgmii-txid";
+ phy-mode = "rgmii-id";
dual_emac_res_vlan = <1>;
};
&cpsw_emac1 {
phy-handle = <ðphy1>;
- phy-mode = "rgmii-txid";
+ phy-mode = "rgmii-id";
dual_emac_res_vlan = <2>;
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* 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
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