* Re: [PATCH] 8139too in linux-3.18.0: some potential bugs
From: Jia-Ju Bai @ 2014-12-20 14:15 UTC (permalink / raw)
To: 'Sergei Shtylyov', netdev, jgarzik, shangh
Sorry, I know your meaning.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
diff --git a/drivers/net/ethernet/realtek/8139too.c
b/drivers/net/ethernet/realtek/8139too.c
index 007b38c..f277c5f 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -782,11 +782,11 @@ static struct net_device *rtl8139_init_board(struct
pci_dev *pdev)
rc = pci_enable_device (pdev);
if (rc)
goto err_out;
+ disable_dev_on_err = 1;
rc = pci_request_regions (pdev, DRV_NAME);
if (rc)
goto err_out;
- disable_dev_on_err = 1;
pci_set_master (pdev);
@@ -1098,6 +1098,7 @@ static int rtl8139_init_one(struct pci_dev *pdev,
return 0;
err_out:
+ netif_napi_del(&tp->napi);
__rtl8139_cleanup_dev (dev);
pci_disable_device (pdev);
return i;
@@ -1112,6 +1113,7 @@ static void rtl8139_remove_one(struct pci_dev *pdev)
assert (dev != NULL);
cancel_delayed_work_sync(&tp->thread);
+ netif_napi_del(&tp->napi);
unregister_netdev (dev);
-----邮件原件-----
发件人: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
发送时间: 2014年12月20日 21:48
收件人: Jia-Ju Bai; netdev@vger.kernel.org; jgarzik@pobox.com;
shangh@realtek.com.tw
主题: Re: [PATCH] 8139too in linux-3.18.0: some potential bugs
On 12/20/2014 4:20 PM, Jia-Ju Bai wrote:
> I have actually tested 8139too driver on the real hardware(Realtek
> RTL8139D PCI Ethernet Controller), and find some potential bugs:
> The target file is drivers/net/ethernet/realtek/8139too.c, which is
> used to build 8139too.ko.
> (1) In the normal process of 8139too, netif_napi_add is called in
> rtl8139_init_one, but netif_napi_del is not called in rtl8139_remove_one.
> However, many other ethernet card drivers call them in pairs, even in
> the error handling paths, such as r8169 and igb.
> (2) In the normal process of 8139too, pci_enable_device and
> pci_disable_device are called in pairs in rtl8139_init_board(in
> rtl8139_init_one) and rtl8139_remove_one. However, when
> pci_enable_device has been called and pci_request_regions is failed in
> rtl8139_init_board, "err_out" segment in rtl8139_init_board is
> executed immediately to exit, but pci_disable_device is not called because
"disable_dev_on_err = 0".
Again, please fix one issue per patch.
> Meanwhile, I also write the patch to fix the bugs. I have run the
> patch on the hardware, it can work normally and fix the above bugs.
Too bad you didn't provide a sign-off...
WBR, Sergei
^ permalink raw reply related
* Re: [PATCH] e1000 in linux-3.18.0: a potential bug
From: Sergei Shtylyov @ 2014-12-20 14:15 UTC (permalink / raw)
To: Jia-Ju Bai, netdev
In-Reply-To: <000001d01c5c$dd9f2db0$98dd8910$@163.com>
On 12/20/2014 4:57 PM, Jia-Ju Bai wrote:
> Maybe the email can not be displayed fully...
It was displayed alright.
> I send my patch again:
There was no need, especially without the patch description.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] e1000 in linux-3.18.0: a potential bug
From: Jia-Ju Bai @ 2014-12-20 13:57 UTC (permalink / raw)
To: sergei.shtylyov, netdev
Maybe the email can not be displayed fully...
I send my patch again:
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 24f3986..f6def7b 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1004,7 +1004,7 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
/* make ready for any if (hw->...) below */
err = e1000_init_hw_struct(adapter, hw);
if (err)
- goto err_sw_init;
+ goto err_dma;
/* there is a workaround being applied below that limits
* 64-bit DMA addresses to 64-bit hardware. There are some
@@ -1239,8 +1239,9 @@ err_eeprom:
iounmap(hw->flash_address);
kfree(adapter->tx_ring);
kfree(adapter->rx_ring);
-err_dma:
err_sw_init:
+ netif_napi_del(&adapter->napi);
+err_dma:
err_mdio_ioremap:
iounmap(hw->ce4100_gbe_mdio_base_virt);
iounmap(hw->hw_addr);
@@ -1271,6 +1272,7 @@ static void e1000_remove(struct pci_dev *pdev)
e1000_down_and_stop(adapter);
e1000_release_manageability(adapter);
+ netif_napi_del(&adapter->napi);
unregister_netdev(netdev);
e1000_phy_hw_reset(hw);
^ permalink raw reply related
* Re: [PATCH] 8139too in linux-3.18.0: some potential bugs
From: Jia-Ju Bai @ 2014-12-20 13:53 UTC (permalink / raw)
To: sergei.shtylyov, netdev
I have written it in the e-mail. Does not it display??
Okay, I send it again:
diff --git a/drivers/net/ethernet/realtek/8139too.c
b/drivers/net/ethernet/realtek/8139too.c
index 007b38c..f277c5f 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -782,11 +782,11 @@ static struct net_device *rtl8139_init_board(struct
pci_dev *pdev)
rc = pci_enable_device (pdev);
if (rc)
goto err_out;
+ disable_dev_on_err = 1;
rc = pci_request_regions (pdev, DRV_NAME);
if (rc)
goto err_out;
- disable_dev_on_err = 1;
pci_set_master (pdev);
@@ -1098,6 +1098,7 @@ static int rtl8139_init_one(struct pci_dev *pdev,
return 0;
err_out:
+ netif_napi_del (&tp->napi);
__rtl8139_cleanup_dev (dev);
pci_disable_device (pdev);
return i;
@@ -1112,6 +1113,7 @@ static void rtl8139_remove_one(struct pci_dev *pdev)
assert (dev != NULL);
cancel_delayed_work_sync(&tp->thread);
+ netif_napi_del (&tp->napi);
unregister_netdev (dev);
^ permalink raw reply related
* Re: [PATCH] 8139too in linux-3.18.0: some potential bugs
From: Sergei Shtylyov @ 2014-12-20 13:48 UTC (permalink / raw)
To: Jia-Ju Bai, netdev, jgarzik, shangh
In-Reply-To: <001601d01c57$be1e65a0$3a5b30e0$@163.com>
On 12/20/2014 4:20 PM, Jia-Ju Bai wrote:
> I have actually tested 8139too driver on the real hardware(Realtek RTL8139D
> PCI Ethernet Controller), and find some potential bugs:
> The target file is drivers/net/ethernet/realtek/8139too.c, which is used to
> build 8139too.ko.
> (1) In the normal process of 8139too, netif_napi_add is called in
> rtl8139_init_one, but netif_napi_del is not called in rtl8139_remove_one.
> However, many other ethernet card drivers call them in pairs, even in the
> error handling paths, such as r8169 and igb.
> (2) In the normal process of 8139too, pci_enable_device and
> pci_disable_device are called in pairs in rtl8139_init_board(in
> rtl8139_init_one) and rtl8139_remove_one. However, when pci_enable_device
> has been called and pci_request_regions is failed in rtl8139_init_board,
> "err_out" segment in rtl8139_init_board is executed immediately to exit, but
> pci_disable_device is not called because "disable_dev_on_err = 0".
Again, please fix one issue per patch.
> Meanwhile, I also write the patch to fix the bugs. I have run the patch on
> the hardware, it can work normally and fix the above bugs.
Too bad you didn't provide a sign-off...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH]e100 in linux-3.18.0: some potential bugs
From: Sergei Shtylyov @ 2014-12-20 13:33 UTC (permalink / raw)
To: Jia-Ju Bai, todd.fujinaka; +Cc: netdev, Linux-nics, linux.nics, e1000-devel
In-Reply-To: <000001d01c28$41c937c0$c55ba740$@163.com>
Hello.
On 12/20/2014 10:40 AM, Jia-Ju Bai wrote:
> I have actually tested e100 driver on the real hardware(Intel 82559 PCI
> Ethernet Controller), and find some bugs:
> The target file is drivers/net/ethernet/intel/e100.c, which is used to build
> e100.ko.
> (1) The function pci_pool_create is called by e100_probe when initializing
> the ethernet card driver. But when pci_pool_create is failed, which means
> that it returns NULL to nic->cbs_pool, the system crash will happen. Because
> pci_pool_alloc (in e100_alloc_cbs in e100_up in e100_open) need to use
> nic->cbs_pool to allocate the resource, but it is NULL. I suggest that a
> check can be added in the code to detect whether pci_pool_create returns
> NULL.
> (2) In the normal process, netif_napi_add is called in e100_probe, but
> netif_napi_del is not called in e100_remove. However, many other ethernet
> card drivers call them in pairs, even in the error handling paths, such as
> r8169 and igb.
> Meanwhile, I also write the patch to fix the bugs. I have run the patch on
> the hardware, it can work normally and fix the above bugs.
> diff --git a/drivers/net/ethernet/intel/e100.c
> b/drivers/net/ethernet/intel/e100.c
> index 781065e..2631d3f 100644
> --- a/drivers/net/ethernet/intel/e100.c
> +++ b/drivers/net/ethernet/intel/e100.c
> @@ -2969,6 +2969,11 @@ static int e100_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> nic->params.cbs.max * sizeof(struct cb),
> sizeof(u32),
> 0);
> + if(!(nic->cbs_pool))
Oh, and the inner () not needed.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH]e100 in linux-3.18.0: some potential bugs
From: Sergei Shtylyov @ 2014-12-20 13:32 UTC (permalink / raw)
To: Jia-Ju Bai, todd.fujinaka; +Cc: netdev, Linux-nics, linux.nics, e1000-devel
In-Reply-To: <000001d01c28$41c937c0$c55ba740$@163.com>
On 12/20/2014 10:40 AM, Jia-Ju Bai wrote:
> I have actually tested e100 driver on the real hardware(Intel 82559 PCI
> Ethernet Controller), and find some bugs:
> The target file is drivers/net/ethernet/intel/e100.c, which is used to build
> e100.ko.
> (1) The function pci_pool_create is called by e100_probe when initializing
> the ethernet card driver. But when pci_pool_create is failed, which means
> that it returns NULL to nic->cbs_pool, the system crash will happen. Because
> pci_pool_alloc (in e100_alloc_cbs in e100_up in e100_open) need to use
> nic->cbs_pool to allocate the resource, but it is NULL. I suggest that a
> check can be added in the code to detect whether pci_pool_create returns
> NULL.
> (2) In the normal process, netif_napi_add is called in e100_probe, but
> netif_napi_del is not called in e100_remove. However, many other ethernet
> card drivers call them in pairs, even in the error handling paths, such as
> r8169 and igb.
Fixing one issue per patch is the rule of thumb.
> Meanwhile, I also write the patch to fix the bugs. I have run the patch on
> the hardware, it can work normally and fix the above bugs.
Again, your sign-off is required. See Documentation/SubmittingPatches.
> diff --git a/drivers/net/ethernet/intel/e100.c
> b/drivers/net/ethernet/intel/e100.c
> index 781065e..2631d3f 100644
> --- a/drivers/net/ethernet/intel/e100.c
> +++ b/drivers/net/ethernet/intel/e100.c
> @@ -2969,6 +2969,11 @@ static int e100_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> nic->params.cbs.max * sizeof(struct cb),
> sizeof(u32),
> 0);
> + if(!(nic->cbs_pool))
Space needed after *if*. Please run your patches thru scripts/checkpatch.pl.
[...]
WBR, Sergei
^ permalink raw reply
* [PATCH] ne2k+8390 in linux-3.18.0: some potential bugs
From: Jia-Ju Bai @ 2014-12-20 13:27 UTC (permalink / raw)
To: netdev
I have actually tested ne2k+8390 driver on the real hardware(Realtek RTL8029
PCI Ethernet Controller), and find some potential bugs:
The target file is drivers/net/ethernet/8390/ne2k-pci.c, which is used to
build ne2k-pci.ko.
(1) The function request_region is called by ne2k_pci_init_one when
initializing the ethernet card driver. But when request_region is failed,
which means that it returns the error value, ne2k_pci_init_one returns
immediately to halt the process. However, because pci_enable_device has been
called before request_region in ne2k_pci_init_one, pci_disable_device should
be called before exiting. When the driver works normally, pci_enable_device
and pci_disable_device are called in pairs in ne2k_pci_init_one and
ne2k_pci_remove_one. Moreover, other ethernet card drivers call
pci_enable_device and pci_disable_device in pairs in error handling paths,
such as r8169 and sky2.
(2) The similar problem occurs when alloc_ei_netdev is failed in
ne2k_pci_init_one.
(3) The similar problem occurs when register_netdev is failed in
ne2k_pci_init_one.
Meanwhile, I also write the patch to fix the bugs. I have run the patch on
the hardware, it can work normally and fix the above bugs.
diff --git a/drivers/net/ethernet/8390/ne2k-pci.c
b/drivers/net/ethernet/8390/ne2k-pci.c
index 89c8d9f..f241c6b 100644
--- a/drivers/net/ethernet/8390/ne2k-pci.c
+++ b/drivers/net/ethernet/8390/ne2k-pci.c
@@ -246,13 +246,13 @@ static int ne2k_pci_init_one(struct pci_dev *pdev,
if (!ioaddr || ((pci_resource_flags (pdev, 0) & IORESOURCE_IO) ==
0)) {
dev_err(&pdev->dev, "no I/O resource at PCI BAR #0\n");
- return -ENODEV;
+ goto err_out;
}
if (request_region (ioaddr, NE_IO_EXTENT, DRV_NAME) == NULL) {
dev_err(&pdev->dev, "I/O resource 0x%x @ 0x%lx busy\n",
NE_IO_EXTENT, ioaddr);
- return -EBUSY;
+ goto err_out;
}
reg0 = inb(ioaddr);
@@ -392,6 +392,8 @@ err_out_free_netdev:
free_netdev (dev);
err_out_free_res:
release_region (ioaddr, NE_IO_EXTENT);
+err_out:
+ pci_disable_device (pdev);
return -ENODEV;
}
Thanks!
^ permalink raw reply related
* Re: [PATCH] e1000 in linux-3.18.0: a potential bug
From: Sergei Shtylyov @ 2014-12-20 13:27 UTC (permalink / raw)
To: Jia-Ju Bai, todd.fujinaka, netdev; +Cc: linux.nics, e1000-devel
In-Reply-To: <000d01d01c29$a9edb870$fdc92950$@163.com>
Hello.
On 12/20/2014 10:50 AM, Jia-Ju Bai wrote:
> I have actually tested e1000 driver on the real hardware(Intel 82540EM PCI
> Gigabit Ethernet Controller), and find a potential bug:
> The target file is drivers/net/ethernet/intel/e1000/e1000_main.c, which is
> used to build e1000.ko.
> (1) In the normal process, netif_napi_add is called in e1000_probe, but
> netif_napi_del is not called in e1000_remove. However, many other ethernet
> card drivers call them in pairs, even in the error handling paths, such as
> r8169 and igb.
> Meanwhile, I also write the patch to fix the bug. I have run the patch on
> the hardware, it can work normally and fix the above bug.
You didn't sign off on your patch, so it can't be applied.
WBR, Sergei
^ permalink raw reply
* [PATCH] 8139too in linux-3.18.0: some potential bugs
From: Jia-Ju Bai @ 2014-12-20 13:20 UTC (permalink / raw)
To: netdev, jgarzik, shangh
I have actually tested 8139too driver on the real hardware(Realtek RTL8139D
PCI Ethernet Controller), and find some potential bugs:
The target file is drivers/net/ethernet/realtek/8139too.c, which is used to
build 8139too.ko.
(1) In the normal process of 8139too, netif_napi_add is called in
rtl8139_init_one, but netif_napi_del is not called in rtl8139_remove_one.
However, many other ethernet card drivers call them in pairs, even in the
error handling paths, such as r8169 and igb.
(2) In the normal process of 8139too, pci_enable_device and
pci_disable_device are called in pairs in rtl8139_init_board(in
rtl8139_init_one) and rtl8139_remove_one. However, when pci_enable_device
has been called and pci_request_regions is failed in rtl8139_init_board,
"err_out" segment in rtl8139_init_board is executed immediately to exit, but
pci_disable_device is not called because "disable_dev_on_err = 0".
Meanwhile, I also write the patch to fix the bugs. I have run the patch on
the hardware, it can work normally and fix the above bugs.
diff --git a/drivers/net/ethernet/realtek/8139too.c
b/drivers/net/ethernet/realtek/8139too.c
index 007b38c..f277c5f 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -782,11 +782,11 @@ static struct net_device *rtl8139_init_board(struct
pci_dev *pdev)
rc = pci_enable_device (pdev);
if (rc)
goto err_out;
+ disable_dev_on_err = 1;
rc = pci_request_regions (pdev, DRV_NAME);
if (rc)
goto err_out;
- disable_dev_on_err = 1;
pci_set_master (pdev);
@@ -1098,6 +1098,7 @@ static int rtl8139_init_one(struct pci_dev *pdev,
return 0;
err_out:
+ netif_napi_del (&tp->napi);
__rtl8139_cleanup_dev (dev);
pci_disable_device (pdev);
return i;
@@ -1112,6 +1113,7 @@ static void rtl8139_remove_one(struct pci_dev *pdev)
assert (dev != NULL);
cancel_delayed_work_sync(&tp->thread);
+ netif_napi_del (&tp->napi);
unregister_netdev (dev);
Thanks!
^ permalink raw reply related
* [PATCH] net: wireless: brcm80211: brcmsmac: phy: phy_cmn.c: Remove some unused functions
From: Rickard Strandqvist @ 2014-12-20 13:19 UTC (permalink / raw)
To: Brett Rudley, Arend van Spriel
Cc: Rickard Strandqvist, Hante Meuleman, John W. Linville,
Fabian Frederick, Peter Senna Tschudin,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Removes some functions that are not used anywhere:
wlc_phy_edcrs_lock() wlc_phy_txpower_ipa_ison() wlc_phy_upd_rssi_offset()
wlc_phy_get_pwrdet_offsets() wlc_lcnphy_epa_switch() wlc_phy_stf_ssmode_get()
wlc_phy_stf_chain_get() write_phy_channel_reg() wlc_phy_BSSinit()
wlc_phy_set_deaf() wlc_phy_freqtrack_end() wlc_phy_freqtrack_start()
wlc_phy_noise_sample_request_external() wlc_phy_test_ison()
wlc_phy_txpower_hw_ctrl_set() wlc_phy_bf_preempt_enable()
wlc_phy_runbist_config() wlc_phy_txpwr_percent_set()
wlc_phy_txpower_get_target_max() wlc_radioreg_exit()
wlc_phy_txpower_get_target_min() wlc_phy_txpower_boardlimit_band()
wlc_phy_txpower_sromlimit_max_get() wlc_radioreg_enter()
wlc_phy_txpower_target_set() wlc_phy_chanspec_band_firstch()
wlc_phy_chanspec_bandrange_get() wlc_phy_bw_state_get() wlc_phy_clear_tssi()
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist-IW2WV5XWFqGZkjO+N0TKoMugMpMbD5Xr@public.gmane.org>
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 433 --------------------
.../net/wireless/brcm80211/brcmsmac/phy/phy_hal.h | 27 --
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h | 10 -
3 files changed, 470 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
index 941b1e4..af428bb 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -138,23 +138,6 @@ void wlc_phyreg_exit(struct brcms_phy_pub *pih)
wlapi_bmac_ucode_wake_override_phyreg_clear(pi->sh->physhim);
}
-void wlc_radioreg_enter(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
- wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, MCTL_LOCK_RADIO);
-
- udelay(10);
-}
-
-void wlc_radioreg_exit(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- (void)bcma_read16(pi->d11core, D11REGOFFS(phyversion));
- pi->phy_wreg = 0;
- wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, 0);
-}
-
u16 read_radio_reg(struct brcms_phy *pi, u16 addr)
{
u16 data;
@@ -274,11 +257,6 @@ void mod_radio_reg(struct brcms_phy *pi, u16 addr, u16 mask, u16 val)
write_radio_reg(pi, addr, (rval & ~mask) | (val & mask));
}
-void write_phy_channel_reg(struct brcms_phy *pi, uint val)
-{
- bcma_write16(pi->d11core, D11REGOFFS(phychannel), val);
-}
-
u16 read_phy_reg(struct brcms_phy *pi, u16 addr)
{
bcma_wflush16(pi->d11core, D11REGOFFS(phyregaddr), addr);
@@ -703,18 +681,6 @@ void wlc_phy_por_inform(struct brcms_phy_pub *ppi)
pi->phy_init_por = true;
}
-void wlc_phy_edcrs_lock(struct brcms_phy_pub *pih, bool lock)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- pi->edcrs_threshold_lock = lock;
-
- write_phy_reg(pi, 0x22c, 0x46b);
- write_phy_reg(pi, 0x22d, 0x46b);
- write_phy_reg(pi, 0x22e, 0x3c0);
- write_phy_reg(pi, 0x22f, 0x3c0);
-}
-
void wlc_phy_initcal_enable(struct brcms_phy_pub *pih, bool initcal)
{
struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
@@ -1094,20 +1060,6 @@ void wlc_phy_mute_upd(struct brcms_phy_pub *pih, bool mute, u32 flags)
return;
}
-void wlc_phy_clear_tssi(struct brcms_phy_pub *pih)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- if (ISNPHY(pi)) {
- return;
- } else {
- wlapi_bmac_write_shm(pi->sh->physhim, M_B_TSSI_0, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_B_TSSI_1, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_G_TSSI_0, NULL_TSSI_W);
- wlapi_bmac_write_shm(pi->sh->physhim, M_G_TSSI_1, NULL_TSSI_W);
- }
-}
-
static bool wlc_phy_cal_txpower_recalc_sw(struct brcms_phy *pi)
{
return false;
@@ -1147,13 +1099,6 @@ void wlc_phy_switch_radio(struct brcms_phy_pub *pih, bool on)
}
}
-u16 wlc_phy_bw_state_get(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- return pi->bw;
-}
-
void wlc_phy_bw_state_set(struct brcms_phy_pub *ppi, u16 bw)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -1209,20 +1154,6 @@ int wlc_phy_chanspec_freq2bandrange_lpssn(uint freq)
return range;
}
-int wlc_phy_chanspec_bandrange_get(struct brcms_phy *pi, u16 chanspec)
-{
- int range = -1;
- uint channel = CHSPEC_CHANNEL(chanspec);
- uint freq = wlc_phy_channel2freq(channel);
-
- if (ISNPHY(pi))
- range = wlc_phy_get_chan_freq_range_nphy(pi, channel);
- else if (ISLCNPHY(pi))
- range = wlc_phy_chanspec_freq2bandrange_lpssn(freq);
-
- return range;
-}
-
void wlc_phy_chanspec_ch14_widefilter_set(struct brcms_phy_pub *ppi,
bool wide_filter)
{
@@ -1265,50 +1196,6 @@ wlc_phy_chanspec_band_validch(struct brcms_phy_pub *ppi, uint band,
}
}
-u16 wlc_phy_chanspec_band_firstch(struct brcms_phy_pub *ppi, uint band)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
- uint i;
- uint channel;
- u16 chspec;
-
- for (i = 0; i < ARRAY_SIZE(chan_info_all); i++) {
- channel = chan_info_all[i].chan;
-
- if (ISNPHY(pi) && pi->bw == WL_CHANSPEC_BW_40) {
- uint j;
-
- for (j = 0; j < ARRAY_SIZE(chan_info_all); j++) {
- if (chan_info_all[j].chan ==
- channel + CH_10MHZ_APART)
- break;
- }
-
- if (j == ARRAY_SIZE(chan_info_all))
- continue;
-
- channel = upper_20_sb(channel);
- chspec = channel | WL_CHANSPEC_BW_40 |
- WL_CHANSPEC_CTL_SB_LOWER;
- if (band == BRCM_BAND_2G)
- chspec |= WL_CHANSPEC_BAND_2G;
- else
- chspec |= WL_CHANSPEC_BAND_5G;
- } else
- chspec = ch20mhz_chspec(channel);
-
- if ((pi->a_band_high_disable) && (channel >= FIRST_REF5_CHANNUM)
- && (channel <= LAST_REF5_CHANNUM))
- continue;
-
- if ((band == BRCM_BAND_2G && channel <= CH_MAX_2G_CHANNEL) ||
- (band == BRCM_BAND_5G && channel > CH_MAX_2G_CHANNEL))
- return chspec;
- }
-
- return (u16) INVCHANSPEC;
-}
-
int wlc_phy_txpower_get(struct brcms_phy_pub *ppi, uint *qdbm, bool *override)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -1319,56 +1206,6 @@ int wlc_phy_txpower_get(struct brcms_phy_pub *ppi, uint *qdbm, bool *override)
return 0;
}
-void wlc_phy_txpower_target_set(struct brcms_phy_pub *ppi,
- struct txpwr_limits *txpwr)
-{
- bool mac_enabled = false;
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- memcpy(&pi->tx_user_target[TXP_FIRST_CCK],
- &txpwr->cck[0], BRCMS_NUM_RATES_CCK);
-
- memcpy(&pi->tx_user_target[TXP_FIRST_OFDM],
- &txpwr->ofdm[0], BRCMS_NUM_RATES_OFDM);
- memcpy(&pi->tx_user_target[TXP_FIRST_OFDM_20_CDD],
- &txpwr->ofdm_cdd[0], BRCMS_NUM_RATES_OFDM);
-
- memcpy(&pi->tx_user_target[TXP_FIRST_OFDM_40_SISO],
- &txpwr->ofdm_40_siso[0], BRCMS_NUM_RATES_OFDM);
- memcpy(&pi->tx_user_target[TXP_FIRST_OFDM_40_CDD],
- &txpwr->ofdm_40_cdd[0], BRCMS_NUM_RATES_OFDM);
-
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_20_SISO],
- &txpwr->mcs_20_siso[0], BRCMS_NUM_RATES_MCS_1_STREAM);
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_20_CDD],
- &txpwr->mcs_20_cdd[0], BRCMS_NUM_RATES_MCS_1_STREAM);
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_20_STBC],
- &txpwr->mcs_20_stbc[0], BRCMS_NUM_RATES_MCS_1_STREAM);
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_20_SDM],
- &txpwr->mcs_20_mimo[0], BRCMS_NUM_RATES_MCS_2_STREAM);
-
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_40_SISO],
- &txpwr->mcs_40_siso[0], BRCMS_NUM_RATES_MCS_1_STREAM);
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_40_CDD],
- &txpwr->mcs_40_cdd[0], BRCMS_NUM_RATES_MCS_1_STREAM);
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_40_STBC],
- &txpwr->mcs_40_stbc[0], BRCMS_NUM_RATES_MCS_1_STREAM);
- memcpy(&pi->tx_user_target[TXP_FIRST_MCS_40_SDM],
- &txpwr->mcs_40_mimo[0], BRCMS_NUM_RATES_MCS_2_STREAM);
-
- if (bcma_read32(pi->d11core, D11REGOFFS(maccontrol)) & MCTL_EN_MAC)
- mac_enabled = true;
-
- if (mac_enabled)
- wlapi_suspend_mac_and_wait(pi->sh->physhim);
-
- wlc_phy_txpower_recalc_target(pi);
- wlc_phy_cal_txpower_recalc_sw(pi);
-
- if (mac_enabled)
- wlapi_enable_mac(pi->sh->physhim);
-}
-
int wlc_phy_txpower_set(struct brcms_phy_pub *ppi, uint qdbm, bool override)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -1452,59 +1289,6 @@ wlc_phy_txpower_sromlimit(struct brcms_phy_pub *ppi, uint channel, u8 *min_pwr,
}
}
-void
-wlc_phy_txpower_sromlimit_max_get(struct brcms_phy_pub *ppi, uint chan,
- u8 *max_txpwr, u8 *min_txpwr)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
- u8 tx_pwr_max = 0;
- u8 tx_pwr_min = 255;
- u8 max_num_rate;
- u8 maxtxpwr, mintxpwr, rate, pactrl;
-
- pactrl = 0;
-
- max_num_rate = ISNPHY(pi) ? TXP_NUM_RATES :
- ISLCNPHY(pi) ? (TXP_LAST_SISO_MCS_20 +
- 1) : (TXP_LAST_OFDM + 1);
-
- for (rate = 0; rate < max_num_rate; rate++) {
-
- wlc_phy_txpower_sromlimit(ppi, chan, &mintxpwr, &maxtxpwr,
- rate);
-
- maxtxpwr = (maxtxpwr > pactrl) ? (maxtxpwr - pactrl) : 0;
-
- maxtxpwr = (maxtxpwr > 6) ? (maxtxpwr - 6) : 0;
-
- tx_pwr_max = max(tx_pwr_max, maxtxpwr);
- tx_pwr_min = min(tx_pwr_min, maxtxpwr);
- }
- *max_txpwr = tx_pwr_max;
- *min_txpwr = tx_pwr_min;
-}
-
-void
-wlc_phy_txpower_boardlimit_band(struct brcms_phy_pub *ppi, uint bandunit,
- s32 *max_pwr, s32 *min_pwr, u32 *step_pwr)
-{
- return;
-}
-
-u8 wlc_phy_txpower_get_target_min(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- return pi->tx_power_min;
-}
-
-u8 wlc_phy_txpower_get_target_max(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- return pi->tx_power_max;
-}
-
static s8 wlc_phy_env_measure_vbat(struct brcms_phy *pi)
{
if (ISLCNPHY(pi))
@@ -1810,13 +1594,6 @@ wlc_phy_txpower_reg_limit_calc(struct brcms_phy *pi, struct txpwr_limits *txpwr,
}
}
-void wlc_phy_txpwr_percent_set(struct brcms_phy_pub *ppi, u8 txpwr_percent)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- pi->txpwr_percent = txpwr_percent;
-}
-
void wlc_phy_machwcap_set(struct brcms_phy_pub *ppi, u32 machwcap)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -1824,35 +1601,6 @@ void wlc_phy_machwcap_set(struct brcms_phy_pub *ppi, u32 machwcap)
pi->sh->machwcap = machwcap;
}
-void wlc_phy_runbist_config(struct brcms_phy_pub *ppi, bool start_end)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
- u16 rxc;
- rxc = 0;
-
- if (start_end == ON) {
- if (!ISNPHY(pi))
- return;
-
- if (NREV_IS(pi->pubpi.phy_rev, 3)
- || NREV_IS(pi->pubpi.phy_rev, 4)) {
- bcma_wflush16(pi->d11core, D11REGOFFS(phyregaddr),
- 0xa0);
- bcma_set16(pi->d11core, D11REGOFFS(phyregdata),
- 0x1 << 15);
- }
- } else {
- if (NREV_IS(pi->pubpi.phy_rev, 3)
- || NREV_IS(pi->pubpi.phy_rev, 4)) {
- bcma_wflush16(pi->d11core, D11REGOFFS(phyregaddr),
- 0xa0);
- bcma_write16(pi->d11core, D11REGOFFS(phyregdata), rxc);
- }
-
- wlc_phy_por_inform(ppi);
- }
-}
-
void
wlc_phy_txpower_limit_set(struct brcms_phy_pub *ppi, struct txpwr_limits *txpwr,
u16 chanspec)
@@ -1886,13 +1634,6 @@ void wlc_phy_ofdm_rateset_war(struct brcms_phy_pub *pih, bool war)
pi->ofdm_rateset_war = war;
}
-void wlc_phy_bf_preempt_enable(struct brcms_phy_pub *pih, bool bf_preempt)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- pi->bf_preempt_4306 = bf_preempt;
-}
-
void wlc_phy_txpower_update_shm(struct brcms_phy *pi)
{
int j;
@@ -1953,37 +1694,6 @@ bool wlc_phy_txpower_hw_ctrl_get(struct brcms_phy_pub *ppi)
return pi->hwpwrctrl;
}
-void wlc_phy_txpower_hw_ctrl_set(struct brcms_phy_pub *ppi, bool hwpwrctrl)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
- bool suspend;
-
- if (!pi->hwpwrctrl_capable)
- return;
-
- pi->hwpwrctrl = hwpwrctrl;
- pi->nphy_txpwrctrl = hwpwrctrl;
- pi->txpwrctrl = hwpwrctrl;
-
- if (ISNPHY(pi)) {
- suspend = (0 == (bcma_read32(pi->d11core,
- D11REGOFFS(maccontrol)) &
- MCTL_EN_MAC));
- if (!suspend)
- wlapi_suspend_mac_and_wait(pi->sh->physhim);
-
- wlc_phy_txpwrctrl_enable_nphy(pi, pi->nphy_txpwrctrl);
- if (pi->nphy_txpwrctrl == PHY_TPC_HW_OFF)
- wlc_phy_txpwr_fixpower_nphy(pi);
- else
- mod_phy_reg(pi, 0x1e7, (0x7f << 0),
- pi->saved_txpwr_idx);
-
- if (!suspend)
- wlapi_enable_mac(pi->sh->physhim);
- }
-}
-
void wlc_phy_txpower_ipa_upd(struct brcms_phy *pi)
{
@@ -2141,13 +1851,6 @@ void wlc_phy_antsel_type_set(struct brcms_phy_pub *ppi, u8 antsel_type)
pi->antsel_type = antsel_type;
}
-bool wlc_phy_test_ison(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- return pi->phytest_on;
-}
-
void wlc_phy_ant_rxdiv_set(struct brcms_phy_pub *ppi, u8 val)
{
struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
@@ -2461,15 +2164,6 @@ done:
}
-void wlc_phy_noise_sample_request_external(struct brcms_phy_pub *pih)
-{
- u8 channel;
-
- channel = CHSPEC_CHANNEL(wlc_phy_chanspec_get(pih));
-
- wlc_phy_noise_sample_request(pih, PHY_NOISE_SAMPLE_EXTERNAL, channel);
-}
-
static const s8 lcnphy_gain_index_offset_for_pkt_rssi[] = {
8,
8,
@@ -2568,27 +2262,6 @@ end:
return rssi;
}
-void wlc_phy_freqtrack_start(struct brcms_phy_pub *pih)
-{
- return;
-}
-
-void wlc_phy_freqtrack_end(struct brcms_phy_pub *pih)
-{
- return;
-}
-
-void wlc_phy_set_deaf(struct brcms_phy_pub *ppi, bool user_flag)
-{
- struct brcms_phy *pi;
- pi = (struct brcms_phy *) ppi;
-
- if (ISLCNPHY(pi))
- wlc_lcnphy_deaf_mode(pi, true);
- else if (ISNPHY(pi))
- wlc_nphy_deaf_mode(pi, true);
-}
-
void wlc_phy_watchdog(struct brcms_phy_pub *pih)
{
struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
@@ -2649,28 +2322,6 @@ void wlc_phy_watchdog(struct brcms_phy_pub *pih)
}
}
-void wlc_phy_BSSinit(struct brcms_phy_pub *pih, bool bonlyap, int rssi)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
- uint i;
- uint k;
-
- for (i = 0; i < MA_WINDOW_SZ; i++)
- pi->sh->phy_noise_window[i] = (s8) (rssi & 0xff);
- if (ISLCNPHY(pi)) {
- for (i = 0; i < MA_WINDOW_SZ; i++)
- pi->sh->phy_noise_window[i] =
- PHY_NOISE_FIXED_VAL_LCNPHY;
- }
- pi->sh->phy_noise_index = 0;
-
- for (i = 0; i < PHY_NOISE_WINDOW_SZ; i++) {
- for (k = WL_ANT_IDX_1; k < WL_ANT_RX_MAX; k++)
- pi->nphy_noise_win[k][i] = PHY_NOISE_FIXED_VAL_NPHY;
- }
- pi->nphy_noise_index = 0;
-}
-
void
wlc_phy_papd_decode_epsilon(u32 epsilon, s32 *eps_real, s32 *eps_imag)
{
@@ -2825,14 +2476,6 @@ void wlc_phy_stf_chain_set(struct brcms_phy_pub *pih, u8 txchain, u8 rxchain)
pi->pubpi.phy_corenum = (u8)hweight8(pi->sh->phyrxchain);
}
-void wlc_phy_stf_chain_get(struct brcms_phy_pub *pih, u8 *txchain, u8 *rxchain)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
-
- *txchain = pi->sh->phytxchain;
- *rxchain = pi->sh->phyrxchain;
-}
-
u8 wlc_phy_stf_chain_active_get(struct brcms_phy_pub *pih)
{
s16 nphy_currtemp;
@@ -2865,89 +2508,13 @@ u8 wlc_phy_stf_chain_active_get(struct brcms_phy_pub *pih)
return active_bitmap;
}
-s8 wlc_phy_stf_ssmode_get(struct brcms_phy_pub *pih, u16 chanspec)
-{
- struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
- u8 siso_mcs_id, cdd_mcs_id;
-
- siso_mcs_id =
- (CHSPEC_IS40(chanspec)) ? TXP_FIRST_MCS_40_SISO :
- TXP_FIRST_MCS_20_SISO;
- cdd_mcs_id =
- (CHSPEC_IS40(chanspec)) ? TXP_FIRST_MCS_40_CDD :
- TXP_FIRST_MCS_20_CDD;
-
- if (pi->tx_power_target[siso_mcs_id] >
- (pi->tx_power_target[cdd_mcs_id] + 12))
- return PHY_TXC1_MODE_SISO;
- else
- return PHY_TXC1_MODE_CDD;
-}
-
const u8 *wlc_phy_get_ofdm_rate_lookup(void)
{
return ofdm_rate_lookup;
}
-void wlc_lcnphy_epa_switch(struct brcms_phy *pi, bool mode)
-{
- if ((pi->sh->chip == BCMA_CHIP_ID_BCM4313) &&
- (pi->sh->boardflags & BFL_FEM)) {
- if (mode) {
- u16 txant = 0;
- txant = wlapi_bmac_get_txant(pi->sh->physhim);
- if (txant == 1) {
- mod_phy_reg(pi, 0x44d, (0x1 << 2), (1) << 2);
-
- mod_phy_reg(pi, 0x44c, (0x1 << 2), (1) << 2);
-
- }
-
- bcma_chipco_gpio_control(&pi->d11core->bus->drv_cc,
- 0x0, 0x0);
- bcma_chipco_gpio_out(&pi->d11core->bus->drv_cc,
- ~0x40, 0x40);
- bcma_chipco_gpio_outen(&pi->d11core->bus->drv_cc,
- ~0x40, 0x40);
- } else {
- mod_phy_reg(pi, 0x44c, (0x1 << 2), (0) << 2);
-
- mod_phy_reg(pi, 0x44d, (0x1 << 2), (0) << 2);
-
- bcma_chipco_gpio_out(&pi->d11core->bus->drv_cc,
- ~0x40, 0x00);
- bcma_chipco_gpio_outen(&pi->d11core->bus->drv_cc,
- ~0x40, 0x00);
- bcma_chipco_gpio_control(&pi->d11core->bus->drv_cc,
- 0x0, 0x40);
- }
- }
-}
-
void wlc_phy_ldpc_override_set(struct brcms_phy_pub *ppi, bool ldpc)
{
return;
}
-void
-wlc_phy_get_pwrdet_offsets(struct brcms_phy *pi, s8 *cckoffset, s8 *ofdmoffset)
-{
- *cckoffset = 0;
- *ofdmoffset = 0;
-}
-
-s8 wlc_phy_upd_rssi_offset(struct brcms_phy *pi, s8 rssi, u16 chanspec)
-{
-
- return rssi;
-}
-
-bool wlc_phy_txpower_ipa_ison(struct brcms_phy_pub *ppi)
-{
- struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
-
- if (ISNPHY(pi))
- return wlc_phy_n_txpower_ipa_ison(pi);
- else
- return 0;
-}
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_hal.h b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_hal.h
index 4d3734f..4e5e944 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_hal.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_hal.h
@@ -202,7 +202,6 @@ void wlc_phy_antsel_init(struct brcms_phy_pub *ppi, bool lut_init);
void wlc_phy_chanspec_set(struct brcms_phy_pub *ppi, u16 chanspec);
u16 wlc_phy_chanspec_get(struct brcms_phy_pub *ppi);
void wlc_phy_chanspec_radio_set(struct brcms_phy_pub *ppi, u16 newch);
-u16 wlc_phy_bw_state_get(struct brcms_phy_pub *ppi);
void wlc_phy_bw_state_set(struct brcms_phy_pub *ppi, u16 bw);
int wlc_phy_rssi_compute(struct brcms_phy_pub *pih, struct d11rxhdr *rxh);
@@ -210,52 +209,34 @@ void wlc_phy_por_inform(struct brcms_phy_pub *ppi);
void wlc_phy_noise_sample_intr(struct brcms_phy_pub *ppi);
bool wlc_phy_bist_check_phy(struct brcms_phy_pub *ppi);
-void wlc_phy_set_deaf(struct brcms_phy_pub *ppi, bool user_flag);
-
void wlc_phy_switch_radio(struct brcms_phy_pub *ppi, bool on);
void wlc_phy_anacore(struct brcms_phy_pub *ppi, bool on);
-void wlc_phy_BSSinit(struct brcms_phy_pub *ppi, bool bonlyap, int rssi);
-
void wlc_phy_chanspec_ch14_widefilter_set(struct brcms_phy_pub *ppi,
bool wide_filter);
void wlc_phy_chanspec_band_validch(struct brcms_phy_pub *ppi, uint band,
struct brcms_chanvec *channels);
-u16 wlc_phy_chanspec_band_firstch(struct brcms_phy_pub *ppi, uint band);
void wlc_phy_txpower_sromlimit(struct brcms_phy_pub *ppi, uint chan, u8 *_min_,
u8 *_max_, int rate);
void wlc_phy_txpower_sromlimit_max_get(struct brcms_phy_pub *ppi, uint chan,
u8 *_max_, u8 *_min_);
-void wlc_phy_txpower_boardlimit_band(struct brcms_phy_pub *ppi, uint band,
- s32 *, s32 *, u32 *);
void wlc_phy_txpower_limit_set(struct brcms_phy_pub *ppi, struct txpwr_limits *,
u16 chanspec);
int wlc_phy_txpower_get(struct brcms_phy_pub *ppi, uint *qdbm, bool *override);
int wlc_phy_txpower_set(struct brcms_phy_pub *ppi, uint qdbm, bool override);
-void wlc_phy_txpower_target_set(struct brcms_phy_pub *ppi,
- struct txpwr_limits *);
bool wlc_phy_txpower_hw_ctrl_get(struct brcms_phy_pub *ppi);
-void wlc_phy_txpower_hw_ctrl_set(struct brcms_phy_pub *ppi, bool hwpwrctrl);
-u8 wlc_phy_txpower_get_target_min(struct brcms_phy_pub *ppi);
-u8 wlc_phy_txpower_get_target_max(struct brcms_phy_pub *ppi);
-bool wlc_phy_txpower_ipa_ison(struct brcms_phy_pub *pih);
void wlc_phy_stf_chain_init(struct brcms_phy_pub *pih, u8 txchain, u8 rxchain);
void wlc_phy_stf_chain_set(struct brcms_phy_pub *pih, u8 txchain, u8 rxchain);
-void wlc_phy_stf_chain_get(struct brcms_phy_pub *pih, u8 *txchain, u8 *rxchain);
u8 wlc_phy_stf_chain_active_get(struct brcms_phy_pub *pih);
-s8 wlc_phy_stf_ssmode_get(struct brcms_phy_pub *pih, u16 chanspec);
void wlc_phy_ldpc_override_set(struct brcms_phy_pub *ppi, bool val);
void wlc_phy_cal_perical(struct brcms_phy_pub *ppi, u8 reason);
-void wlc_phy_noise_sample_request_external(struct brcms_phy_pub *ppi);
-void wlc_phy_edcrs_lock(struct brcms_phy_pub *pih, bool lock);
void wlc_phy_cal_papd_recal(struct brcms_phy_pub *ppi);
void wlc_phy_ant_rxdiv_set(struct brcms_phy_pub *ppi, u8 val);
-void wlc_phy_clear_tssi(struct brcms_phy_pub *ppi);
void wlc_phy_hold_upd(struct brcms_phy_pub *ppi, u32 id, bool val);
void wlc_phy_mute_upd(struct brcms_phy_pub *ppi, bool val, u32 flags);
@@ -265,17 +246,9 @@ void wlc_phy_txpower_get_current(struct brcms_phy_pub *ppi,
struct tx_power *power, uint channel);
void wlc_phy_initcal_enable(struct brcms_phy_pub *pih, bool initcal);
-bool wlc_phy_test_ison(struct brcms_phy_pub *ppi);
-void wlc_phy_txpwr_percent_set(struct brcms_phy_pub *ppi, u8 txpwr_percent);
void wlc_phy_ofdm_rateset_war(struct brcms_phy_pub *pih, bool war);
-void wlc_phy_bf_preempt_enable(struct brcms_phy_pub *pih, bool bf_preempt);
void wlc_phy_machwcap_set(struct brcms_phy_pub *ppi, u32 machwcap);
-void wlc_phy_runbist_config(struct brcms_phy_pub *ppi, bool start_end);
-
-void wlc_phy_freqtrack_start(struct brcms_phy_pub *ppi);
-void wlc_phy_freqtrack_end(struct brcms_phy_pub *ppi);
-
const u8 *wlc_phy_get_ofdm_rate_lookup(void);
s8 wlc_phy_get_tx_power_offset_by_mcs(struct brcms_phy_pub *ppi,
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
index 4960f7d..ee8ea42 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
@@ -926,8 +926,6 @@ void write_radio_reg(struct brcms_phy *pi, u16 addr, u16 val);
void wlc_phyreg_enter(struct brcms_phy_pub *pih);
void wlc_phyreg_exit(struct brcms_phy_pub *pih);
-void wlc_radioreg_enter(struct brcms_phy_pub *pih);
-void wlc_radioreg_exit(struct brcms_phy_pub *pih);
void wlc_phy_read_table(struct brcms_phy *pi,
const struct phytbl_info *ptbl_info,
@@ -939,7 +937,6 @@ void wlc_phy_table_addr(struct brcms_phy *pi, uint tbl_id, uint tbl_offset,
u16 tblAddr, u16 tblDataHi, u16 tblDataLo);
void wlc_phy_table_data_write(struct brcms_phy *pi, uint width, u32 val);
-void write_phy_channel_reg(struct brcms_phy *pi, uint val);
void wlc_phy_txpower_update_shm(struct brcms_phy *pi);
u8 wlc_phy_nbits(s32 value);
@@ -975,7 +972,6 @@ void wlc_phy_chanspec_set_lcnphy(struct brcms_phy *pi, u16 chanspec);
void wlc_phy_chanspec_set_fixup_lcnphy(struct brcms_phy *pi, u16 chanspec);
int wlc_phy_channel2freq(uint channel);
int wlc_phy_chanspec_freq2bandrange_lpssn(uint);
-int wlc_phy_chanspec_bandrange_get(struct brcms_phy *, u16 chanspec);
void wlc_lcnphy_set_tx_pwr_ctrl(struct brcms_phy *pi, u16 mode);
s8 wlc_lcnphy_get_current_tx_pwr_idx(struct brcms_phy *pi);
@@ -1002,8 +998,6 @@ s16 wlc_lcnphy_tempsense_new(struct brcms_phy *pi, bool mode);
s8 wlc_lcnphy_tempsense_degree(struct brcms_phy *pi, bool mode);
s8 wlc_lcnphy_vbatsense(struct brcms_phy *pi, bool mode);
void wlc_phy_carrier_suppress_lcnphy(struct brcms_phy *pi);
-void wlc_lcnphy_crsuprs(struct brcms_phy *pi, int channel);
-void wlc_lcnphy_epa_switch(struct brcms_phy *pi, bool mode);
void wlc_2064_vco_cal(struct brcms_phy *pi);
void wlc_phy_txpower_recalc_target(struct brcms_phy *pi);
@@ -1104,7 +1098,6 @@ void wlc_phy_txpwrctrl_enable_nphy(struct brcms_phy *pi, u8 ctrl_type);
void wlc_phy_txpwr_fixpower_nphy(struct brcms_phy *pi);
void wlc_phy_txpwr_apply_nphy(struct brcms_phy *pi);
void wlc_phy_txpwr_papd_cal_nphy(struct brcms_phy *pi);
-u16 wlc_phy_txpwr_idx_get_nphy(struct brcms_phy *pi);
struct nphy_txgains wlc_phy_get_tx_gain_nphy(struct brcms_phy *pi);
int wlc_phy_cal_txiqlo_nphy(struct brcms_phy *pi,
@@ -1134,9 +1127,6 @@ int wlc_phy_rssi_compute_nphy(struct brcms_phy *pi, struct d11rxhdr *rxh);
void wlc_phy_nphy_tkip_rifs_war(struct brcms_phy *pi, u8 rifs);
-void wlc_phy_get_pwrdet_offsets(struct brcms_phy *pi, s8 *cckoffset,
- s8 *ofdmoffset);
-s8 wlc_phy_upd_rssi_offset(struct brcms_phy *pi, s8 rssi, u16 chanspec);
bool wlc_phy_n_txpower_ipa_ison(struct brcms_phy *pih);
#endif /* _BRCM_PHY_INT_H_ */
--
1.7.10.4
--
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] 3c59x in linux-3.18.0: memory leak
From: Jia-Ju Bai @ 2014-12-20 13:06 UTC (permalink / raw)
To: klassert, netdev, vortex
I have actually tested 3c59x driver on the real hardware(3Com 3c905B
100BaseTX PCI Ethernet Controller), and find a memory leak:
The target file is drivers/net/ethernet/3com/3c59x.c, which is used to build
3c59x.ko.
(1) The function vortex_up is called by vortex_open when initializing the
ethernet card driver. But when vortex_up is failed, which means that it
returns the error value, "out" segment is executed immediately to halt the
process. However, the resources allocated by __netdev_alloc_skb in
vortex_open are not released by dev_kfree_skb when vortex_up is failed.
(2) As shown in (1), one reason that vortex_up is failed is that
pci_enable_device is failed(return the error value) in vortex_up, and
"err_out" segment is executed immediately to return.
Meanwhile, I also write the patch to fix the bug. I have run the patch on
the hardware, it can work normally and fix this bug.
diff --git a/drivers/net/ethernet/3com/3c59x.c
b/drivers/net/ethernet/3com/3c59x.c
index 41095eb..d0c5bee 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -1782,6 +1782,16 @@ vortex_open(struct net_device *dev)
if (!retval)
goto out;
+ if (vp->full_bus_master_rx) {
+ for (i = 0; i < RX_RING_SIZE; i++) {
+ if (vp->rx_skbuff[i]) {
+ dev_kfree_skb(vp->rx_skbuff[i]);
+ vp->rx_skbuff[i] = NULL;
+ }
+ }
+ retval = -ENOMEM;
+ }
+
err_free_irq:
free_irq(dev->irq, dev);
err:
^ permalink raw reply related
* Re: [PATCH] igb in linux-3.18.0: some potential bugs
From: Jia-Ju Bai @ 2014-12-20 12:59 UTC (permalink / raw)
To: 'Jeff Kirsher'; +Cc: e1000-devel, netdev, linux.nics
Thank for the reply!
For the first reply:
I let some functions fail on purpose to test error handling code, and then run the driver in reality as well as monitor the function calls in runtime.
The results are in my report.
For the second reply:
I admit you are right, and my code style need to be improved.
On Sat, 2014-12-20 at 16:11 +0800, Jia-Ju Bai wrote:
> I have actually tested igb driver on the real hardware(Intel 82575EB
> PCI-E Gigabit Ethernet Controller), and find some potential bugs:
> The target file is drivers/net/ethernet/intel/igb/igb_main.c
>
> (1) In the normal process of igb, pci_enable_pcie_error_reporting and
> pci_disable_pcie_error_reporting is called in pairs in igb_probe and
> igb_remove. However, when pci_enable_pcie_error_reporting has been
> called and alloc_etherdev_mqs in igb_probe is failed,
> "err_alloc_etherdev"
> segment
> in igb_probe is executed immediately to exit, but
> pci_disable_pcie_error_reporting is not called.
> (2) The same situation happens when pci_iomap in igb_probe is failed.
> (3) The same situation happens when igb_sw_init in igb_probe is
> failed.
> (4) The same situation happens when register_netdev in igb_probe is
> failed.
> (5) The same situation happens when igb_init_i2c in igb_probe is
> failed.
>
> (6) The function kcalloc is called by igb_sw_init when initializing
> the ethernet card driver, but kfree is not called when register_netdev
> in igb_probe is failed, which may cause memory leak.
> (7) The same situation happens when igb_init_i2c in igb_probe is
> failed.
> (8) The same situation happens when kzalloc in igb_alloc_q_vector is
> failed.
> (9) The same situation happens when igb_alloc_q_vector in
> igb_alloc_q_vectors is failed.
>
> (10) When igb_init_i2c in igb_probe is failed, igb_enable_sriov is
> called in igb_probe_vfs, but igb_disable_sriov is not called.
> (11) The same situation with [10] happens when register_netdev in
> igb_probe is failed.
>
> Meanwhile, I also write the patch to fix the bugs. I have run the
> patch on the hardware, it can work normally and fix the above bugs.
>Was this a bug you actually saw? Or a theoretical bug based on code review?
>I do not mind adding this to my queue so that we can review and test the patch, although this will cause a fair amount of regression testing.
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH 1/3] batman-adv: Calculate extra tail size based on queued fragments
From: Sven Eckelmann @ 2014-12-20 12:48 UTC (permalink / raw)
To: davem; +Cc: netdev, Sven Eckelmann
In-Reply-To: <1419079737-31107-1-git-send-email-sven@narfation.org>
The fragmentation code was replaced in 610bfc6bc99bc83680d190ebc69359a05fc7f605
("batman-adv: Receive fragmented packets and merge"). The new code provided a
mostly unused parameter skb for the merging function. It is used inside the
function to calculate the additionally needed skb tailroom. But instead of
increasing its own tailroom, it is only increasing the tailroom of the first
queued skb. This is not correct in some situations because the first queued
entry can be a different one than the parameter.
An observed problem was:
1. packet with size 104, total_size 1464, fragno 1 was received
- packet is queued
2. packet with size 1400, total_size 1464, fragno 0 was received
- packet is queued at the end of the list
3. enough data was received and can be given to the merge function
(1464 == (1400 - 20) + (104 - 20))
- merge functions gets 1400 byte large packet as skb argument
4. merge function gets first entry in queue (104 byte)
- stored as skb_out
5. merge function calculates the required extra tail as total_size - skb->len
- pskb_expand_head tail of skb_out with 64 bytes
6. merge function tries to squeeze the extra 1380 bytes from the second queued
skb (1400 byte aka skb parameter) in the 64 extra tail bytes of skb_out
Instead calculate the extra required tail bytes for skb_out also using skb_out
instead of using the parameter skb. The skb parameter is only used to get the
total_size from the last received packet. This is also the total_size used to
decide that all fragments were received.
Reported-by: Philipp Psurek <philipp.psurek@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Acked-by: Martin Hundebøll <martin@hundeboll.net>
---
Problem is in the kernel since v3.13 and may be important for the stable tree.
net/batman-adv/fragmentation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
index fc1835c..8af3461 100644
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -251,7 +251,7 @@ batadv_frag_merge_packets(struct hlist_head *chain, struct sk_buff *skb)
kfree(entry);
/* Make room for the rest of the fragments. */
- if (pskb_expand_head(skb_out, 0, size - skb->len, GFP_ATOMIC) < 0) {
+ if (pskb_expand_head(skb_out, 0, size - skb_out->len, GFP_ATOMIC) < 0) {
kfree_skb(skb_out);
skb_out = NULL;
goto free;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] batman-adv: avoid NULL dereferences and fix if check
From: Sven Eckelmann @ 2014-12-20 12:48 UTC (permalink / raw)
To: davem; +Cc: netdev, Antonio Quartulli, Marek Lindner
In-Reply-To: <1419079737-31107-1-git-send-email-sven@narfation.org>
From: Antonio Quartulli <antonio@meshcoding.com>
Gateway having bandwidth_down equal to zero are not accepted
at all and so never added to the Gateway list.
For this reason checking the bandwidth_down member in
batadv_gw_out_of_range() is useless.
This is probably a copy/paste error and this check was supposed
to be "!gw_node" only. Moreover, the way the check is written
now may also lead to a NULL dereference.
Fix this by rewriting the if-condition properly.
Introduced by 414254e342a0d58144de40c3da777521ebaeeb07
("batman-adv: tvlv - gateway download/upload bandwidth container")
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
---
Problem is in the kernel since v3.13 and may be important for the stable tree.
net/batman-adv/gateway_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c
index 90cff58..e0bcf9e 100644
--- a/net/batman-adv/gateway_client.c
+++ b/net/batman-adv/gateway_client.c
@@ -810,7 +810,7 @@ bool batadv_gw_out_of_range(struct batadv_priv *bat_priv,
goto out;
gw_node = batadv_gw_node_get(bat_priv, orig_dst_node);
- if (!gw_node->bandwidth_down == 0)
+ if (!gw_node)
goto out;
switch (atomic_read(&bat_priv->gw_mode)) {
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] batman-adv: Unify fragment size calculation
From: Sven Eckelmann @ 2014-12-20 12:48 UTC (permalink / raw)
To: davem; +Cc: netdev, Sven Eckelmann
In-Reply-To: <1419079737-31107-1-git-send-email-sven@narfation.org>
The fragmentation code was replaced in 610bfc6bc99bc83680d190ebc69359a05fc7f605
("batman-adv: Receive fragmented packets and merge") by an implementation which
can handle up to 16 fragments of a packet. The packet is prepared for the split
in fragments by the function batadv_frag_send_packet and the actual split is
done by batadv_frag_create.
Both functions calculate the size of a fragment themself. But their calculation
differs because batadv_frag_send_packet also subtracts ETH_HLEN. Therefore,
the check in batadv_frag_send_packet "can a full fragment can be created?" may
return true even when batadv_frag_create cannot create a full fragment.
The function batadv_frag_create doesn't check the size of the skb before
splitting it and therefore might try to create a larger fragment than the
remaining buffer. This creates an integer underflow and an invalid len is given
to skb_split.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
Problem is in the kernel since v3.13 and may be important for the stable tree.
net/batman-adv/fragmentation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
index 8af3461..00f9e14 100644
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -434,7 +434,7 @@ bool batadv_frag_send_packet(struct sk_buff *skb,
* fragments larger than BATADV_FRAG_MAX_FRAG_SIZE
*/
mtu = min_t(unsigned, mtu, BATADV_FRAG_MAX_FRAG_SIZE);
- max_fragment_size = (mtu - header_size - ETH_HLEN);
+ max_fragment_size = mtu - header_size;
max_packet_size = max_fragment_size * BATADV_FRAG_MAX_FRAGMENTS;
/* Don't even try to fragment, if we need more than 16 fragments */
--
2.1.4
^ permalink raw reply related
* Stable fixes for batman-adv
From: Sven Eckelmann @ 2014-12-20 12:48 UTC (permalink / raw)
To: davem; +Cc: netdev
Hi,
it seems that patches aren't forwarded anymore (since August?) from batman-adv
to the netdev mailing list. Please correct me if I am wrong.
I would hereby try to send some patches directly to the netdev mailing list
instead of waiting any longer for the patches to be forwarded. There are more
non-feature patches [1] waiting in the batman-adv repo (everything after
"batman-adv: fix alignment" from 2014-05-15) but these don't seem to
be related to crashes.
At least the first patch caused crashes in real world scenarios [2] and could
also be used to crash a mesh node on-demand. The last patch has its bug report
in the linux bug tracker [3]. The second patch is a wrong size calculation but
no problem was yet observed in the wild.
All patches fix problems which were introduced in Linux 3.13.
Kind regards,
Sven
[1] http://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/maint
[2] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-November/012561.html
[3] https://bugzilla.kernel.org/show_bug.cgi?id=84061
^ permalink raw reply
* 答复: [linux-nics] [PATCH] igb in linux-3.18.0: some potential bugs
From: Jia-Ju Bai @ 2014-12-20 12:56 UTC (permalink / raw)
To: 'Jeff Kirsher'; +Cc: e1000-devel, netdev, linux.nics
In-Reply-To: <1419071709.2461.86.camel@jtkirshe-mobl.home>
Thank for the reply!
For the first reply:
I let some functions fail on purpose to test error handling code, and then run the driver in reality as well as monitor the function calls in runtime.
The results are in my report.
For the second reply:
I admit you are right, and my code style need to be improved.
On Sat, 2014-12-20 at 16:11 +0800, Jia-Ju Bai wrote:
> I have actually tested igb driver on the real hardware(Intel 82575EB
> PCI-E Gigabit Ethernet Controller), and find some potential bugs:
> The target file is drivers/net/ethernet/intel/igb/igb_main.c
>
> (1) In the normal process of igb, pci_enable_pcie_error_reporting and
> pci_disable_pcie_error_reporting is called in pairs in igb_probe and
> igb_remove. However, when pci_enable_pcie_error_reporting has been
> called and alloc_etherdev_mqs in igb_probe is failed,
> "err_alloc_etherdev"
> segment
> in igb_probe is executed immediately to exit, but
> pci_disable_pcie_error_reporting is not called.
> (2) The same situation happens when pci_iomap in igb_probe is failed.
> (3) The same situation happens when igb_sw_init in igb_probe is
> failed.
> (4) The same situation happens when register_netdev in igb_probe is
> failed.
> (5) The same situation happens when igb_init_i2c in igb_probe is
> failed.
>
> (6) The function kcalloc is called by igb_sw_init when initializing
> the ethernet card driver, but kfree is not called when register_netdev
> in igb_probe is failed, which may cause memory leak.
> (7) The same situation happens when igb_init_i2c in igb_probe is
> failed.
> (8) The same situation happens when kzalloc in igb_alloc_q_vector is
> failed.
> (9) The same situation happens when igb_alloc_q_vector in
> igb_alloc_q_vectors is failed.
>
> (10) When igb_init_i2c in igb_probe is failed, igb_enable_sriov is
> called in igb_probe_vfs, but igb_disable_sriov is not called.
> (11) The same situation with [10] happens when register_netdev in
> igb_probe is failed.
>
> Meanwhile, I also write the patch to fix the bugs. I have run the
> patch on the hardware, it can work normally and fix the above bugs.
Was this a bug you actually saw? Or a theoretical bug based on code review?
I do not mind adding this to my queue so that we can review and test the patch, although this will cause a fair amount of regression testing.
【来自网易邮箱的超大附件】
邮件带有附件预览链接，若您转发或回复此邮件时不希望对方预览附件，建议您手动删除链接。
signature.asc
下载: http://u.163.com/t/HnVMNHn21
预览: http://u.163.com/t/g1ju64
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Re:Re: [linux-nics] [PATCH]e100 in linux-3.18.0: some potential bugs
From: Jeff Kirsher @ 2014-12-20 12:52 UTC (permalink / raw)
To: 白家驹; +Cc: netdev, e1000-devel
In-Reply-To: <1e83d62.1197.14a67b6f11a.Coremail.baijiaju1990@163.com>
[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]
On Sat, 2014-12-20 at 20:40 +0800, 白家驹 wrote:
> Thank for the reply!
>
> For the first reply:
> I let pci_pool_create fail on purpose to simulate insufficient memory,
> and then run the driver in reality, but the driver crashes.
>
> For the second reply:
> I admit you are right, and my code style need to be improved.
>
Added in netdev and e1000-devel back onto the CC, since Jia-Ju Bai
removed them in his reply
>
> At 2014-12-20 18:18:09,"Jeff Kirsher" <jeffrey.t.kirsher@intel.com> wrote:
> >On Sat, 2014-12-20 at 15:40 +0800, Jia-Ju Bai wrote:
> >> I have actually tested e100 driver on the real hardware(Intel 82559
> >> PCI
> >> Ethernet Controller), and find some bugs:
> >> The target file is drivers/net/ethernet/intel/e100.c, which is used to
> >> build
> >> e100.ko.
> >>
> >> (1) The function pci_pool_create is called by e100_probe when
> >> initializing
> >> the ethernet card driver. But when pci_pool_create is failed, which
> >> means
> >> that it returns NULL to nic->cbs_pool, the system crash will happen.
> >> Because
> >> pci_pool_alloc (in e100_alloc_cbs in e100_up in e100_open) need to use
> >> nic->cbs_pool to allocate the resource, but it is NULL. I suggest that
> >> a
> >> check can be added in the code to detect whether pci_pool_create
> >> returns
> >> NULL.
> >> (2) In the normal process, netif_napi_add is called in e100_probe, but
> >> netif_napi_del is not called in e100_remove. However, many other
> >> ethernet
> >> card drivers call them in pairs, even in the error handling paths,
> >> such as
> >> r8169 and igb.
> >>
> >> Meanwhile, I also write the patch to fix the bugs. I have run the
> >> patch on
> >> the hardware, it can work normally and fix the above bugs.
> >
> >Did you actually experience an issue? Or is this a theoretical issue
> >that was never actually seen?
> >
> >>
> >> diff --git a/drivers/net/ethernet/intel/e100.c
> >> b/drivers/net/ethernet/intel/e100.c
> >> index 781065e..2631d3f 100644
> >> --- a/drivers/net/ethernet/intel/e100.c
> >> +++ b/drivers/net/ethernet/intel/e100.c
> >> @@ -2969,6 +2969,11 @@ static int e100_probe(struct pci_dev *pdev,
> >> const
> >> struct pci_device_id *ent)
> >> nic->params.cbs.max * sizeof(struct cb),
> >> sizeof(u32),
> >> 0);
> >> + if(!(nic->cbs_pool))
> >> + {
> >> + err = -ENOMEM;
> >> + goto err_out_pool;
> >> + }
> >> netif_info(nic, probe, nic->netdev,
> >
> >Minor nit-pick but your open bracket needs to be on the same line as the
> >if statement AND you need a space between the 'if' and (). So the above
> >code should look like:
> > if (!nic->cbs_pool) {
> > err = -ENOMEM;
> > goto err_out_pool;
> > }
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Re:Re: [linux-nics] [PATCH] e1000 in linux-3.18.0: a potential bug
From: Jeff Kirsher @ 2014-12-20 12:49 UTC (permalink / raw)
To: 白家驹; +Cc: netdev, e1000-devel
In-Reply-To: <79ea17da.119c.14a67bcadd1.Coremail.baijiaju1990@163.com>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
On Sat, 2014-12-20 at 20:47 +0800, 白家驹 wrote:
> Thanks for the reply!
> I run the driver normally, and monitor all function calls in runtime,
> and then find this violation.
Adding netdev and e1000-devel back onto the CC since Jia-Ju Bai removed
them in his reply...
>
> At 2014-12-20 18:34:20,"Jeff Kirsher" <jeffrey.t.kirsher@intel.com> wrote:
> >On Sat, 2014-12-20 at 15:50 +0800, Jia-Ju Bai wrote:
> >> I have actually tested e1000 driver on the real hardware(Intel 82540EM
> >> PCI
> >> Gigabit Ethernet Controller), and find a potential bug:
> >> The target file is drivers/net/ethernet/intel/e1000/e1000_main.c,
> >> which is
> >> used to build e1000.ko.
> >>
> >> (1) In the normal process, netif_napi_add is called in e1000_probe,
> >> but
> >> netif_napi_del is not called in e1000_remove. However, many other
> >> ethernet
> >> card drivers call them in pairs, even in the error handling paths,
> >> such as
> >> r8169 and igb.
> >>
> >> Meanwhile, I also write the patch to fix the bug. I have run the patch
> >> on
> >> the hardware, it can work normally and fix the above bug.
> >
> >Was this a bug you actually saw? Or a theoretical bug based on code
> >review?
> >
> >I do not mind adding this to my queue so that we can review and test the
> >patch, although this will cause a fair amount of regression testing.
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] net: wireless: rtlwifi: rtl8192ee: trx.c: Remove unused function
From: Rickard Strandqvist @ 2014-12-20 12:48 UTC (permalink / raw)
To: Larry Finger, Chaoming Li
Cc: Rickard Strandqvist, John W. Linville, Greg Kroah-Hartman,
Rasmus Villemoes, Joe Perches, linux-wireless, netdev,
linux-kernel
Remove the function rtl92ee_get_available_desc() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 21 ---------------------
drivers/net/wireless/rtlwifi/rtl8192ee/trx.h | 1 -
2 files changed, 22 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index 2fcbef1..8186ed2 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -710,27 +710,6 @@ 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)
-{
- struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- u16 point_diff = 0;
- u16 current_tx_read_point = 0, current_tx_write_point = 0;
- u32 tmp_4byte;
-
- tmp_4byte = rtl_read_dword(rtlpriv,
- get_desc_addr_fr_q_idx(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));
-
- rtlpci->tx_ring[q_idx].avl_desc = point_diff;
-}
-
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/rtl8192ee/trx.h b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
index 6f9be1c..4426c49 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.h
@@ -829,7 +829,6 @@ 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);
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);
--
1.7.10.4
^ permalink raw reply related
* Re: Re:Re: [linux-nics] [PATCH] e1000e in linux-3.18.0: some potential bugs
From: Jeff Kirsher @ 2014-12-20 12:47 UTC (permalink / raw)
To: 白家驹; +Cc: netdev, e1000-devel
In-Reply-To: <aaab622.119b.14a67ba656c.Coremail.baijiaju1990@163.com>
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
On Sat, 2014-12-20 at 20:44 +0800, 白家驹 wrote:
> Thank for the reply!
>
> For the first reply:
> I let some functions fail on purpose to test error handling code, and
> then run the driver in reality as well as monitor the function calls
> in runtime.
> The results are in my report.
>
> For the second reply:
> I admit you are right, and my code style need to be improved.
Adding netdev and e1000-devel mailing lists back onto the CC, since 白家
驹 removed them in his reply.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] net: ceph: ceph_strings.c: Remove unused function
From: Rickard Strandqvist @ 2014-12-20 12:34 UTC (permalink / raw)
To: Sage Weil, David S. Miller
Cc: Rickard Strandqvist, ceph-devel, netdev, linux-kernel
Remove the function ceph_pool_op_name() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
include/linux/ceph/ceph_fs.h | 2 --
net/ceph/ceph_strings.c | 14 --------------
2 files changed, 16 deletions(-)
diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs.h
index 3c97d5e..0684f9e 100644
--- a/include/linux/ceph/ceph_fs.h
+++ b/include/linux/ceph/ceph_fs.h
@@ -191,8 +191,6 @@ struct ceph_mon_statfs_reply {
struct ceph_statfs st;
} __attribute__ ((packed));
-const char *ceph_pool_op_name(int op);
-
struct ceph_mon_poolop {
struct ceph_mon_request_header monhdr;
struct ceph_fsid fsid;
diff --git a/net/ceph/ceph_strings.c b/net/ceph/ceph_strings.c
index 3056020..139a9cb 100644
--- a/net/ceph/ceph_strings.c
+++ b/net/ceph/ceph_strings.c
@@ -42,17 +42,3 @@ const char *ceph_osd_state_name(int s)
return "???";
}
}
-
-const char *ceph_pool_op_name(int op)
-{
- switch (op) {
- case POOL_OP_CREATE: return "create";
- case POOL_OP_DELETE: return "delete";
- case POOL_OP_AUID_CHANGE: return "auid change";
- case POOL_OP_CREATE_SNAP: return "create snap";
- case POOL_OP_DELETE_SNAP: return "delete snap";
- case POOL_OP_CREATE_UNMANAGED_SNAP: return "create unmanaged snap";
- case POOL_OP_DELETE_UNMANAGED_SNAP: return "delete unmanaged snap";
- }
- return "???";
-}
--
1.7.10.4
^ permalink raw reply related
* [PATCH] net: wireless: ipw2x00: ipw2200.c: Remove unused function
From: Rickard Strandqvist @ 2014-12-20 12:29 UTC (permalink / raw)
To: Stanislav Yakovlev, John W. Linville
Cc: Rickard Strandqvist, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Remove the function ipw_alive() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist-IW2WV5XWFqGZkjO+N0TKoMugMpMbD5Xr@public.gmane.org>
---
drivers/net/wireless/ipw2x00/ipw2200.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index edc3443..2f830ca 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -3021,20 +3021,6 @@ static void ipw_remove_current_network(struct ipw_priv *priv)
spin_unlock_irqrestore(&priv->ieee->lock, flags);
}
-/**
- * Check that card is still alive.
- * Reads debug register from domain0.
- * If card is present, pre-defined value should
- * be found there.
- *
- * @param priv
- * @return 1 if card is present, 0 otherwise
- */
-static inline int ipw_alive(struct ipw_priv *priv)
-{
- return ipw_read32(priv, 0x90) == 0xd55555d5;
-}
^ permalink raw reply related
* Re: [linux-nics] [PATCH] igb in linux-3.18.0: some potential bugs
From: Jeff Kirsher @ 2014-12-20 10:35 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: todd.fujinaka, netdev, e1000-devel, linux.nics
In-Reply-To: <001101d01c2c$8dcc0040$a96400c0$@163.com>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
On Sat, 2014-12-20 at 16:11 +0800, Jia-Ju Bai wrote:
> I have actually tested igb driver on the real hardware(Intel 82575EB
> PCI-E
> Gigabit Ethernet Controller), and find some potential bugs:
> The target file is drivers/net/ethernet/intel/igb/igb_main.c
>
> (1) In the normal process of igb, pci_enable_pcie_error_reporting and
> pci_disable_pcie_error_reporting is called in pairs in igb_probe and
> igb_remove. However, when pci_enable_pcie_error_reporting has been
> called
> and alloc_etherdev_mqs in igb_probe is failed, "err_alloc_etherdev"
> segment
> in igb_probe is executed immediately to exit, but
> pci_disable_pcie_error_reporting is not called.
> (2) The same situation happens when pci_iomap in igb_probe is failed.
> (3) The same situation happens when igb_sw_init in igb_probe is
> failed.
> (4) The same situation happens when register_netdev in igb_probe is
> failed.
> (5) The same situation happens when igb_init_i2c in igb_probe is
> failed.
>
> (6) The function kcalloc is called by igb_sw_init when initializing
> the
> ethernet card driver, but kfree is not called when register_netdev in
> igb_probe is failed, which may cause memory leak.
> (7) The same situation happens when igb_init_i2c in igb_probe is
> failed.
> (8) The same situation happens when kzalloc in igb_alloc_q_vector is
> failed.
> (9) The same situation happens when igb_alloc_q_vector in
> igb_alloc_q_vectors is failed.
>
> (10) When igb_init_i2c in igb_probe is failed, igb_enable_sriov is
> called in
> igb_probe_vfs, but igb_disable_sriov is not called.
> (11) The same situation with [10] happens when register_netdev in
> igb_probe
> is failed.
>
> Meanwhile, I also write the patch to fix the bugs. I have run the
> patch on
> the hardware, it can work normally and fix the above bugs.
Was this a bug you actually saw? Or a theoretical bug based on code
review?
I do not mind adding this to my queue so that we can review and test the
patch, although this will cause a fair amount of regression testing.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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