* Re: [PATCH net-next v8 2/4] net: netcp: Add Keystone NetCP core ethernet driver
From: Paul Bolle @ 2015-01-20 17:26 UTC (permalink / raw)
To: Murali Karicheri
Cc: Wingman Kwok, Valentin Rothberg, davem, devicetree, linux-kernel,
netdev
In-Reply-To: <54BE8BEA.3000100@ti.com>
On Tue, 2015-01-20 at 12:10 -0500, Murali Karicheri wrote:
> On 01/20/2015 03:18 AM, Paul Bolle wrote:
> > On Thu, 2015-01-15 at 19:12 -0500, Murali Karicheri wrote:
> >> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> >> index 605dd90..e11bcfa 100644
> >> --- a/drivers/net/ethernet/ti/Kconfig
> >> +++ b/drivers/net/ethernet/ti/Kconfig
> >> @@ -73,12 +73,23 @@ config TI_CPSW
> >> config TI_CPTS
> >> boolean "TI Common Platform Time Sync (CPTS) Support"
> >> depends on TI_CPSW
> >> + depends on TI_CPSW || TI_KEYSTONE_NET
> >
> > You probably meant to add
> > || TI_KEYSTONE_NETCP
> >
> > here. Ie, add CP. But as this slipped through testing it _might_ not be
> > needed at all.
>
> Currently CPTS driver is not used for NetCP. So I want to remove the
> above Kconfig dependency from Kconfig and cpts.o from the Makefile. Do
> you expect me to send an incremental patch for this to the netdev list?
That's Dave's call. I think that Dave works with incremental patches
exclusively once things have hit (one of the trees that feed into)
linux-next.
> or can pick the attached patch that addresses this issue. Let me know.
I'm just the reporter. Please send it through the regular channels. That
would certainly include netdev.
Paul Bolle
^ permalink raw reply
* Re: [PATCH net-next v8 2/4] net: netcp: Add Keystone NetCP core ethernet driver
From: Murali Karicheri @ 2015-01-20 17:10 UTC (permalink / raw)
To: Paul Bolle
Cc: Wingman Kwok, Valentin Rothberg, davem, devicetree, linux-kernel,
netdev
In-Reply-To: <1421741935.9655.73.camel@x220>
[-- Attachment #1: Type: text/plain, Size: 4573 bytes --]
On 01/20/2015 03:18 AM, Paul Bolle wrote:
> Murali, Wingman,
>
> On Thu, 2015-01-15 at 19:12 -0500, Murali Karicheri wrote:
>> The network coprocessor (NetCP) is a hardware accelerator available in
>> Keystone SoCs that processes Ethernet packets. NetCP consists of following
>> hardware components
>>
>> 1 Gigabit Ethernet (GbE) subsystem with a Ethernet switch sub-module to
>> send and receive packets.
>> 2 Packet Accelerator (PA) module to perform packet classification
>> operations such as header matching, and packet modification operations
>> such as checksum generation.
>> 3 Security Accelerator(SA) capable of performing IPSec operations on
>> ingress/egress packets.
>> 4 An optional 10 Gigabit Ethernet Subsystem (XGbE) which includes a
>> 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates
>> per Ethernet port.
>> 5 Packet DMA and Queue Management Subsystem (QMSS) to enqueue and dequeue
>> packets and DMA the packets between memory and NetCP hardware components
>> described above.
>>
>> NetCP core driver make use of the Keystone Navigator driver API to allocate
>> DMA channel for the Ethenet device and to handle packet queue/de-queue,
>> Please refer API's in include/linux/soc/ti/knav_dma.h and
>> drivers/soc/ti/knav_qmss.h for details.
>>
>> NetCP driver consists of NetCP core driver and at a minimum Gigabit
>> Ethernet (GBE) module (1) driver to implement the Network device function.
>> Other modules (2,3) can be optionally added to achieve supported hardware
>> acceleration function. The initial version of the driver include NetCP
>> core driver and GBE driver modules.
>>
>> Please refer Documentation/devicetree/bindings/net/keystone-netcp.txt
>> for design of the driver.
>>
>> Cc: David Miller<davem@davemloft.net>
>> Cc: Rob Herring<robh+dt@kernel.org>
>> Cc: Grant Likely<grant.likely@linaro.org>
>> Cc: Santosh Shilimkar<santosh.shilimkar@kernel.org>
>> Cc: Pawel Moll<pawel.moll@arm.com>
>> Cc: Mark Rutland<mark.rutland@arm.com>
>> Cc: Ian Campbell<ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala<galak@codeaurora.org>
>>
>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>> Signed-off-by: Wingman Kwok<w-kwok2@ti.com>
>
> This patch is included as commit 84640e27f230 ("net: netcp: Add Keystone
> NetCP core ethernet driver") in today's linux-next. I noticed because a
> script I run on linux-next spotted a problem in it.
>
>> ---
>> MAINTAINERS | 7 +
>> drivers/net/ethernet/ti/Kconfig | 11 +
>> drivers/net/ethernet/ti/Makefile | 3 +
>> drivers/net/ethernet/ti/netcp.h | 229 ++++
>> drivers/net/ethernet/ti/netcp_core.c | 2141 ++++++++++++++++++++++++++++++++++
>> 5 files changed, 2391 insertions(+)
>> create mode 100644 drivers/net/ethernet/ti/netcp.h
>> create mode 100644 drivers/net/ethernet/ti/netcp_core.c
>>
>> [...]
>> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
>> index 605dd90..e11bcfa 100644
>> --- a/drivers/net/ethernet/ti/Kconfig
>> +++ b/drivers/net/ethernet/ti/Kconfig
>> @@ -73,12 +73,23 @@ config TI_CPSW
>> config TI_CPTS
>> boolean "TI Common Platform Time Sync (CPTS) Support"
>> depends on TI_CPSW
>> + depends on TI_CPSW || TI_KEYSTONE_NET
>
> You probably meant to add
> || TI_KEYSTONE_NETCP
>
> here. Ie, add CP. But as this slipped through testing it _might_ not be
> needed at all.
Paul,
Currently CPTS driver is not used for NetCP. So I want to remove the
above Kconfig dependency from Kconfig and cpts.o from the Makefile. Do
you expect me to send an incremental patch for this to the netdev list?
or can pick the attached patch that addresses this issue. Let me know.
Thanks.
Murali
>
>> select PTP_1588_CLOCK
>> ---help---
>> This driver supports the Common Platform Time Sync unit of
>> the CPSW Ethernet Switch. The unit can time stamp PTP UDP/IPv4
>> and Layer 2 packets, and the driver offers a PTP Hardware Clock.
>>
>> +config TI_KEYSTONE_NETCP
>> + tristate "TI Keystone NETCP Ethernet subsystem Support"
>> + depends on OF
>> + depends on KEYSTONE_NAVIGATOR_DMA&& KEYSTONE_NAVIGATOR_QMSS
>> + ---help---
>> + This driver supports TI's Keystone NETCP Ethernet subsystem.
>> +
>> + To compile this driver as a module, choose M here: the module
>> + will be called keystone_netcp.
>> +
>> config TLAN
>> tristate "TI ThunderLAN support"
>> depends on (PCI || EISA)
>
> Thanks,
>
>
> Paul Bolle
>
--
Murali Karicheri
Linux Kernel, Texas Instruments
[-- Attachment #2: 0001-net-netcp-remove-unused-kconfig-option-and-code.patch --]
[-- Type: text/x-diff, Size: 1532 bytes --]
>From 44838a357c691c70762be2978619c6967f0dd220 Mon Sep 17 00:00:00 2001
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Tue, 20 Jan 2015 12:08:43 -0500
Subject: [PATCH] net: netcp: remove unused kconfig option and code
Currently CPTS is built into the netcp driver even though there is no
call out to the CPTS driver. This patch removes the dependency in Kconfig
and remove cpts.o from the Makefile for NetCP.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
drivers/net/ethernet/ti/Kconfig | 2 +-
drivers/net/ethernet/ti/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index e11bcfa..824e376 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -73,7 +73,7 @@ config TI_CPSW
config TI_CPTS
boolean "TI Common Platform Time Sync (CPTS) Support"
depends on TI_CPSW
- depends on TI_CPSW || TI_KEYSTONE_NET
+ depends on TI_CPSW
select PTP_1588_CLOCK
---help---
This driver supports the Common Platform Time Sync unit of
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 465d03d..0a9813b 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -13,4 +13,4 @@ ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o
obj-$(CONFIG_TI_KEYSTONE_NETCP) += keystone_netcp.o
keystone_netcp-y := netcp_core.o netcp_ethss.o netcp_sgmii.o \
- netcp_xgbepcsr.o cpsw_ale.o cpts.o
+ netcp_xgbepcsr.o cpsw_ale.o
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
From: David Ahern @ 2015-01-20 17:07 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <1421679769.32277.15.camel@redhat.com>
On 1/19/15 8:02 AM, Hannes Frederic Sowa wrote:
>
> I would still prefer that we flush automatically generated addresses and
> only keep the static and permanent ones.
>
> What do you think?
Fine with me. Static addresses were the motivation of the patch.
David
^ permalink raw reply
* [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-20 17:06 UTC (permalink / raw)
To: netdev; +Cc: Harout Hedeshian
The kernel forcefully applies MTU values received in router
advertisements provided the new MTU is less than the current. This
behavior is undesirable when the user space is managing the MTU. Instead
a sysctl flag 'accept_ra_mtu' is introduced such that the user space
can control whether or not RA provided MTU updates should be applied. The
default behavior is unchanged; user space must explicitly set this flag
to 0 for RA MTUs to be ignored.
Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
---
Documentation/networking/ip-sysctl.txt | 7 +++++++
include/linux/ipv6.h | 1 +
include/uapi/linux/ipv6.h | 1 +
net/ipv6/addrconf.c | 10 ++++++++++
net/ipv6/ndisc.c | 2 +-
5 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 85b0221..a5e4c81 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1287,6 +1287,13 @@ accept_ra_rtr_pref - BOOLEAN
Functional default: enabled if accept_ra is enabled.
disabled if accept_ra is disabled.
+accept_ra_mtu - BOOLEAN
+ Apply the MTU value specified in RA option 5 (RFC4861). If
+ disabled, the MTU specified in the RA will be ignored.
+
+ Functional default: enabled if accept_ra is enabled.
+ disabled if accept_ra is disabled.
+
accept_redirects - BOOLEAN
Accept Redirects.
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index c694e7b..2805062 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -52,6 +52,7 @@ struct ipv6_devconf {
__s32 force_tllao;
__s32 ndisc_notify;
__s32 suppress_frag_ndisc;
+ __s32 accept_ra_mtu;
void *sysctl;
};
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 73cb02d..437a6a4 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -169,6 +169,7 @@ enum {
DEVCONF_SUPPRESS_FRAG_NDISC,
DEVCONF_ACCEPT_RA_FROM_LOCAL,
DEVCONF_USE_OPTIMISTIC,
+ DEVCONF_ACCEPT_RA_MTU,
DEVCONF_MAX
};
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d6b4f5d..7dcc065e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -201,6 +201,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.disable_ipv6 = 0,
.accept_dad = 1,
.suppress_frag_ndisc = 1,
+ .accept_ra_mtu = 1,
};
static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -238,6 +239,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.disable_ipv6 = 0,
.accept_dad = 1,
.suppress_frag_ndisc = 1,
+ .accept_ra_mtu = 1,
};
/* Check if a valid qdisc is available */
@@ -4380,6 +4382,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
array[DEVCONF_NDISC_NOTIFY] = cnf->ndisc_notify;
array[DEVCONF_SUPPRESS_FRAG_NDISC] = cnf->suppress_frag_ndisc;
array[DEVCONF_ACCEPT_RA_FROM_LOCAL] = cnf->accept_ra_from_local;
+ array[DEVCONF_ACCEPT_RA_MTU] = cnf->accept_ra_mtu;
}
static inline size_t inet6_ifla6_size(void)
@@ -5259,6 +5262,13 @@ static struct addrconf_sysctl_table
.proc_handler = proc_dointvec,
},
{
+ .procname = "accept_ra_mtu",
+ .data = &ipv6_devconf.accept_ra_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
/* sentinel */
}
},
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6828667..8a9d7c1 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1348,7 +1348,7 @@ skip_routeinfo:
}
}
- if (ndopts.nd_opts_mtu) {
+ if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
__be32 n;
u32 mtu;
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH V2 for 3.19 7/7] rtlwifi: rtl8192ee: Fix DMA stalls
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Troy Tan, netdev, Larry Finger, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger@lwfinger.net>
From: Troy Tan <troy_tan@realsil.com.cn>
There are instances where the DMA engine stalls. The new code detects
such stalls and restarts DMA without needing a power reset.
Signed-off-by: Troy Tan <troy_tan@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.18]
---
drivers/net/wireless/rtlwifi/rtl8192ee/hw.c | 140 +++++++++++++++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192ee/reg.h | 2 +
2 files changed, 142 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c
index 9199559..09bc43e 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c
@@ -1137,6 +1137,139 @@ void rtl92ee_enable_hw_security_config(struct ieee80211_hw *hw)
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_WPA_CONFIG, &sec_reg_value);
}
+static bool _rtl8192ee_check_pcie_dma_hang(struct rtl_priv *rtlpriv)
+{
+ u8 tmp;
+
+ /* write reg 0x350 Bit[26]=1. Enable debug port. */
+ tmp = rtl_read_byte(rtlpriv, REG_BACKDOOR_DBI_DATA + 3);
+ if (!(tmp & BIT(2))) {
+ rtl_write_byte(rtlpriv, REG_BACKDOOR_DBI_DATA + 3,
+ tmp | BIT(2));
+ mdelay(100); /* Suggested by DD Justin_tsai. */
+ }
+
+ /* read reg 0x350 Bit[25] if 1 : RX hang
+ * read reg 0x350 Bit[24] if 1 : TX hang
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_BACKDOOR_DBI_DATA + 3);
+ if ((tmp & BIT(0)) || (tmp & BIT(1))) {
+ RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
+ "CheckPcieDMAHang8192EE(): true!!\n");
+ return true;
+ }
+ return false;
+}
+
+static void _rtl8192ee_reset_pcie_interface_dma(struct rtl_priv *rtlpriv,
+ bool mac_power_on)
+{
+ u8 tmp;
+ bool release_mac_rx_pause;
+ u8 backup_pcie_dma_pause;
+
+ RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
+ "ResetPcieInterfaceDMA8192EE()\n");
+
+ /* Revise Note: Follow the document "PCIe RX DMA Hang Reset Flow_v03"
+ * released by SD1 Alan.
+ */
+
+ /* 1. disable register write lock
+ * write 0x1C bit[1:0] = 2'h0
+ * write 0xCC bit[2] = 1'b1
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_RSV_CTRL);
+ tmp &= ~(BIT(1) | BIT(0));
+ rtl_write_byte(rtlpriv, REG_RSV_CTRL, tmp);
+ tmp = rtl_read_byte(rtlpriv, REG_PMC_DBG_CTRL2);
+ tmp |= BIT(2);
+ rtl_write_byte(rtlpriv, REG_PMC_DBG_CTRL2, tmp);
+
+ /* 2. Check and pause TRX DMA
+ * write 0x284 bit[18] = 1'b1
+ * write 0x301 = 0xFF
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_RXDMA_CONTROL);
+ if (tmp & BIT(2)) {
+ /* Already pause before the function for another reason. */
+ release_mac_rx_pause = false;
+ } else {
+ rtl_write_byte(rtlpriv, REG_RXDMA_CONTROL, (tmp | BIT(2)));
+ release_mac_rx_pause = true;
+ }
+
+ backup_pcie_dma_pause = rtl_read_byte(rtlpriv, REG_PCIE_CTRL_REG + 1);
+ if (backup_pcie_dma_pause != 0xFF)
+ rtl_write_byte(rtlpriv, REG_PCIE_CTRL_REG + 1, 0xFF);
+
+ if (mac_power_on) {
+ /* 3. reset TRX function
+ * write 0x100 = 0x00
+ */
+ rtl_write_byte(rtlpriv, REG_CR, 0);
+ }
+
+ /* 4. Reset PCIe DMA
+ * write 0x003 bit[0] = 0
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_SYS_FUNC_EN + 1);
+ tmp &= ~(BIT(0));
+ rtl_write_byte(rtlpriv, REG_SYS_FUNC_EN + 1, tmp);
+
+ /* 5. Enable PCIe DMA
+ * write 0x003 bit[0] = 1
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_SYS_FUNC_EN + 1);
+ tmp |= BIT(0);
+ rtl_write_byte(rtlpriv, REG_SYS_FUNC_EN + 1, tmp);
+
+ if (mac_power_on) {
+ /* 6. enable TRX function
+ * write 0x100 = 0xFF
+ */
+ rtl_write_byte(rtlpriv, REG_CR, 0xFF);
+
+ /* We should init LLT & RQPN and
+ * prepare Tx/Rx descrptor address later
+ * because MAC function is reset.
+ */
+ }
+
+ /* 7. Restore PCIe autoload down bit
+ * write 0xF8 bit[17] = 1'b1
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_MAC_PHY_CTRL_NORMAL + 2);
+ tmp |= BIT(1);
+ rtl_write_byte(rtlpriv, REG_MAC_PHY_CTRL_NORMAL + 2, tmp);
+
+ /* In MAC power on state, BB and RF maybe in ON state,
+ * if we release TRx DMA here
+ * it will cause packets to be started to Tx/Rx,
+ * so we release Tx/Rx DMA later.
+ */
+ if (!mac_power_on) {
+ /* 8. release TRX DMA
+ * write 0x284 bit[18] = 1'b0
+ * write 0x301 = 0x00
+ */
+ if (release_mac_rx_pause) {
+ tmp = rtl_read_byte(rtlpriv, REG_RXDMA_CONTROL);
+ rtl_write_byte(rtlpriv, REG_RXDMA_CONTROL,
+ (tmp & (~BIT(2))));
+ }
+ rtl_write_byte(rtlpriv, REG_PCIE_CTRL_REG + 1,
+ backup_pcie_dma_pause);
+ }
+
+ /* 9. lock system register
+ * write 0xCC bit[2] = 1'b0
+ */
+ tmp = rtl_read_byte(rtlpriv, REG_PMC_DBG_CTRL2);
+ tmp &= ~(BIT(2));
+ rtl_write_byte(rtlpriv, REG_PMC_DBG_CTRL2, tmp);
+}
+
int rtl92ee_hw_init(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -1162,6 +1295,13 @@ int rtl92ee_hw_init(struct ieee80211_hw *hw)
rtlhal->fw_ps_state = FW_PS_STATE_ALL_ON_92E;
}
+ if (_rtl8192ee_check_pcie_dma_hang(rtlpriv)) {
+ RT_TRACE(rtlpriv, COMP_INIT, DBG_DMESG, "92ee dma hang!\n");
+ _rtl8192ee_reset_pcie_interface_dma(rtlpriv,
+ rtlhal->mac_func_enable);
+ rtlhal->mac_func_enable = false;
+ }
+
rtstatus = _rtl92ee_init_mac(hw);
rtl_write_byte(rtlpriv, 0x577, 0x03);
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/reg.h b/drivers/net/wireless/rtlwifi/rtl8192ee/reg.h
index 3f2a959..1eaa1fa 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/reg.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/reg.h
@@ -77,9 +77,11 @@
#define REG_HIMRE 0x00B8
#define REG_HISRE 0x00BC
+#define REG_PMC_DBG_CTRL2 0x00CC
#define REG_EFUSE_ACCESS 0x00CF
#define REG_HPON_FSM 0x00EC
#define REG_SYS_CFG1 0x00F0
+#define REG_MAC_PHY_CTRL_NORMAL 0x00F8
#define REG_SYS_CFG2 0x00FC
#define REG_CR 0x0100
--
2.1.2
^ permalink raw reply related
* [PATCH V2 for 3.19 6/7] rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, netdev, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger@lwfinger.net>
This driver utilizes a FIFO buffer for RX descriptors. There are four places
in the code where it calculates the number of free slots. Several of those
locations do the calculation incorrectly. To fix these and to prevent future
mistakes, a common inline routine is created.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [V3.18]
---
drivers/net/wireless/rtlwifi/pci.h | 7 +++++++
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 26 ++++++--------------------
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.h b/drivers/net/wireless/rtlwifi/pci.h
index 5e83230..d4567d1 100644
--- a/drivers/net/wireless/rtlwifi/pci.h
+++ b/drivers/net/wireless/rtlwifi/pci.h
@@ -325,4 +325,11 @@ static inline void pci_write32_async(struct rtl_priv *rtlpriv,
writel(val, (u8 __iomem *) rtlpriv->io.pci_mem_start + addr);
}
+static inline u16 calc_fifo_space(u16 rp, u16 wp)
+{
+ if (rp <= wp)
+ return RTL_PCI_MAX_RX_COUNT - 1 + rp - wp;
+ return rp - wp - 1;
+}
+
#endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index cb3cbb6..80658bdf 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -499,14 +499,7 @@ u16 rtl92ee_rx_desc_buff_remained_cnt(struct ieee80211_hw *hw, u8 queue_index)
if (!start_rx)
return 0;
- if ((last_read_point > (RX_DESC_NUM_92E / 2)) &&
- (read_point <= (RX_DESC_NUM_92E / 2))) {
- remind_cnt = RX_DESC_NUM_92E - write_point;
- } else {
- remind_cnt = (read_point >= write_point) ?
- (read_point - write_point) :
- (RX_DESC_NUM_92E - write_point + read_point);
- }
+ remind_cnt = calc_fifo_space(read_point, write_point);
if (remind_cnt == 0)
return 0;
@@ -568,10 +561,8 @@ u16 rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 q_idx)
current_tx_read_point = (u16)((tmp_4byte >> 16) & 0x0fff);
current_tx_write_point = (u16)((tmp_4byte) & 0x0fff);
- point_diff = ((current_tx_read_point > current_tx_write_point) ?
- (current_tx_read_point - current_tx_write_point) :
- (TX_DESC_NUM_92E - current_tx_write_point +
- current_tx_read_point));
+ point_diff = calc_fifo_space(current_tx_read_point,
+ current_tx_write_point);
rtlpci->tx_ring[q_idx].avl_desc = point_diff;
return point_diff;
@@ -973,11 +964,8 @@ void rtl92ee_set_desc(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
ring->cur_tx_wp = cur_tx_wp;
ring->cur_tx_rp = cur_tx_rp;
- point_diff = ((cur_tx_rp > cur_tx_wp) ?
- (cur_tx_rp - cur_tx_wp) :
- (TX_DESC_NUM_92E - 1 -
- cur_tx_wp + cur_tx_rp));
-
+ point_diff = calc_fifo_space(cur_tx_rp,
+ cur_tx_wp);
ring->avl_desc = point_diff;
}
}
@@ -1066,9 +1054,7 @@ bool rtl92ee_is_tx_desc_closed(struct ieee80211_hw *hw, u8 hw_queue, u16 index)
ring->cur_tx_wp = cur_tx_wp;
ring->cur_tx_rp = cur_tx_rp;
- point_diff = ((cur_tx_rp > cur_tx_wp) ?
- (cur_tx_rp - cur_tx_wp) :
- (TX_DESC_NUM_92E - cur_tx_wp + cur_tx_rp));
+ point_diff = calc_fifo_space(cur_tx_rp, cur_tx_wp);
ring->avl_desc = point_diff;
}
--
2.1.2
^ permalink raw reply related
* [PATCH V2 for 3.19 5/7] rtlwifi: rtl8192ee: Fix parsing of received packet
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Troy Tan, netdev, Larry Finger, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger@lwfinger.net>
From: Troy Tan <troy_tan@realsil.com.cn>
The firmware supplies two kinds of packets via the RX mechanism. Besides the
normal data received over the air, these packets may contain bluetooth status
and other information. The present code fails to detect which kind of
information was received.
Signed-off-by: Troy Tan <troy_tan@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [V3.18]
---
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 4 ++++
drivers/net/wireless/rtlwifi/rtl8192ee/trx.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index 1535680..cb3cbb6 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -354,6 +354,10 @@ bool rtl92ee_rx_query_desc(struct ieee80211_hw *hw,
struct ieee80211_hdr *hdr;
u32 phystatus = GET_RX_DESC_PHYST(pdesc);
+ if (GET_RX_STATUS_DESC_RPT_SEL(pdesc) == 0)
+ status->packet_report_type = NORMAL_RX;
+ else
+ status->packet_report_type = C2H_PACKET;
status->length = (u16)GET_RX_DESC_PKT_LEN(pdesc);
status->rx_drvinfo_size = (u8)GET_RX_DESC_DRV_INFO_SIZE(pdesc) *
RX_DRV_INFO_SIZE_UNIT;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
index c56f305..8f78ac9 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
@@ -542,6 +542,8 @@
LE_BITS_TO_4BYTE(__pdesc+8, 12, 4)
#define GET_RX_DESC_RX_IS_QOS(__pdesc) \
LE_BITS_TO_4BYTE(__pdesc+8, 16, 1)
+#define GET_RX_STATUS_DESC_RPT_SEL(__pdesc) \
+ LE_BITS_TO_4BYTE(__pdesc+8, 28, 1)
#define GET_RX_DESC_RXMCS(__pdesc) \
LE_BITS_TO_4BYTE(__pdesc+12, 0, 7)
--
2.1.2
^ permalink raw reply related
* [PATCH V2 for 3.19 2/7] rtlwifi: rtl8192ee: Fix handling of new style descriptors
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Troy Tan, netdev, Larry Finger, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger@lwfinger.net>
From: Troy Tan <troy_tan@realsil.com.cn>
The hardware and firmware for the RTL8192EE utilize a FIFO list of
descriptors. There were some problems with the initial implementation.
The worst of these failed to detect that the FIFO was becoming full,
which led to the device needing to be power cycled. As this condition
is not relevant to most of the devices supported by rtlwifi, a callback
routine was added to detect this situation. This patch implements the
necessary changes in the pci handler, and the linkage into the appropriate
rtl8192ee routine.
Signed-off-by: Troy Tan <troy_tan@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [V3.18]
---
drivers/net/wireless/rtlwifi/pci.c | 31 +++++++++++++++++++++-------
drivers/net/wireless/rtlwifi/rtl8192ee/sw.c | 3 +--
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 3 ++-
drivers/net/wireless/rtlwifi/rtl8192ee/trx.h | 2 +-
drivers/net/wireless/rtlwifi/wifi.h | 1 +
5 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index e25faac..a62170e 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -578,6 +578,13 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int prio)
else
entry = (u8 *)(&ring->desc[ring->idx]);
+ if (rtlpriv->cfg->ops->get_available_desc &&
+ rtlpriv->cfg->ops->get_available_desc(hw, prio) <= 1) {
+ RT_TRACE(rtlpriv, (COMP_INTR | COMP_SEND), DBG_DMESG,
+ "no available desc!\n");
+ return;
+ }
+
if (!rtlpriv->cfg->ops->is_tx_desc_closed(hw, prio, ring->idx))
return;
ring->idx = (ring->idx + 1) % ring->entries;
@@ -641,10 +648,9 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int prio)
ieee80211_tx_status_irqsafe(hw, skb);
- if ((ring->entries - skb_queue_len(&ring->queue))
- == 2) {
+ if ((ring->entries - skb_queue_len(&ring->queue)) <= 4) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
+ RT_TRACE(rtlpriv, COMP_ERR, DBG_DMESG,
"more desc left, wake skb_queue@%d, ring->idx = %d, skb_queue_len = 0x%x\n",
prio, ring->idx,
skb_queue_len(&ring->queue));
@@ -793,7 +799,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
rx_remained_cnt =
rtlpriv->cfg->ops->rx_desc_buff_remained_cnt(hw,
hw_queue);
- if (rx_remained_cnt < 1)
+ if (rx_remained_cnt == 0)
return;
} else { /* rx descriptor */
@@ -845,18 +851,18 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
else
skb_reserve(skb, stats.rx_drvinfo_size +
stats.rx_bufshift);
-
} else {
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
"skb->end - skb->tail = %d, len is %d\n",
skb->end - skb->tail, len);
- break;
+ dev_kfree_skb_any(skb);
+ goto new_trx_end;
}
/* handle command packet here */
if (rtlpriv->cfg->ops->rx_command_packet &&
rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
dev_kfree_skb_any(skb);
- goto end;
+ goto new_trx_end;
}
/*
@@ -906,6 +912,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
} else {
dev_kfree_skb_any(skb);
}
+new_trx_end:
if (rtlpriv->use_new_trx_flow) {
rtlpci->rx_ring[hw_queue].next_rx_rp += 1;
rtlpci->rx_ring[hw_queue].next_rx_rp %=
@@ -921,7 +928,6 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
rtlpriv->enter_ps = false;
schedule_work(&rtlpriv->works.lps_change_work);
}
-end:
skb = new_skb;
no_new:
if (rtlpriv->use_new_trx_flow) {
@@ -1685,6 +1691,15 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
}
}
+ if (rtlpriv->cfg->ops->get_available_desc &&
+ rtlpriv->cfg->ops->get_available_desc(hw, hw_queue) == 0) {
+ RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
+ "get_available_desc fail\n");
+ spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock,
+ flags);
+ return skb->len;
+ }
+
if (ieee80211_is_data_qos(fc)) {
tid = rtl_get_tid(skb);
if (sta) {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/sw.c b/drivers/net/wireless/rtlwifi/rtl8192ee/sw.c
index f30c916..27e28f1 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/sw.c
@@ -113,8 +113,6 @@ int rtl92ee_init_sw_vars(struct ieee80211_hw *hw)
RCR_HTC_LOC_CTRL |
RCR_AMF |
RCR_ACF |
- RCR_ADF |
- RCR_AICV |
RCR_ACRC32 |
RCR_AB |
RCR_AM |
@@ -241,6 +239,7 @@ static struct rtl_hal_ops rtl8192ee_hal_ops = {
.set_desc = rtl92ee_set_desc,
.get_desc = rtl92ee_get_desc,
.is_tx_desc_closed = rtl92ee_is_tx_desc_closed,
+ .get_available_desc = rtl92ee_get_available_desc,
.tx_polling = rtl92ee_tx_polling,
.enable_hw_sec = rtl92ee_enable_hw_security_config,
.init_sw_leds = rtl92ee_init_sw_leds,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index 51806ac..0a006c4 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -551,7 +551,7 @@ static u16 get_desc_addr_fr_q_idx(u16 queue_index)
return desc_address;
}
-void rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 q_idx)
+u16 rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 q_idx)
{
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -570,6 +570,7 @@ void rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 q_idx)
current_tx_read_point));
rtlpci->tx_ring[q_idx].avl_desc = point_diff;
+ return point_diff;
}
void rtl92ee_pre_fill_tx_bd_desc(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
index 45fd9db..c56f305 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
@@ -829,7 +829,7 @@ void rtl92ee_rx_check_dma_ok(struct ieee80211_hw *hw, u8 *header_desc,
u8 queue_index);
u16 rtl92ee_rx_desc_buff_remained_cnt(struct ieee80211_hw *hw,
u8 queue_index);
-void rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 queue_index);
+u16 rtl92ee_get_available_desc(struct ieee80211_hw *hw, u8 queue_index);
void rtl92ee_pre_fill_tx_bd_desc(struct ieee80211_hw *hw,
u8 *tx_bd_desc, u8 *desc, u8 queue_index,
struct sk_buff *skb, dma_addr_t addr);
diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
index 3b3453a..413c2ab 100644
--- a/drivers/net/wireless/rtlwifi/wifi.h
+++ b/drivers/net/wireless/rtlwifi/wifi.h
@@ -2172,6 +2172,7 @@ struct rtl_hal_ops {
void (*add_wowlan_pattern)(struct ieee80211_hw *hw,
struct rtl_wow_pattern *rtl_pattern,
u8 index);
+ u16 (*get_available_desc)(struct ieee80211_hw *hw, u8 q_idx);
};
struct rtl_intf_ops {
--
2.1.2
^ permalink raw reply related
* [PATCH V2 for 3.19 4/7] rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX write point
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA, Larry Finger, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
Initially, the routine to update the write point in the FIFO buffer was
coded to save CPU time by not doing the calculation every interrupt. This
was an error and results in TX hangs.
Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [V3.18]
---
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index 0a006c4..1535680 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -1049,8 +1049,7 @@ bool rtl92ee_is_tx_desc_closed(struct ieee80211_hw *hw, u8 hw_queue, u16 index)
static u8 stop_report_cnt;
struct rtl8192_tx_ring *ring = &rtlpci->tx_ring[hw_queue];
- /*checking Read/Write Point each interrupt wastes CPU */
- if (stop_report_cnt > 15 || !rtlpriv->link_info.busytraffic) {
+ {
u16 point_diff = 0;
u16 cur_tx_rp, cur_tx_wp;
u32 tmpu32 = 0;
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 for 3.19 3/7] rtlwifi: rtl8192ee: Fix adhoc fail
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA, Larry Finger, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
When the buffer descriptor index exceeds 2, then a TX HANG condition
will result.
Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [V3.18]
---
drivers/net/wireless/rtlwifi/rtl8192ee/fw.c | 6 +-----
drivers/net/wireless/rtlwifi/rtl8192ee/hw.c | 26 --------------------------
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/fw.c b/drivers/net/wireless/rtlwifi/rtl8192ee/fw.c
index 45c128b..c5d4b80 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/fw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/fw.c
@@ -666,7 +666,6 @@ void rtl92ee_set_fw_rsvdpagepkt(struct ieee80211_hw *hw, bool b_dl_finished)
struct sk_buff *skb = NULL;
u32 totalpacketlen;
- bool rtstatus;
u8 u1rsvdpageloc[5] = { 0 };
bool b_dlok = false;
@@ -728,10 +727,7 @@ void rtl92ee_set_fw_rsvdpagepkt(struct ieee80211_hw *hw, bool b_dl_finished)
memcpy((u8 *)skb_put(skb, totalpacketlen),
&reserved_page_packet, totalpacketlen);
- rtstatus = rtl_cmd_send_packet(hw, skb);
-
- if (rtstatus)
- b_dlok = true;
+ b_dlok = true;
if (b_dlok) {
RT_TRACE(rtlpriv, COMP_POWER, DBG_LOUD ,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c
index 47beb49..9199559 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/hw.c
@@ -85,29 +85,6 @@ static void _rtl92ee_enable_bcn_sub_func(struct ieee80211_hw *hw)
_rtl92ee_set_bcn_ctrl_reg(hw, 0, BIT(1));
}
-static void _rtl92ee_return_beacon_queue_skb(struct ieee80211_hw *hw)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
- struct rtl8192_tx_ring *ring = &rtlpci->tx_ring[BEACON_QUEUE];
- unsigned long flags;
-
- spin_lock_irqsave(&rtlpriv->locks.irq_th_lock, flags);
- while (skb_queue_len(&ring->queue)) {
- struct rtl_tx_buffer_desc *entry =
- &ring->buffer_desc[ring->idx];
- struct sk_buff *skb = __skb_dequeue(&ring->queue);
-
- pci_unmap_single(rtlpci->pdev,
- rtlpriv->cfg->ops->get_desc(
- (u8 *)entry, true, HW_DESC_TXBUFF_ADDR),
- skb->len, PCI_DMA_TODEVICE);
- kfree_skb(skb);
- ring->idx = (ring->idx + 1) % ring->entries;
- }
- spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock, flags);
-}
-
static void _rtl92ee_disable_bcn_sub_func(struct ieee80211_hw *hw)
{
_rtl92ee_set_bcn_ctrl_reg(hw, BIT(1), 0);
@@ -403,9 +380,6 @@ static void _rtl92ee_download_rsvd_page(struct ieee80211_hw *hw)
rtl_write_byte(rtlpriv, REG_DWBCN0_CTRL + 2,
bcnvalid_reg | BIT(0));
- /* Return Beacon TCB */
- _rtl92ee_return_beacon_queue_skb(hw);
^ permalink raw reply related
* [PATCH V2 for 3.19 1/7] rtlwifi: Remove logging statement that is no longer needed
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable
In-Reply-To: <1421773286-1039-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
In commit e9538cf4f907 ("rtlwifi: Fix error when accessing unmapped memory
in skb"), a printk was included to indicate that the condition had been
reached. There is now enough evidence from other users that the fix is
working. That logging statement can now be removed.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [V3.18]
---
drivers/net/wireless/rtlwifi/pci.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index c70efb9..e25faac 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -816,11 +816,8 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
/* get a new skb - if fail, old one will be reused */
new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
- if (unlikely(!new_skb)) {
- pr_err("Allocation of new skb failed in %s\n",
- __func__);
+ if (unlikely(!new_skb))
goto no_new;
- }
if (rtlpriv->use_new_trx_flow) {
buffer_desc =
&rtlpci->rx_ring[rxring_idx].buffer_desc
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 for 3.19 0/7] Fixes for rtl8192ee
From: Larry Finger @ 2015-01-20 17:01 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA
Kalle,
This is V2 of the patches for rtl8192ee to be applied to 3.19. They replace
all the patches submitted under the title '[PATCH for 3.19 0/3] rtlwifi:
Various updates/fixes". All are marked for backporting to 3.18.
The first of these removes a logging statement that is no longer needed.
Patches 1-6 are relatively small and should not be a problem for 3.19.
Patch 7 is quite a bit larger, and adds two new routines to detect
DMA stalls. I will understand if you want to defer that to -next; however,
it does fix a serious problem.
Larry
---
Larry Finger (2):
rtlwifi: Remove logging statement that is no longer needed
rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO
Troy Tan (5):
rtlwifi: rtl8192ee: Fix handling of new style descriptors
rtlwifi: rtl8192ee: Fix adhoc fail
rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX write
point
rtlwifi: rtl8192ee: Fix parsing of received packet
rtlwifi: rtl8192ee: Fix DMA stalls
drivers/net/wireless/rtlwifi/pci.c | 36 ++++--
drivers/net/wireless/rtlwifi/pci.h | 7 ++
drivers/net/wireless/rtlwifi/rtl8192ee/fw.c | 6 +-
drivers/net/wireless/rtlwifi/rtl8192ee/hw.c | 166 ++++++++++++++++++++++-----
drivers/net/wireless/rtlwifi/rtl8192ee/reg.h | 2 +
drivers/net/wireless/rtlwifi/rtl8192ee/sw.c | 3 +-
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 36 +++---
drivers/net/wireless/rtlwifi/rtl8192ee/trx.h | 4 +-
drivers/net/wireless/rtlwifi/wifi.h | 1 +
9 files changed, 192 insertions(+), 69 deletions(-)
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] rhashtable: rhashtable_remove() must unlink in both tbl and future_tbl
From: Thomas Graf @ 2015-01-20 16:58 UTC (permalink / raw)
To: davem, Ying Xue
Cc: richard.alpe@ericsson.com >> Richard Alpe, Netdev,
tipc-discussion
In-Reply-To: <54BDC30D.5000606@windriver.com>
As removals can occur during resizes, entries may be referred to from
both tbl and future_tbl when the removal is requested. Therefore
rhashtable_remove() must unlink the entry in both tables if this is
the case. The existing code did search both tables but stopped when it
hit the first match.
Failing to do so resulted in use after remove.
Fixes: 97defe1 ("rhashtable: Per bucket locks & deferred expansion/shrinking")
Reported-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
Ying: This should fix the panic that was at the end of your TIPC
related boot log. I'm still working on the use after free.
lib/rhashtable.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index a4449c4..b1aa10e 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -592,6 +592,7 @@ bool rhashtable_remove(struct rhashtable *ht, struct rhash_head *obj)
struct rhash_head *he;
spinlock_t *lock;
unsigned int hash;
+ bool ret = false;
rcu_read_lock();
tbl = rht_dereference_rcu(ht->tbl, ht);
@@ -609,17 +610,16 @@ restart:
}
rcu_assign_pointer(*pprev, obj->next);
- atomic_dec(&ht->nelems);
-
- spin_unlock_bh(lock);
-
- rhashtable_wakeup_worker(ht);
-
- rcu_read_unlock();
- return true;
+ ret = true;
+ break;
}
+ /* The entry may be linked in either 'tbl', 'future_tbl', or both.
+ * 'future_tbl' only exists for a short period of time during
+ * resizing. Thus traversing both is fine and the added cost is
+ * very rare.
+ */
if (tbl != rht_dereference_rcu(ht->future_tbl, ht)) {
spin_unlock_bh(lock);
@@ -632,9 +632,15 @@ restart:
}
spin_unlock_bh(lock);
+
+ if (ret) {
+ atomic_dec(&ht->nelems);
+ rhashtable_wakeup_worker(ht);
+ }
+
rcu_read_unlock();
- return false;
+ return ret;
}
EXPORT_SYMBOL_GPL(rhashtable_remove);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-20 16:56 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <006301d034d0$f9e10520$eda30f60$@codeaurora.org>
On 01/20/2015 05:48 PM, Harout Hedeshian wrote:
...
> I will upload v3 with the following changes:
> - Fix tab indentation in documentation
> - Remove changes from sysctl_binary.c and sysctl.h
> - Fixed netlink dumps
Sounds good, thanks!
^ permalink raw reply
* RE: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-20 16:48 UTC (permalink / raw)
To: 'Daniel Borkmann'; +Cc: netdev
In-Reply-To: <54BD8CB0.8050800@redhat.com>
> > diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> > index 73cb02d..437a6a4 100644
> > --- a/include/uapi/linux/ipv6.h
> > +++ b/include/uapi/linux/ipv6.h
> > @@ -169,6 +169,7 @@ enum {
> > DEVCONF_SUPPRESS_FRAG_NDISC,
> > DEVCONF_ACCEPT_RA_FROM_LOCAL,
> > DEVCONF_USE_OPTIMISTIC,
> > + DEVCONF_ACCEPT_RA_MTU,
> > DEVCONF_MAX
> > };
>
> You also need a corresponding ipv6_store_devconf() entry, otherwise
> netlink dumps will always see this setting as disabled.
I added the following:
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cdd70ed..5743293 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4378,6 +4378,7 @@ static inline void ipv6_store_devconf(struct
ipv6_devconf *cnf,
array[DEVCONF_NDISC_NOTIFY] = cnf->ndisc_notify;
array[DEVCONF_SUPPRESS_FRAG_NDISC] = cnf->suppress_frag_ndisc;
array[DEVCONF_ACCEPT_RA_FROM_LOCAL] = cnf->accept_ra_from_local;
+ array[DEVCONF_ACCEPT_RA_MTU] = cnf->accept_ra_mtu;
}
I will upload v3 with the following changes:
- Fix tab indentation in documentation
- Remove changes from sysctl_binary.c and sysctl.h
- Fixed netlink dumps
-- Sanity test results below --
As a quick test, I wrote a very simple utility to dump out the raw contents
of a RTM_NEWLINK event and tested it out on a UML instance by assigning some
easily identifiable (but meaningless) value:
root@debian-wheezy-template:/mnt/host# ./a.out &
root@debian-wheezy-template:/mnt/host# cd /proc/sys/net/ipv6/conf/eth0
root@debian-wheezy-template:/proc/sys/net/ipv6/conf/eth0# echo 90 >
accept_ra_mtu #should print the letter 'Z'
root@debian-wheezy-template:/proc/sys/net/ipv6/conf/eth0# ifconfig eth0 up
&& ifconfig eth0 down
Read 1152 bytes from the socket
0 1 2 3 4 5 6 7 8 9 A B C D E F
...<truncated>...
00000020| 09 00 03 00 65 74 68 30 00 00 00 00 08 00 0D 00 | ....eth0........
...<truncated>...
00000300| 00 00 00 00 00 00 00 00 5A 00 00 00 24 01 03 00 | ........Z...$...
root@debian-wheezy-template:/proc/sys/net/ipv6/conf/eth0# echo 89 >
accept_ra_mtu # should print the letter 'Y'
root@debian-wheezy-template:/proc/sys/net/ipv6/conf/eth0# ifconfig eth0 up
&& ifconfig eth0 down
Read 1152 bytes from the socket
0 1 2 3 4 5 6 7 8 9 A B C D E F
...<truncated>...
00000020| 09 00 03 00 65 74 68 30 00 00 00 00 08 00 0D 00 | ....eth0........
...<truncated>...
00000300| 00 00 00 00 00 00 00 00 59 00 00 00 24 01 03 00 | ........Y...$...
Thanks,
Harout
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH 11/11] usb: core: fix a race with usb_queue_reset_device()
From: Olivier Sobrie @ 2015-01-20 16:30 UTC (permalink / raw)
To: Alan Stern; +Cc: Jan Dumon, Greg Kroah-Hartman, linux-kernel, linux-usb, netdev
In-Reply-To: <Pine.LNX.4.44L0.1501201022360.1150-100000@iolanthe.rowland.org>
On Tue, Jan 20, 2015 at 10:26:30AM -0500, Alan Stern wrote:
> On Tue, 20 Jan 2015, Olivier Sobrie wrote:
>
> > When usb_queue_reset() is called it schedules a work in view of
> > resetting the usb interface. When the reset work is running, it
> > can be scheduled again (e.g. by the usb disconnect method of
> > the driver).
> >
> > Consider that the reset work is queued again while the reset work
> > is running and that this work leads to a forced unbinding of the
> > usb interface (e.g. because a driver is bound to the interface
> > and has no pre/post_reset methods - see usb_reset_device()).
> > In such condition, usb_unbind_interface() gets called and this
> > function calls usb_cancel_queued_reset() which does nothing
> > because the flag "reset_running" is set to 1. The second reset
> > work that has been scheduled is therefore not cancelled.
> > Later, the usb_reset_device() tries to rebind the interface.
> > If it fails, then the usb interface context which contain the
> > reset work struct is freed and it most likely crash when the
> > second reset work tries to be run.
>
> There was an earlier patch posted for testing (no results yet)
> affecting this same region of code:
>
> http://marc.info/?l=linux-usb&m=142064533924019&w=2
>
> It should fix the problem described here, because (among other things)
> it adds usb_get/put_intf calls to the delayed-reset routines.
Ok sorry I didn't see that patch. It looks indeed that it should
solve my problem.
I'll give it a try tomorrow.
Thank you,
--
Olivier
^ permalink raw reply
* Re: [PATCH net-next v8 2/4] net: netcp: Add Keystone NetCP core ethernet driver
From: Murali Karicheri @ 2015-01-20 15:55 UTC (permalink / raw)
To: Paul Bolle
Cc: Wingman Kwok, Valentin Rothberg, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1421741935.9655.73.camel@x220>
On 01/20/2015 03:18 AM, Paul Bolle wrote:
> Murali, Wingman,
>
> On Thu, 2015-01-15 at 19:12 -0500, Murali Karicheri wrote:
>> The network coprocessor (NetCP) is a hardware accelerator available in
>> Keystone SoCs that processes Ethernet packets. NetCP consists of following
>> hardware components
>>
>> 1 Gigabit Ethernet (GbE) subsystem with a Ethernet switch sub-module to
>> send and receive packets.
>> 2 Packet Accelerator (PA) module to perform packet classification
>> operations such as header matching, and packet modification operations
>> such as checksum generation.
>> 3 Security Accelerator(SA) capable of performing IPSec operations on
>> ingress/egress packets.
>> 4 An optional 10 Gigabit Ethernet Subsystem (XGbE) which includes a
>> 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates
>> per Ethernet port.
>> 5 Packet DMA and Queue Management Subsystem (QMSS) to enqueue and dequeue
>> packets and DMA the packets between memory and NetCP hardware components
>> described above.
>>
>> NetCP core driver make use of the Keystone Navigator driver API to allocate
>> DMA channel for the Ethenet device and to handle packet queue/de-queue,
>> Please refer API's in include/linux/soc/ti/knav_dma.h and
>> drivers/soc/ti/knav_qmss.h for details.
>>
>> NetCP driver consists of NetCP core driver and at a minimum Gigabit
>> Ethernet (GBE) module (1) driver to implement the Network device function.
>> Other modules (2,3) can be optionally added to achieve supported hardware
>> acceleration function. The initial version of the driver include NetCP
>> core driver and GBE driver modules.
>>
>> Please refer Documentation/devicetree/bindings/net/keystone-netcp.txt
>> for design of the driver.
>>
>> Cc: David Miller<davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> Cc: Rob Herring<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Grant Likely<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Santosh Shilimkar<santosh.shilimkar-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Pawel Moll<pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland<mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> Signed-off-by: Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>
>> Signed-off-by: Wingman Kwok<w-kwok2-l0cyMroinI0@public.gmane.org>
>
> This patch is included as commit 84640e27f230 ("net: netcp: Add Keystone
> NetCP core ethernet driver") in today's linux-next. I noticed because a
> script I run on linux-next spotted a problem in it.
>
>> ---
>> MAINTAINERS | 7 +
>> drivers/net/ethernet/ti/Kconfig | 11 +
>> drivers/net/ethernet/ti/Makefile | 3 +
>> drivers/net/ethernet/ti/netcp.h | 229 ++++
>> drivers/net/ethernet/ti/netcp_core.c | 2141 ++++++++++++++++++++++++++++++++++
>> 5 files changed, 2391 insertions(+)
>> create mode 100644 drivers/net/ethernet/ti/netcp.h
>> create mode 100644 drivers/net/ethernet/ti/netcp_core.c
>>
>> [...]
>> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
>> index 605dd90..e11bcfa 100644
>> --- a/drivers/net/ethernet/ti/Kconfig
>> +++ b/drivers/net/ethernet/ti/Kconfig
>> @@ -73,12 +73,23 @@ config TI_CPSW
>> config TI_CPTS
>> boolean "TI Common Platform Time Sync (CPTS) Support"
>> depends on TI_CPSW
>> + depends on TI_CPSW || TI_KEYSTONE_NET
>
> You probably meant to add
> || TI_KEYSTONE_NETCP
>
> here. Ie, add CP. But as this slipped through testing it _might_ not be
> needed at all.
Paul,
I will get back to you on this today.
Thanks
Murali
>
>> select PTP_1588_CLOCK
>> ---help---
>> This driver supports the Common Platform Time Sync unit of
>> the CPSW Ethernet Switch. The unit can time stamp PTP UDP/IPv4
>> and Layer 2 packets, and the driver offers a PTP Hardware Clock.
>>
>> +config TI_KEYSTONE_NETCP
>> + tristate "TI Keystone NETCP Ethernet subsystem Support"
>> + depends on OF
>> + depends on KEYSTONE_NAVIGATOR_DMA&& KEYSTONE_NAVIGATOR_QMSS
>> + ---help---
>> + This driver supports TI's Keystone NETCP Ethernet subsystem.
>> +
>> + To compile this driver as a module, choose M here: the module
>> + will be called keystone_netcp.
>> +
>> config TLAN
>> tristate "TI ThunderLAN support"
>> depends on (PCI || EISA)
>
> Thanks,
>
>
> Paul Bolle
>
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v8 0/4] net: Add Keystone NetCP ethernet driver support
From: Murali Karicheri @ 2015-01-20 15:53 UTC (permalink / raw)
To: David Miller
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150119.151106.822126941934010309.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 01/19/2015 03:11 PM, David Miller wrote:
> From: Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>
> Date: Thu, 15 Jan 2015 19:10:03 -0500
>
>> The Network Coprocessor (NetCP) is a hardware accelerator that processes
>> Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
>> switch sub-module to send and receive packets. NetCP also includes a packet
>> accelerator (PA) module to perform packet classification operations such as
>> header matching, and packet modification operations such as checksum
>> generation. NetCP can also optionally include a Security Accelerator(SA)
>> capable of performing IPSec operations on ingress/egress packets.
>>
>> Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
>> includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
>> 1Gb/s rates per Ethernet port.
>>
>> Both GBE and XGBE network processors supported using common driver. It
>> is also designed to handle future variants of NetCP.
>
> Series applied to net-next, thanks.
David,
Thanks a lot for applying this series. This helps us move forward to
work on the next set of patches.
Thanks
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 2/2] bnx2x: fix napi poll return value for repoll
From: Eric Dumazet @ 2015-01-20 15:44 UTC (permalink / raw)
To: Govindarajulu Varadarajan
Cc: Willem de Bruijn, davem, netdev, ariel.elior, ssujith, benve
In-Reply-To: <alpine.LNX.2.03.1501202027430.31736@ws.cisco>
On Tue, 2015-01-20 at 20:54 +0530, Govindarajulu Varadarajan wrote:
> On Tue, 20 Jan 2015, Eric Dumazet wrote:
>
> > On Tue, 2015-01-20 at 18:46 +0530, Govindarajulu Varadarajan wrote:
> >> With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi repoll
> >> is done only when work_done == budget. When in busy_poll is we return 0 in
> >> napi_poll. We should return budget. Also do not return workdone > budget.
> >>
> >
> > I am not sure.
> >
>
> This is based on f41281d02f8b94e136f78cb1b6a5d78182c222bd &
> 9dfa9a27b620640322588df399eb8f624b48d877
>
> I do not know about bnx2x, but in enic driver, when busy_poll is enables
> rq clean is not happening. This is because, in napi_poll() when
> work_done < budget, we do not repoll. At this point, enic has disables rq intr
> and has not called napi_complete. Driver assumes that napi will repoll.
> Which does not happen.
>
> Lot of drivers I have checked return full budget if they want to repoll.
> eg. mlx4_en_poll_rx_cq()
I was referring to the "workdone > budget" condition.
But yes, the fix about busy poll seems needed.
^ permalink raw reply
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Thomas Graf @ 2015-01-20 15:35 UTC (permalink / raw)
To: Patrick McHardy
Cc: davem, herbert, paulmck, ying.xue, netdev, netfilter-devel
In-Reply-To: <20150120152149.GA3012@acer.localdomain>
On 01/20/15 at 03:21pm, Patrick McHardy wrote:
> I think its preferrable to make the need to handle NETLINK_F_DUMP_INTR
> as noticable as possible and not hide it. Silent failure is the worst
> kind of failure.
I agree to that. The point here is to avoid unnecessary use of
NETLINK_F_DUMP_INTR if all entries fit into a single message buffer.
> Yeah. The point could be made that this is a regression though. We didn't
> require userspace to deal with interruptions before, and the behaviour
> was well defined and acceptable for most cases, its not anymore.
>
> So I think it should be handled by the kernel, without changes to
> userspace.
nl_table_lock was released between individual messages just like
ht->mutex is released with this change.
What changed is that inserts and removal can now occur *while* the
message is being constructed whereas previously they could only
occur between message construction periods. In either case, the dump
would end up missing entries or showing duplicates.
^ permalink raw reply
* Re: [PATCH net 2/2] bnx2x: fix napi poll return value for repoll
From: Govindarajulu Varadarajan @ 2015-01-20 15:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Govindarajulu Varadarajan, Willem de Bruijn, davem, netdev,
ariel.elior, ssujith, benve
In-Reply-To: <1421765644.4832.4.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 20 Jan 2015, Eric Dumazet wrote:
> On Tue, 2015-01-20 at 06:51 -0800, Eric Dumazet wrote:
>
>>>
>>> for_each_cos_in_tx_queue(fp, cos)
>>> if (bnx2x_tx_queue_has_work(fp->txdata_ptr[cos]))
>>> @@ -3187,7 +3187,7 @@ static int bnx2x_poll(struct napi_struct *napi, int budget)
>>> /* must not complete if we consumed full budget */
>>> if (work_done >= budget) {
>>> bnx2x_fp_unlock_napi(fp);
>>> - break;
>>> + return budget;
>>
>> This one looks fine.
>
> But its not necessary, as here budget == work_done.
>
> (work_done > budget) would be a bug from bnx2x_rx_int()
>
Yes, I missed that one. This change here is not needed.
Thanks
^ permalink raw reply
* Re: [PATCH 11/11] usb: core: fix a race with usb_queue_reset_device()
From: Alan Stern @ 2015-01-20 15:26 UTC (permalink / raw)
To: Olivier Sobrie
Cc: Jan Dumon, Greg Kroah-Hartman, linux-kernel, linux-usb, netdev
In-Reply-To: <1421756978-4093-12-git-send-email-olivier@sobrie.be>
On Tue, 20 Jan 2015, Olivier Sobrie wrote:
> When usb_queue_reset() is called it schedules a work in view of
> resetting the usb interface. When the reset work is running, it
> can be scheduled again (e.g. by the usb disconnect method of
> the driver).
>
> Consider that the reset work is queued again while the reset work
> is running and that this work leads to a forced unbinding of the
> usb interface (e.g. because a driver is bound to the interface
> and has no pre/post_reset methods - see usb_reset_device()).
> In such condition, usb_unbind_interface() gets called and this
> function calls usb_cancel_queued_reset() which does nothing
> because the flag "reset_running" is set to 1. The second reset
> work that has been scheduled is therefore not cancelled.
> Later, the usb_reset_device() tries to rebind the interface.
> If it fails, then the usb interface context which contain the
> reset work struct is freed and it most likely crash when the
> second reset work tries to be run.
There was an earlier patch posted for testing (no results yet)
affecting this same region of code:
http://marc.info/?l=linux-usb&m=142064533924019&w=2
It should fix the problem described here, because (among other things)
it adds usb_get/put_intf calls to the delayed-reset routines.
Alan Stern
^ permalink raw reply
* Re: [PATCH net 2/2] bnx2x: fix napi poll return value for repoll
From: Govindarajulu Varadarajan @ 2015-01-20 15:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: Govindarajulu Varadarajan, Willem de Bruijn, davem, netdev,
ariel.elior, ssujith, benve
In-Reply-To: <1421765480.4832.2.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 20 Jan 2015, Eric Dumazet wrote:
> On Tue, 2015-01-20 at 18:46 +0530, Govindarajulu Varadarajan wrote:
>> With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi repoll
>> is done only when work_done == budget. When in busy_poll is we return 0 in
>> napi_poll. We should return budget. Also do not return workdone > budget.
>>
>
> I am not sure.
>
This is based on f41281d02f8b94e136f78cb1b6a5d78182c222bd &
9dfa9a27b620640322588df399eb8f624b48d877
I do not know about bnx2x, but in enic driver, when busy_poll is enables
rq clean is not happening. This is because, in napi_poll() when
work_done < budget, we do not repoll. At this point, enic has disables rq intr
and has not called napi_complete. Driver assumes that napi will repoll.
Which does not happen.
Lot of drivers I have checked return full budget if they want to repoll.
eg. mlx4_en_poll_rx_cq()
^ permalink raw reply
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Patrick McHardy @ 2015-01-20 15:21 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, herbert, paulmck, ying.xue, netdev, netfilter-devel
In-Reply-To: <20150120145551.GH20315@casper.infradead.org>
On 20.01, Thomas Graf wrote:
> On 01/20/15 at 02:31pm, Patrick McHardy wrote:
> > On 20.01, Thomas Graf wrote:
> > > Lock out table resizes while dumping Netlink sockets to user space.
> > > This keeps disruptions to a minimum for readers which don't handle
> > > the NLM_F_DUMP_INTR flag.
> >
> > This doesn't lock them out for the duration of the entire dump of
> > course, so the benefit seems rather small. Still with this patch,
> > they will need to handle NLM_F_DUMP_INTR or will get unpredictable
> > behaviour, in which case I'd think it makes more sense to not even
> > try this, all it does is hide parts of the brokenness.
>
> If it would lock out the resize for the entire dump I would not have
> done patches 1 and 2 ;-)
>
> I does provide better behaviour if the whole dump fits into a single
> buffer or if it fits into 2 buffers and we are already dumping into
> the 2nd buffer when the resize occurs. Otherwise we will see resizes
> and thus tons of duplicates even in those scenarios even if no insert
> or removal occurs in parallel.
>
> In the case of Netlink diag that should be typical case. Most systems
> will not have 1000s of Netlink sockets in parallel.
I think its preferrable to make the need to handle NETLINK_F_DUMP_INTR
as noticable as possible and not hide it. Silent failure is the worst
kind of failure.
> > An alternative would be to set a flag in ht when a dump begins that
> > indicates to skip resizing operations and on the end of the dump
> > perform any resizing operations that might be necessary. Herbert
> > disagrees though and he might be right.
>
> I don't like the flag as it prevents resizes (and possibly rehashes
> further down the road) for a long period of time. The hashtable
> becomes attackable.
Yeah. The point could be made that this is a regression though. We didn't
require userspace to deal with interruptions before, and the behaviour
was well defined and acceptable for most cases, its not anymore.
So I think it should be handled by the kernel, without changes to
userspace.
^ permalink raw reply
* Re: [PATCH 04/11] hso: fix memory leak in hso_create_rfkill()
From: Olivier Sobrie @ 2015-01-20 15:10 UTC (permalink / raw)
To: Oliver Neukum
Cc: Jan Dumon, Greg Kroah-Hartman, linux-kernel, linux-usb, netdev
In-Reply-To: <1421759597.29486.22.camel@linux-0dmf.site>
On Tue, Jan 20, 2015 at 02:13:17PM +0100, Oliver Neukum wrote:
> On Tue, 2015-01-20 at 13:29 +0100, Olivier Sobrie wrote:
> > When the rfkill interface was created, a buffer containing the name
> > of the rfkill node was allocated. This buffer was never freed when the
> > device disappears.
> >
> > To fix the problem, we put the name given to rfkill_alloc() in
> > the hso_net structure.
> >
> > Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
> > ---
> > drivers/net/usb/hso.c | 12 +++---------
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> > index 470ef9e..a49ac2e 100644
> > --- a/drivers/net/usb/hso.c
> > +++ b/drivers/net/usb/hso.c
> > @@ -153,6 +153,7 @@ struct hso_net {
> > struct hso_device *parent;
> > struct net_device *net;
> > struct rfkill *rfkill;
> > + char name[8];
> >
> > struct usb_endpoint_descriptor *in_endp;
> > struct usb_endpoint_descriptor *out_endp;
> > @@ -2467,27 +2468,20 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
> > {
> > struct hso_net *hso_net = dev2net(hso_dev);
> > struct device *dev = &hso_net->net->dev;
> > - char *rfkn;
> >
> > - rfkn = kzalloc(20, GFP_KERNEL);
> > - if (!rfkn)
> > - dev_err(dev, "%s - Out of memory\n", __func__);
> > -
> > - snprintf(rfkn, 20, "hso-%d",
> > + snprintf(hso_net->name, sizeof(hso_net->name), "hso-%d",
> > interface->altsetting->desc.bInterfaceNumber);
>
> That number is not unique. Indeed it will be identical for all devices.
Indeed. That should be corrected too.
Thank you,
Olivier
^ 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