* [net 0/2] DPAA fixes
From: Madalin Bucur @ 2018-06-28 12:26 UTC (permalink / raw)
To: davem, netdev; +Cc: linux-kernel, Madalin Bucur
A couple of fixes for the DPAA drivers, addressing an issue
with short UDP or TCP frames (with padding) that were marked
as having a wrong checksum and dropped by the FMan hardware
and a problem with the buffer used for the scatter-gather
table being too small as per the hardware requirements.
Madalin Bucur (2):
fsl/fman: fix parser reporting bad checksum on short frames
dpaa_eth: DPAA SGT needs to be 256B
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 15 ++++++++-------
drivers/net/ethernet/freescale/fman/fman_port.c | 8 ++++++++
2 files changed, 16 insertions(+), 7 deletions(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH v2 net-next 0/6] net sched actions: code style cleanup and fixes
From: Davide Caratti @ 2018-06-28 12:26 UTC (permalink / raw)
To: Roman Mashak, davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1530120815-13736-1-git-send-email-mrv@mojatatu.com>
On Wed, 2018-06-27 at 13:33 -0400, Roman Mashak wrote:
> The patchset fixes a few code stylistic issues and typos, as well as one
> detected by sparse semantic checker tool.
>
> No functional changes introduced.
>
> Patch 1 & 2 fix coding style bits caught by the checkpatch.pl script
> Patch 3 fixes an issue with a shadowed variable
> Patch 4 adds sizeof() operator instead of magic number for buffer length
> Patch 5 fixes typos in diagnostics messages
> Patch 6 explicitly sets unsigned char for bitwise operation
>
> v2:
> - submit for net-next
> - added Reviewed-by tags
> - use u8* instead of char* as per Davide Caratti suggestion
>
> Roman Mashak (6):
> net sched actions: fix coding style in pedit action
> net sched actions: fix coding style in pedit headers
> net sched actions: fix sparse warning
> net sched actions: use sizeof operator for buffer length
> net sched actions: fix misleading text strings in pedit action
> net sched actions: avoid bitwise operation on signed value in pedit
>
> include/net/tc_act/tc_pedit.h | 1 +
> include/uapi/linux/tc_act/tc_pedit.h | 9 ++++++--
> net/sched/act_pedit.c | 43 +++++++++++++++++++-----------------
> 3 files changed, 31 insertions(+), 22 deletions(-)
>
for the series:
Acked-by: Davide Caratti <dcaratti@redhat.com>
regards,
--
davide
^ permalink raw reply
* [PATCH] net: phy: DP83TC811: Fix diabling interrupts
From: Dan Murphy @ 2018-06-28 12:13 UTC (permalink / raw)
To: andrew, f.fainelli; +Cc: netdev, Dan Murphy
Fix a bug where INT_STAT1 was written twice and
INT_STAT2 was ignored when disabling interrupts.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/dp83tc811.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/dp83tc811.c b/drivers/net/phy/dp83tc811.c
index 081d99aa3985..49ac678eb2dc 100644
--- a/drivers/net/phy/dp83tc811.c
+++ b/drivers/net/phy/dp83tc811.c
@@ -222,7 +222,7 @@ static int dp83811_config_intr(struct phy_device *phydev)
if (err < 0)
return err;
- err = phy_write(phydev, MII_DP83811_INT_STAT1, 0);
+ err = phy_write(phydev, MII_DP83811_INT_STAT2, 0);
}
return err;
--
2.17.0.582.gccdcbd54c
^ permalink raw reply related
* Re: [PATCH 1/2] net: phy: DP83TC811: Add INT_STAT3
From: Andrew Lunn @ 2018-06-28 12:04 UTC (permalink / raw)
To: Dan Murphy; +Cc: f.fainelli, netdev
In-Reply-To: <98e615dd-3fa7-78b2-3401-13cae4916c14@ti.com>
> Yes I was debating whether to include this change in the patch or have it
> stand alone for stable back port.
>
> I will pull it out and cc stable
No need to CC stable. Base the patch on daveM net branch, and David
will do the rest.
You probably want to wait a week or two before sending the other
patches for net-next. You want net to be merged into net-next, in
order to avoid conflicts.
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: DP83TC811: Fix SGMII enable/disable
From: Dan Murphy @ 2018-06-28 11:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: f.fainelli, netdev
In-Reply-To: <20180628082006.GC16727@lunn.ch>
Andrew
On 06/28/2018 03:20 AM, Andrew Lunn wrote:
> On Wed, Jun 27, 2018 at 01:16:18PM -0500, Dan Murphy wrote:
>> If SGMII was selected in the DT then the device should
>> write the SGMII enable bit.
>>
>> If SGMII is not selected in the DT then the SGMII bit
>> should be disabled.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> arch/arm/configs/omap2plus_defconfig | 1 +
>> drivers/net/phy/dp83tc811.c | 20 +++++++++-----------
>> 2 files changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
>> index 06fb948ecfb3..30857d5b7a6c 100644
>> --- a/arch/arm/configs/omap2plus_defconfig
>> +++ b/arch/arm/configs/omap2plus_defconfig
>> @@ -182,6 +182,7 @@ CONFIG_TI_CPTS=y
>> CONFIG_AT803X_PHY=y
>> CONFIG_DP83848_PHY=y
>> CONFIG_DP83867_PHY=y
>> +CONFIG_DP83TC811_PHY=y
>> CONFIG_MICREL_PHY=y
>> CONFIG_SMSC_PHY=y
>> CONFIG_PPP=m
>
> Hi Dan
>
> This change does not belong here.
>
Correct I will remove it.
> Andrew
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: DP83TC811: Add INT_STAT3
From: Dan Murphy @ 2018-06-28 11:54 UTC (permalink / raw)
To: Andrew Lunn; +Cc: f.fainelli, netdev
In-Reply-To: <20180628081612.GB16727@lunn.ch>
Andrew
On 06/28/2018 03:16 AM, Andrew Lunn wrote:
>> err = phy_write(phydev, MII_DP83811_INT_STAT1, 0);
>> if (err < 0)
>> return err;
>>
>> - err = phy_write(phydev, MII_DP83811_INT_STAT1, 0);
>> + err = phy_write(phydev, MII_DP83811_INT_STAT2, 0);
>> + if (err < 0)
>> + return err;
>> +
>> + err = phy_write(phydev, MII_DP83811_INT_STAT3, 0);
>> }
>>
>
> Hi Dan
>
> This seems like a bug fix, and so should be in a patch of its own, for
> net, not net-next.
>
Yes I was debating whether to include this change in the patch or have it
stand alone for stable back port.
I will pull it out and cc stable
> Andrew
>
--
------------------
Dan Murphy
^ permalink raw reply
* [PATCH net 1/1] bnx2x: Fix receiving tx-timeout in error or recovery state.
From: Sudarsana Reddy Kalluru @ 2018-06-28 11:52 UTC (permalink / raw)
To: davem; +Cc: netdev, Ariel.Elior
Driver performs the internal reload when it receives tx-timeout event from
the OS. Internal reload might fail in some scenarios e.g., fatal HW issues.
In such cases OS still see the link, which would result in undesirable
functionalities such as re-generation of tx-timeouts.
The patch addresses this issue by indicating the link-down to OS when
tx-timeout is detected, and keeping the link in down state till the
internal reload is successful.
Please consider applying it to 'net' branch.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 6 ++++++
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 6 ++++++
3 files changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index d847e1b..be15061 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1533,6 +1533,7 @@ struct bnx2x {
struct link_vars link_vars;
u32 link_cnt;
struct bnx2x_link_report_data last_reported_link;
+ bool force_link_down;
struct mdio_if_info mdio;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 8cd73ff..af7b5a4 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -1261,6 +1261,11 @@ void __bnx2x_link_report(struct bnx2x *bp)
{
struct bnx2x_link_report_data cur_data;
+ if (bp->force_link_down) {
+ bp->link_vars.link_up = 0;
+ return;
+ }
+
/* reread mf_cfg */
if (IS_PF(bp) && !CHIP_IS_E1(bp))
bnx2x_read_mf_cfg(bp);
@@ -2817,6 +2822,7 @@ int bnx2x_nic_load(struct bnx2x *bp, int load_mode)
bp->pending_max = 0;
}
+ bp->force_link_down = false;
if (bp->port.pmf) {
rc = bnx2x_initial_phy_init(bp, load_mode);
if (rc)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 5b1ed24..57348f2 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -10279,6 +10279,12 @@ static void bnx2x_sp_rtnl_task(struct work_struct *work)
bp->sp_rtnl_state = 0;
smp_mb();
+ /* Immediately indicate link as down */
+ bp->link_vars.link_up = 0;
+ bp->force_link_down = true;
+ netif_carrier_off(bp->dev);
+ BNX2X_ERR("Indicating link is down due to Tx-timeout\n");
+
bnx2x_nic_unload(bp, UNLOAD_NORMAL, true);
/* When ret value shows failure of allocation failure,
* the nic is rebooted again. If open still fails, a error
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 2/5] net: emaclite: Simplify if-else statements
From: Joe Perches @ 2018-06-28 11:04 UTC (permalink / raw)
To: Radhey Shyam Pandey, davem, michal.simek, andrew
Cc: netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <1530171584-20673-3-git-send-email-radhey.shyam.pandey@xilinx.com>
On Thu, 2018-06-28 at 13:09 +0530, Radhey Shyam Pandey wrote:
> Remove else as it is not required with if doing a return.
> Fixes below checkpatch warning.
[]
> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
[]
> @@ -1052,13 +1051,13 @@ static bool get_bool(struct platform_device *ofdev, const char *s)
> {
> u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
>
> - if (p) {
> - return (bool)*p;
> - } else {
> + if (!p) {
> dev_warn(&ofdev->dev, "Parameter %s not found,"
> "defaulting to false\n", s);
Please coalesce the format onto a single line
and add the missing space after the comma.
> return false;
> }
> +
> + return (bool)*p;
> }
>
> static const struct net_device_ops xemaclite_netdev_ops;
^ permalink raw reply
* Re: [v3] ath10k: transmit queued frames after processing rx packets
From: Kalle Valo @ 2018-06-28 9:44 UTC (permalink / raw)
To: Niklas Cassel
Cc: netdev, linux-wireless, linux-kernel, ath10k, Kalle Valo,
Niklas Cassel, David S. Miller
In-Reply-To: <20180523221508.26391-1-niklas.cassel@linaro.org>
Niklas Cassel <niklas.cassel@linaro.org> wrote:
> When running iperf on ath10k SDIO, TX can stop working:
>
> iperf -c 192.168.1.1 -i 1 -t 20 -w 10K
> [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
> [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
> [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
> [ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec
> [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 0.0-10.3 sec 9.01 MBytes 7.32 Mbits/sec
>
> There are frames in the ieee80211_txq and there are frames that have
> been removed from from this queue, but haven't yet been sent on the wire
> (num_pending_tx).
>
> When num_pending_tx reaches max_num_pending_tx, we will stop the queues
> by calling ieee80211_stop_queues().
>
> As frames that have previously been sent for transmission
> (num_pending_tx) are completed, we will decrease num_pending_tx and wake
> the queues by calling ieee80211_wake_queue(). ieee80211_wake_queue()
> does not call wake_tx_queue, so we might still have frames in the
> queue at this point.
>
> While the queues were stopped, the socket buffer might have filled up,
> and in order for user space to write more, we need to free the frames
> in the queue, since they are accounted to the socket. In order to free
> them, we first need to transmit them.
>
> This problem cannot be reproduced on low-latency devices, e.g. pci,
> since they call ath10k_mac_tx_push_pending() from
> ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called
> on high-latency devices.
> Fix the problem by calling ath10k_mac_tx_push_pending(), after
> processing rx packets, just like for low-latency devices, also in the
> SDIO case. Since we are calling ath10k_mac_tx_push_pending() directly,
> we also need to export it.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
3f04950f32d5 ath10k: transmit queued frames after processing rx packets
--
https://patchwork.kernel.org/patch/10422451/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3] ath10k: transmit queued frames after processing rx packets
From: Kalle Valo @ 2018-06-28 9:44 UTC (permalink / raw)
To: Niklas Cassel
Cc: Kalle Valo, David S. Miller, Niklas Cassel, ath10k,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180523221508.26391-1-niklas.cassel@linaro.org>
Niklas Cassel <niklas.cassel@linaro.org> wrote:
> When running iperf on ath10k SDIO, TX can stop working:
>
> iperf -c 192.168.1.1 -i 1 -t 20 -w 10K
> [ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
> [ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
> [ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
> [ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec
> [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec
> [ 3] 0.0-10.3 sec 9.01 MBytes 7.32 Mbits/sec
>
> There are frames in the ieee80211_txq and there are frames that have
> been removed from from this queue, but haven't yet been sent on the wire
> (num_pending_tx).
>
> When num_pending_tx reaches max_num_pending_tx, we will stop the queues
> by calling ieee80211_stop_queues().
>
> As frames that have previously been sent for transmission
> (num_pending_tx) are completed, we will decrease num_pending_tx and wake
> the queues by calling ieee80211_wake_queue(). ieee80211_wake_queue()
> does not call wake_tx_queue, so we might still have frames in the
> queue at this point.
>
> While the queues were stopped, the socket buffer might have filled up,
> and in order for user space to write more, we need to free the frames
> in the queue, since they are accounted to the socket. In order to free
> them, we first need to transmit them.
>
> This problem cannot be reproduced on low-latency devices, e.g. pci,
> since they call ath10k_mac_tx_push_pending() from
> ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called
> on high-latency devices.
> Fix the problem by calling ath10k_mac_tx_push_pending(), after
> processing rx packets, just like for low-latency devices, also in the
> SDIO case. Since we are calling ath10k_mac_tx_push_pending() directly,
> we also need to export it.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
3f04950f32d5 ath10k: transmit queued frames after processing rx packets
--
https://patchwork.kernel.org/patch/10422451/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 01/15] nvmem: add support for cell lookups
From: Srinivas Kandagatla @ 2018-06-28 9:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, Russell King, Grygorii Strashko,
David S . Miller, Lukas Wunner, Rob Herring, Florian Fainelli,
Dan Carpenter, Ivan Khoronzhuk, David Lechner, Greg Kroah-Hartman,
Andrew Lunn, Linux ARM, Linux Kernel Mailing List, linux-omap,
netdev, Bartosz Golaszewski
In-Reply-To: <CAMRc=Md8TM+zLn=T=BQeVHG-PGAvx-PHrs9y1t5zhdYo+m0ovg@mail.gmail.com>
On 28/06/18 08:56, Bartosz Golaszewski wrote:
>> We should also have something like nvmem_remove_lookup_table() for
>> consistency, and it should ensure that it clears the cells entry too.
>>
> What do you mean by clearing the cells entry exactly?
I meant, Removing entry from the nvmem_cells list.
Initially I though we should remove the entry form nvmem_cells list,
but It would complicate this path if some consumer has reference to it.
So, just removing the lookup list should be good! Lets not worry about
removing from nvmem_cells list.
--srini
>
> Bart
>
^ permalink raw reply
* [PATCH net] cnic: tidy up a size calculation
From: Dan Carpenter @ 2018-06-28 9:31 UTC (permalink / raw)
To: David S. Miller; +Cc: Christophe JAILLET, Kees Cook, netdev, kernel-janitors
Static checkers complain that id_tbl->table points to longs and 4 bytes
is smaller than sizeof(long). But the since other side is dividing by
32 instead of sizeof(long), that means the current code works fine.
Anyway, it's more conventional to use the BITS_TO_LONGS() macro when
we're allocating a bitmap.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 30273a7717e2..4fd829b5e65d 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -660,7 +660,7 @@ static int cnic_init_id_tbl(struct cnic_id_tbl *id_tbl, u32 size, u32 start_id,
id_tbl->max = size;
id_tbl->next = next;
spin_lock_init(&id_tbl->lock);
- id_tbl->table = kcalloc(DIV_ROUND_UP(size, 32), 4, GFP_KERNEL);
+ id_tbl->table = kcalloc(BITS_TO_LONGS(size), sizeof(long), GFP_KERNEL);
if (!id_tbl->table)
return -ENOMEM;
^ permalink raw reply related
* Re: wcn36xx: Remove Unicode Byte Order Mark from testcode
From: Kalle Valo @ 2018-06-28 9:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Eyal Ilsar, David S . Miller, Arnd Bergmann, wcn36xx,
linux-wireless, netdev, linux-kernel, Geert Uytterhoeven
In-Reply-To: <1528375527-22761-1-git-send-email-geert@linux-m68k.org>
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Older gcc (< 4.4) doesn't like files starting with a Unicode BOM:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\357’ in program
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\273’ in program
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\277’ in program
>
> Remove the BOM, the rest of the file is plain ASCII anyway.
>
> Output of "file drivers/net/wireless/ath/wcn36xx/testmode.c" before:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c: C source, UTF-8 Unicode (with BOM) text
>
> and after:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c: C source, ASCII text
>
> Fixes: 87f825e6e246cee0 ("wcn36xx: Add support for Factory Test Mode (FTM)")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Ramon Fried <ramon.fried@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-current branch of ath.git, thanks.
371d5e9d99e1 wcn36xx: Remove Unicode Byte Order Mark from testcode
--
https://patchwork.kernel.org/patch/10451875/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net] atm: iphase: fix a 64 bit bug
From: Dan Carpenter @ 2018-06-28 9:24 UTC (permalink / raw)
To: Chas Williams; +Cc: linux-atm-general, netdev, kernel-janitors
The code assumes that there is 4 bytes in a pointer and it doesn't
allocate enough memory.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index ff81a576347e..82532c299bb5 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -1618,7 +1618,7 @@ static int rx_init(struct atm_dev *dev)
skb_queue_head_init(&iadev->rx_dma_q);
iadev->rx_free_desc_qhead = NULL;
- iadev->rx_open = kcalloc(4, iadev->num_vc, GFP_KERNEL);
+ iadev->rx_open = kcalloc(iadev->num_vc, sizeof(void *), GFP_KERNEL);
if (!iadev->rx_open) {
printk(KERN_ERR DEV_LABEL "itf %d couldn't get free page\n",
dev->number);
^ permalink raw reply related
* Re: [PATCH] bpfilter: fix user mode helper cross compilation
From: Matteo Croce @ 2018-06-28 9:23 UTC (permalink / raw)
To: akpm; +Cc: netdev
In-Reply-To: <20180627231709.01709545812b669e29e797f7@linux-foundation.org>
On Thu, Jun 28, 2018 at 6:17 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 20 Jun 2018 16:04:34 +0200 Matteo Croce <mcroce@redhat.com> wrote:
>
> > Use $(OBJDUMP) instead of literal 'objdump' to avoid
> > using host toolchain when cross compiling.
> >
>
> I'm still having issues here, with ld.
>
> x86_64 machine, ARCH=i386:
>
> y:/usr/src/25> make V=1 M=net/bpfilter
> test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
> echo >&2; \
> echo >&2 " ERROR: Kernel configuration is invalid."; \
> echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
> echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
> echo >&2 ; \
> /bin/false)
> mkdir -p net/bpfilter/.tmp_versions ; rm -f net/bpfilter/.tmp_versions/*
> make -f ./scripts/Makefile.build obj=net/bpfilter
> (cat /dev/null; echo kernel/net/bpfilter/bpfilter.ko;) > net/bpfilter/modules.order
> ld -m elf_i386 -r -o net/bpfilter/bpfilter.o net/bpfilter/bpfilter_kern.o net/bpfilter/bpfilter_umh.o ; scripts/mod/modpost net/bpfilter/bpfilter.o
> ld: i386:x86-64 architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386 output
> scripts/Makefile.build:530: recipe for target 'net/bpfilter/bpfilter.o' failed
> make[1]: *** [net/bpfilter/bpfilter.o] Error 1
> Makefile:1518: recipe for target '_module_net/bpfilter' failed
> make: *** [_module_net/bpfilter] Error 2
>
> y:/usr/src/25> ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.29.1
>
>
Hi Andrew,
That's because the Makefile does `HOSTCC:=$(CC)` which replaces the
tools compiler with the target one.
The problem is that for i386 and x86_64 the compiler is the same, it's
just called with different arguments, -m32 and -m64.
This ends up with mixed i386 and x86_64 binaries which obviously can't
link together.
Personally I think that we should add infrastructure to build target
progs like we do with hostprogs-y instead of keeping messing with
variables and flags. If you want a quick and dirty hack to build it,
I'm using this.
Regards,
diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
index 051dc18b8ccb..5de353cfd26b 100644
--- a/net/bpfilter/Makefile
+++ b/net/bpfilter/Makefile
@@ -5,8 +5,9 @@
hostprogs-y := bpfilter_umh
bpfilter_umh-objs := main.o
-HOSTCFLAGS += -I. -Itools/include/ -Itools/include/uapi
HOSTCC := $(CC)
+HOSTCFLAGS := $(KBUILD_CFLAGS) -I. -Itools/include/ -Itools/include/uapi
+HOSTLOADLIBES_bpfilter_umh := $(KBUILD_CFLAGS)
ifeq ($(CONFIG_BPFILTER_UMH), y)
# builtin bpfilter_umh should be compiled with -static
^ permalink raw reply related
* Re: [PATCH v12 03/10] netdev: cavium: octeon: Add Octeon III BGX Ethernet Nexus
From: Andrew Lunn @ 2018-06-28 8:41 UTC (permalink / raw)
To: Steven J. Hill; +Cc: netdev, Carlos Munoz, Chandrakala Chavva
In-Reply-To: <1530134719-19407-4-git-send-email-steven.hill@cavium.com>
> +static char *mix_port;
> +module_param(mix_port, charp, 0444);
> +MODULE_PARM_DESC(mix_port, "Specifies which ports connect to MIX interfaces.");
> +
> +static char *pki_port;
> +module_param(pki_port, charp, 0444);
> +MODULE_PARM_DESC(pki_port, "Specifies which ports connect to the PKI.");
Module parameters are generally not liked. Can you do without them?
> + /* One time request driver module */
> + if (is_mix) {
> + if (atomic_cmpxchg(&request_mgmt_once, 0, 1) == 0)
> + request_module_nowait("octeon_mgmt");
Why is this needed? So long as the driver has the needed properties,
udev should load the module.
Andrew
^ permalink raw reply
* Re: [PATCH v12 01/10] dt-bindings: Add Cavium Octeon Common Ethernet Interface.
From: Andrew Lunn @ 2018-06-28 8:35 UTC (permalink / raw)
To: Steven J. Hill; +Cc: netdev, Carlos Munoz, Chandrakala Chavva
In-Reply-To: <1530134719-19407-2-git-send-email-steven.hill@cavium.com>
> +- cavium,rx-clk-delay-bypass: Set to <1> to bypass the rx clock delay setting.
> + Needed by the Micrel PHY.
Could you explain this some more. Is it anything to do with RGMII delays?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH bpf 4/4] xsk: fix potential race in SKB TX completion code
From: Magnus Karlsson @ 2018-06-28 8:31 UTC (permalink / raw)
To: eric.dumazet
Cc: Karlsson, Magnus, Björn Töpel, Alexei Starovoitov,
Daniel Borkmann, Network Development, Zhang, Qi Z, pavel
In-Reply-To: <54fa1b60-ebae-94a2-8036-06df6c05307a@gmail.com>
On Wed, Jun 27, 2018 at 5:57 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 06/27/2018 07:02 AM, Magnus Karlsson wrote:
> > There was a potential race in the TX completion code for
> > the SKB case when the TX napi thread and the error path
> > of the sendmsg code could both call the SKB destructor
> > at the same time. Fixed by introducing a spin_lock in the
> > destructor.
>
>
> Wow, what is the impact on performance ?
>
> Please describe a bit more what is the problem.
One process enters the sendmsg code of an AF_XDP socket in order to
send a frame. The execution eventually trickles down to the driver
that is told to send the packet. However, it decides to drop the
packet due to some error condition (e.g., rings full) and frees the
SKB. This will trigger the SKB destructor and a completion will be
sent to the AF_XDP user space through its
single-producer/single-consumer queues.
At the same time a TX interrupt has fired on another core and it
dispatches the TX completion code in the driver. It does its HW
specific things and ends up freeing the SKB associated with the
transmitted packet. This will trigger the SKB destructor and a
completion will be sent to the AF_XDP user space through its
single-producer/single-consumer queues. With a pseudo call stack,
it would look like this:
Core 1:
sendmsg() being called in the application
netdev_start_xmit()
Driver entered through ndo_start_xmit
Driver decides to free the SKB for some reason (e.g., rings full)
Destructor of SKB called
xskq_produce_addr() is called to signal completion to user space
Core 2:
TX completion irq
NAPI loop
Driver irq handler for TX completions
Frees the SKB
Destructor of SKB called
xskq_produce_addr() is called to signal completion to user space
We now have a violation of the single-producer/single-consumer
principle for our queues as there are two threads trying to produce at
the same time on the same queue.
Let me know if this is clear enough and I will put it in the commit
message and submit a V2.
In regards to the performance, I get around 1.74 Mpps for txonly
before and after the introduction of the spinlock on my machine. There
is of course some impact due to the spin lock but it is in the less
significant digits that are too noisy for me to measure. But let us
say that the version without the spin lock got 1.745 Mpps in the best
case and the version with 1.735 Mpps in the worst case, then that
would mean a maximum drop in performance of 0.5%.
Will had some ideas in
https://www.spinics.net/lists/netdev/msg497859.html on how to improve
the performance of the TX SKB path for AF_XDP. We could always
implement these in order to try to recoup the performance loss due to
the spin lock.
/Magnus
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: DP83TC811: Fix SGMII enable/disable
From: Andrew Lunn @ 2018-06-28 8:20 UTC (permalink / raw)
To: Dan Murphy; +Cc: f.fainelli, netdev
In-Reply-To: <20180627181618.23463-2-dmurphy@ti.com>
On Wed, Jun 27, 2018 at 01:16:18PM -0500, Dan Murphy wrote:
> If SGMII was selected in the DT then the device should
> write the SGMII enable bit.
>
> If SGMII is not selected in the DT then the SGMII bit
> should be disabled.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> arch/arm/configs/omap2plus_defconfig | 1 +
> drivers/net/phy/dp83tc811.c | 20 +++++++++-----------
> 2 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index 06fb948ecfb3..30857d5b7a6c 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -182,6 +182,7 @@ CONFIG_TI_CPTS=y
> CONFIG_AT803X_PHY=y
> CONFIG_DP83848_PHY=y
> CONFIG_DP83867_PHY=y
> +CONFIG_DP83TC811_PHY=y
> CONFIG_MICREL_PHY=y
> CONFIG_SMSC_PHY=y
> CONFIG_PPP=m
Hi Dan
This change does not belong here.
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: DP83TC811: Add INT_STAT3
From: Andrew Lunn @ 2018-06-28 8:16 UTC (permalink / raw)
To: Dan Murphy; +Cc: f.fainelli, netdev
In-Reply-To: <20180627181618.23463-1-dmurphy@ti.com>
> err = phy_write(phydev, MII_DP83811_INT_STAT1, 0);
> if (err < 0)
> return err;
>
> - err = phy_write(phydev, MII_DP83811_INT_STAT1, 0);
> + err = phy_write(phydev, MII_DP83811_INT_STAT2, 0);
> + if (err < 0)
> + return err;
> +
> + err = phy_write(phydev, MII_DP83811_INT_STAT3, 0);
> }
>
Hi Dan
This seems like a bug fix, and so should be in a patch of its own, for
net, not net-next.
Andrew
^ permalink raw reply
* Re: [pull request][net 0/9] Mellanox, mlx5 fixes 2018-06-26
From: David Miller @ 2018-06-28 7:57 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz
In-Reply-To: <20180627002118.9856-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 26 Jun 2018 17:21:09 -0700
> This pull request includes fixes for mlx5 netdev and core driver,
> for more information please see the tag log below and for.
>
> Please pull and let me know if there's any issue.
Pulled.
> For -stable:
...
Queued up, thanks.
^ permalink raw reply
* Re: [PATCH v2 01/15] nvmem: add support for cell lookups
From: Bartosz Golaszewski @ 2018-06-28 7:56 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Sekhar Nori, Kevin Hilman, Russell King, Grygorii Strashko,
David S . Miller, Lukas Wunner, Rob Herring, Florian Fainelli,
Dan Carpenter, Ivan Khoronzhuk, David Lechner, Greg Kroah-Hartman,
Andrew Lunn, Linux ARM, Linux Kernel Mailing List, linux-omap,
netdev, Bartosz Golaszewski
In-Reply-To: <25ebceca-8cdd-edae-6393-dd29eb323c53@linaro.org>
2018-06-26 13:06 GMT+02:00 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>:
> Thanks for the patch,
>
> On 26/06/18 11:22, Bartosz Golaszewski wrote:
>>
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> We can currently only register nvmem cells from device tree or by
>> manually calling nvmem_add_cells(). The latter options however forces
>> users to make sure that the nvmem provider with which the cells are
>> associated is registered before the call.
>>
>> This patch proposes a new solution inspired by other frameworks that
>> offer resource lookups (GPIO, PWM etc.). It adds a function that allows
>> machine code to register nvmem lookup which are later lazily used to
>> add corresponding nvmem cells.
>>
> Overall the idea look fine to me.
>
> This needs to be documented in ./Documentation/nvmem/nvmem.txt
>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> drivers/nvmem/core.c | 57 +++++++++++++++++++++++++++++++++-
>> include/linux/nvmem-consumer.h | 6 ++++
>> include/linux/nvmem-provider.h | 6 ++++
>> 3 files changed, 68 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
>> index b5b0cdc21d01..a2e87b464319 100644
>> --- a/drivers/nvmem/core.c
>> +++ b/drivers/nvmem/core.c
>> @@ -62,6 +62,9 @@ static DEFINE_IDA(nvmem_ida);
>> static LIST_HEAD(nvmem_cells);
>> static DEFINE_MUTEX(nvmem_cells_mutex);
>> +static LIST_HEAD(nvmem_cell_lookups);
>> +static DEFINE_MUTEX(nvmem_lookup_mutex);
>> +
>> #ifdef CONFIG_DEBUG_LOCK_ALLOC
>> static struct lock_class_key eeprom_lock_key;
>> #endif
>> @@ -247,6 +250,23 @@ static const struct attribute_group
>> *nvmem_ro_root_dev_groups[] = {
>> NULL,
>> };
>> +/**
>> + * nvmem_register_lookup() - register a number of nvmem cell lookup
>> entries
>> + *
>
>
> Can we rename this to nvmem_add_lookup_table()?
> register sound bit heavy here.
>
> We should also have something like nvmem_remove_lookup_table() for
> consistency, and it should ensure that it clears the cells entry too.
>
What do you mean by clearing the cells entry exactly?
Bart
>
>> + * @lookup: array of nvmem cell lookup entries
>> + * @nentries: number of lookup entries in the array
>> + */
>> +void nvmem_register_lookup(struct nvmem_cell_lookup *lookup, size_t
>> nentries)
>> +{
>> + int i;
>> + > + mutex_lock(&nvmem_lookup_mutex);
>> + for (i = 0; i < nentries; i++)
>> + list_add_tail(&lookup[i].list, &nvmem_cell_lookups);
>> + mutex_unlock(&nvmem_lookup_mutex);
>> +}
>> +EXPORT_SYMBOL_GPL(nvmem_register_lookup);
>> +
>> static void nvmem_release(struct device *dev)
>> {
>> struct nvmem_device *nvmem = to_nvmem_device(dev);
>> @@ -916,6 +936,37 @@ struct nvmem_cell *of_nvmem_cell_get(struct
>> device_node *np,
>> EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
>> #endif
>>
^ permalink raw reply
* Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver
From: Arnd Bergmann @ 2018-06-28 7:53 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Ilias Apalodimas, Ivan Vecera, Florian Fainelli, Andrew Lunn,
Networking, ivan.khoronzhuk, Sekhar Nori,
Jiří Pírko, Francois Ozog, yogeshs, spatton,
Jose.Abreu
In-Reply-To: <88e01f4c-202e-565a-de22-d0ef20b6c989@ti.com>
On Thu, Jun 28, 2018 at 1:03 AM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
>
>
> On 06/27/2018 03:40 PM, Arnd Bergmann wrote:
>> On Wed, Jun 27, 2018 at 9:18 PM, Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>> On 06/22/2018 02:45 AM, Ilias Apalodimas wrote:
>>>> On Thu, Jun 21, 2018 at 05:31:31PM +0200, Arnd Bergmann wrote:
>>>>> On Thu, Jun 21, 2018 at 2:45 PM, Ilias Apalodimas
>>>>> <ilias.apalodimas@linaro.org> wrote:
>>>>>> On Thu, Jun 21, 2018 at 02:19:55PM +0200, Ivan Vecera wrote:
>>>>>
>>>>
>>>> If people like this idea, i can send a V3 with these changes.
>>>
>>> Nop. I do not think this is good idea, because "dual_mac" mode has very strict
>>> meaning and requirements. In "dual_mac" mode both port should be teated and work
>>> as *separate network devices" (like two, not connected PCI eth cards) - the fact that
>>> it's implemented on top of hw, which can do packet switching doesn't matter here and just a
>>> technical solution.
>>> Main requirements:
>>> 1) No packet forwarding is allowed inside hw under any circumstances, only Linux
>>> Host SW can consume or forward packets
>>> 2) One interface should not block another inside CPSW hw which implies special FIFOs/HW
>>> configuration
>>
>> Could you explain the reasoning behind those requirements? I honestly don't
>> see what difference it makes, given that a new driver with switchdev support
>> would look exactly like the dual_emac mode as long as you don't add the
>> two interfaces into a bridge, and the user-visible behavior is already required
>> to be the same.
>
> Am not aware of all details - it's custom filtering/routing/firewalling applications.
> (Like Industrial Ethernet (EtherCAT) to Ethernet converter on one port and
> another port is for control/monitoring purposes)
> And yes, it looks similar. But, as I mentioned, dual_mac mode required CPSW to be
> configured differently and reconfiguration during attaching to the bridge
> is very (very) problematic - first, FIFOs/HW configuration not expected to be done on the fly,
> second vlans 1/2 reserved for this mode while bridge uses vid 1 by default.
> In dual_mac mode port just switched to promiscuous mode when attached to the bridge.
> Using kernel configuration option will break multi-platform support as
> all CPSW instances will start behaving as switch.
I was referring to dynamically reconfiguring the device during switch
attachment (which you say is hard in the current driver, and I can believe that,
but it does seem like a problem that can be solved with a proper design),
and the kernel configuration must have no impact on the default behavior
in that case.
This would still meet the requirements for the use case you mention,
as one would definitely never want to bridge between an EtherCAT
interface and a management interface.
>>> As per, above switchdev functionality doesn't make too much sense in "dual_mac" mode and
>>> introducing dual meaning for this mode is not a good choice either.
>>>
>>> Again, as discussed, option 4 is considered as preferred.
>>
>> Do you mean creating an incompatible binding that could be implemented by
>> the same driver, or duplicating the driver with one copy of the old binding
>> and one copy for the new binding?
>
> The idea is to keep dual_mac and one port mode (60% of use cases) as is
> while create new driver for two port switch mode by refactoring existing driver and
> re-using generic parts as max as possible. Also, update bindings as there are
> a lot of ancient and obsolete DT definitions which still supported for compatibility
> reasons. And, yes, possibility to mix dual_mac and switchdev in one driver is
> considered, but postponed as it hard to implement now, and as the main target is
> to drop custom ioctl and switch to standard Linux interfaces for switch.
> One step at time.
But wouldn't that new driver have the exact same problem with reconfiguring
the device between the boot-time configuration that behaves like
dual_emac and the switch configuration once the switchdev gets attached?
Arnd
^ permalink raw reply
* Re: [PATCH v7 03/11] net: pch_gbe: Probe PHY ID & initialize only once
From: Andrew Lunn @ 2018-06-28 7:47 UTC (permalink / raw)
To: Paul Burton; +Cc: netdev, David S . Miller
In-Reply-To: <20180627000612.27263-4-paul.burton@mips.com>
On Tue, Jun 26, 2018 at 05:06:04PM -0700, Paul Burton wrote:
> The pch_gbe driver currently probes for the PHY ID & configures the PHY
> every time the MAC is reset, even though we know that the PHY won't have
> changed since the last MAC reset [1].
>
> This patch moves the PHY probe to instead happen only once when the
> driver is probed, saving time & moving us closer to the behavior we'll
> have with phylib.
>
> [1] Please, someone patent PHY hotplugging & rigorously enforce said
> patent such that nobody can do it. At least not with an EG20T MAC.
I suppose one additional point here is that with the change to phylib,
and the removal of the code to disable hibernation, the phyid becomes
irrelevant to the MAC driver. So the important change here is moving
phy initialization to the probe.
Andrew
^ permalink raw reply
* Re: [PATCH v7 09/11] net: pch_gbe: Convert to mdiobus and phylib
From: Andrew Lunn @ 2018-06-28 7:44 UTC (permalink / raw)
To: Paul Burton; +Cc: netdev, David S . Miller
In-Reply-To: <20180627180959.vruu7opexcncpqre@pburton-laptop>
> Would you prefer that the MAC driver instead selects the PHY drivers for
> all PHYs known to have been used with the MAC? Or would you be happy if
> I added the equivalent in patch 11:
Hi Paul
Generally, you don't list any specific PHY. All distribution kernels
simply enable all PHYs as kernel modules. Anybody building a cut down
kernel is supposed to know what modules they need for there hardware.
Andrew
^ 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