[PATCH] staging: rtl8723bs: remove duplicate pstat->hwaddr check
IS_MCAST(pstat->hwaddr) checked twice in a row in
odm_RefreshRateAdaptiveMaskCE(). Remove the second check.
Signed-off-by: Denis Efremov
---
drivers/staging/rtl8723bs/hal/odm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm.c
b/drivers/staging/rtl8723bs/hal/odm.c
index f2a9e95a1563..5e432f1bc150 100644
--- a/drivers/staging/rtl8723bs/hal/odm.c
+++ b/drivers/staging/rtl8723bs/hal/odm.c
@@ -1114,8 +1114,6 @@ void odm_RefreshRateAdaptiveMaskCE(PDM_ODM_T pDM_Odm)
if (IS_STA_VALID(pstat)) {
if (IS_MCAST(pstat->hwaddr)) /* if (psta->mac_id == 1)
*/
continue;
- if (IS_MCAST(pstat->hwaddr))
- continue;
if (true == ODM_RAStateCheck(pDM_Odm,
pstat->rssi_stat.UndecoratedSmoothedPWDB, false, >rssi_level)) {
ODM_RT_TRACE(pDM_Odm, ODM_COMP_RA_MASK,
ODM_DBG_LOUD, ("RSSI:%d, RSSI_LEVEL:%d\n",
pstat->rssi_stat.UndecoratedSmoothedPWDB, pstat->rssi_level));
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On 6/16/20 9:53 PM, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: >> v4: >> - Break out the memzero_explicit() change as suggested by Dan Carpenter >> so that it can be backported to stable. >> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for >> now as there can be a bit more discussion on what is best. It will be >> introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? > > Many patches have been posted recently to fix mispairings > of specific types of alloc and free functions. I've prepared a coccinelle script to highlight these mispairings in a function a couple of days ago: https://lkml.org/lkml/2020/6/5/953 I've listed all the fixes in the commit message. Not so many mispairings actually, and most of them are harmless like: kmalloc(E) -> kvfree(E) However, coccinelle script can't detect cross-functions mispairings, i.e. allocation in one function, free in another funtion. Thanks, Denis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
Hi,
On 09.10.2019 12:35, Hans de Goede wrote:
> Hi Denis,
>
> On 30-09-2019 13:01, Denis Efremov wrote:
>> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
>> called with "src == NULL && len == 0". This is an undefined behavior.
>> Moreover this if pre-condition "pBufLen && (*pBufLen == 0) && !pBuf"
>> is constantly false because it is a nested if in the else brach, i.e.,
>> "if (cond) { ... } else { if (cond) {...} }". This patch alters the
>> if condition to check "pBufLen && pBuf" pointers are not NULL.
>>
>> Cc: Greg Kroah-Hartman
>> Cc: Hans de Goede
>> Cc: Bastien Nocera
>> Cc: Larry Finger
>> Cc: Jes Sorensen
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Denis Efremov
>> ---
>> Not tested. I don't have the hardware. The fix is based on my guess.
>
> Thsnk you for your patch.
>
> So I've been doing some digging and this code normally never executes.
>
> For this to execute the user would need to change the rtw_load_phy_file module
> param from its default of 0x44 (LOAD_BB_PG_PARA_FILE |
> LOAD_RF_TXPWR_LMT_PARA_FILE)
> to something which includes 0x02 (LOAD_BB_PARA_FILE) as mask.
>
> And even with that param set for this code to actually do something /
> for pBuf to ever not be NULL the following conditions would have to
> be true:
>
> 1) Set the rtw_load_phy_file module param from its default of
> 0x44 (LOAD_BB_PG_PARA_FILE | LOAD_RF_TXPWR_LMT_PARA_FILE) to something
> which includes 0x02 as mask; and
> 2) Set rtw_phy_file_path module parameter to say "/lib/firmware/"; and
> 3) Store a /lib/firmware/rtl8723b/PHY_REG.txt file in the expected format.
>
> So I've come to the conclusion that all the phy_Config*WithParaFile functions
> (and a bunch of stuff they use) can be removed.
>
> I will prepare and submit a patch for this.
>
Thank you for perfect investigation! I can only agree with you, because this
code is buggy. It looks like no one faced this bug previously and the code
can be safely removed.
Best Regards,
Denis
>
>>
>> drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> index 6539bee9b5ba..0902dc3c1825 100644
>> --- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> +++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> @@ -2320,7 +2320,7 @@ int phy_ConfigBBWithParaFile(
>> }
>> }
>> } else {
>> - if (pBufLen && (*pBufLen == 0) && !pBuf) {
>> + if (pBufLen && pBuf) {
>> memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
>> rtStatus = _SUCCESS;
>> } else
>> @@ -2752,7 +2752,7 @@ int PHY_ConfigRFWithParaFile(
>> }
>> }
>> } else {
>> - if (pBufLen && (*pBufLen == 0) && !pBuf) {
>> + if (pBufLen && pBuf) {
>> memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
>> rtStatus = _SUCCESS;
>> } else
>>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: fix uninitialized variable
Hi, On 10/3/19 2:26 PM, Dan Carpenter wrote: > On Wed, Oct 02, 2019 at 08:41:03PM +0300, Denis Efremov wrote: >> The result variable in prism2_connect() can be used uninitialized on path >> !channel --> ... --> is_wep --> sme->key --> sme->key_idx >= NUM_WEPKEYS. >> This patch initializes result with 0. >> >> Cc: Greg Kroah-Hartman >> Cc: sta...@vger.kernel.org >> Signed-off-by: Denis Efremov >> --- >> drivers/staging/wlan-ng/cfg80211.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/wlan-ng/cfg80211.c >> b/drivers/staging/wlan-ng/cfg80211.c >> index eee1998c4b18..d426905e187e 100644 >> --- a/drivers/staging/wlan-ng/cfg80211.c >> +++ b/drivers/staging/wlan-ng/cfg80211.c >> @@ -441,7 +441,7 @@ static int prism2_connect(struct wiphy *wiphy, struct >> net_device *dev, >> int chan = -1; >> int is_wep = (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_WEP40) || >> (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_WEP104); >> -int result; >> +int result = 0; >> int err = 0; >> > > I can't see any reason why we should have both "err" and "result". > Maybe in olden times "result" used to save positive error codes instead > of negative error codes but now it's just negatives and zero on success. > There is no reason for the exit label either, we could just return > directly. > > So could you redo it and get rid of "result" entirely? Otherwise it > just causes more bugs like this. > Yes, of course. I will prepare v2. Thanks, Denis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: fix uninitialized variable
The result variable in prism2_connect() can be used uninitialized on path !channel --> ... --> is_wep --> sme->key --> sme->key_idx >= NUM_WEPKEYS. This patch initializes result with 0. Cc: Greg Kroah-Hartman Cc: sta...@vger.kernel.org Signed-off-by: Denis Efremov --- drivers/staging/wlan-ng/cfg80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/cfg80211.c b/drivers/staging/wlan-ng/cfg80211.c index eee1998c4b18..d426905e187e 100644 --- a/drivers/staging/wlan-ng/cfg80211.c +++ b/drivers/staging/wlan-ng/cfg80211.c @@ -441,7 +441,7 @@ static int prism2_connect(struct wiphy *wiphy, struct net_device *dev, int chan = -1; int is_wep = (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_WEP40) || (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_WEP104); - int result; + int result = 0; int err = 0; /* Set the channel */ -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
On 01.10.2019 21:58, Dan Carpenter wrote: > On Tue, Oct 01, 2019 at 06:13:21PM +0300, Denis Efremov wrote: >> Just found an official documentation to this issue: >> https://gcc.gnu.org/gcc-4.9/porting_to.html >> "Null pointer checks may be optimized away more aggressively >> ... >> The pointers passed to memmove (and similar functions in ) must be >> non-null >> even when nbytes==0, so GCC can use that information to remove the check >> after the >> memmove call. Calling copy(p, NULL, 0) can therefore deference a null >> pointer and crash." >> > > Correct. In glibc those functions are annotated as non-NULL. > > extern void *memcpy (void *__restrict __dest, const void *__restrict __src, > size_t __n) __THROW __nonnull ((1, 2)); > > We aren't going to do that in the kernel. A second difference is that > in the kernel we use -fno-delete-null-pointer-checks so it doesn't > delete the NULL checks. > Thank you for the clarification. This is really helpful. Best regards, Denis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
On 10/1/19 5:36 PM, David Laight wrote: >> From: Dan Carpenter >> Sent: 01 October 2019 14:57 >> Subject: Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls > ... >> That's true for glibc memcpy() but not for the kernel memcpy(). In the >> kernel there are lots of places which do a zero size memcpy(). > > And probably from NULL (or even garbage) pointers. > > After all a pointer to the end of an array (a + ARRAY_SIZE(a)) is valid > but must not be dereferenced - so memcpy() can't dereference it's > source address when the length is zero. > >> The glibc attitude is "the standard allows us to put knives here" so >> let's put knives everywhere in the path. And the GCC attitude is let's >> silently remove NULL checks instead of just printing a warning that the >> NULL check isn't required... It could really make someone despondent. > > gcc is the one that add knives... > Just found an official documentation to this issue: https://gcc.gnu.org/gcc-4.9/porting_to.html "Null pointer checks may be optimized away more aggressively ... The pointers passed to memmove (and similar functions in ) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash." But again, I would say that the bug in this code is because the if condition was copy-pasted and it should be inverted. Thanks, Denis ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
On 9/30/19 4:18 PM, David Laight wrote:
> From: Denis Efremov
>> Sent: 30 September 2019 12:02
>> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
>> called with "src == NULL && len == 0". This is an undefined behavior.
>
> I'm pretty certain it is well defined (to do nothing).
>
>> Moreover this if pre-condition "pBufLen && (*pBufLen == 0) && !pBuf"
>> is constantly false because it is a nested if in the else brach, i.e.,
>> "if (cond) { ... } else { if (cond) {...} }". This patch alters the
>> if condition to check "pBufLen && pBuf" pointers are not NULL.
>>
> ...
>> ---
>> Not tested. I don't have the hardware. The fix is based on my guess.
>>
>> drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> index 6539bee9b5ba..0902dc3c1825 100644
>> --- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> +++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> @@ -2320,7 +2320,7 @@ int phy_ConfigBBWithParaFile(
>> }
>> }
>> } else {
>> -if (pBufLen && (*pBufLen == 0) && !pBuf) {
>> +if (pBufLen && pBuf) {
>> memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
>
> The existing code is clearly garbage.
> It only ever does memcpy(tgt, NULL, 0).
>
> Under the assumption that the code has been tested the copy clearly isn't
> needed at all
> and can be deleted completely!
Initially I also thought that this is just a dead code and it could be simply
removed. However, if
we look at it more carefully, this if condition looks like a copy-paste error:
if (pBufLen && (*pBufLen == 0) && !pBuf) {
// get proper len
// allocate pBuf
...
memcpy(pBuf, pHalData->para_file_buf, rlen);
...
} else {
if (pBufLen && (*pBufLen == 0) && !pBuf) { // <== condition in patch
memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
rtStatus = _SUCCESS;
} else
DBG_871X("%s(): Critical Error !!!\n", __func__);
}
Thus, I think it will be incorrect to delete the second memcpy.
>
> OTOH if the code hasn't been tested maybe the entire source file should be
> removed :-)
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
On 9/30/19 4:18 PM, David Laight wrote:
> From: Denis Efremov
>> Sent: 30 September 2019 12:02
>> memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
>> called with "src == NULL && len == 0". This is an undefined behavior.
>
> I'm pretty certain it is well defined (to do nothing).
Well, technically you are right. However, UBSAN warns about passing NULL
to memcpy and from the formal point of view this is an undefined behavior [1].
There were a discussion [2] about interesting implication of assuming that
memcpy with 0 size and NULL pointer is fine. This could result in that compiler
assume that pointer is not NULL. However, this is not the case here since
this "if then" branch is a dead code in it's current form. I just find this
piece of code very funny regarding this patch [3].
[1]
https://stackoverflow.com/questions/5243012/is-it-guaranteed-to-be-safe-to-perform-memcpy0-0-0
[2]
https://groups.google.com/forum/#!msg/syzkaller-netbsd-bugs/8B4CIKN0Xz8/wRvIUWxiAgAJ
[3]
https://github.com/torvalds/linux/commit/8f884e76cae65af65c6bec759a17cb0527c54a15#diff-a476c238511f9374c2f1b947fdaffbbcL2339
>
>> Moreover this if pre-condition "pBufLen && (*pBufLen == 0) && !pBuf"
>> is constantly false because it is a nested if in the else brach, i.e.,
>> "if (cond) { ... } else { if (cond) {...} }". This patch alters the
>> if condition to check "pBufLen && pBuf" pointers are not NULL.
>>
> ...
>> ---
>> Not tested. I don't have the hardware. The fix is based on my guess.
>>
>> drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> index 6539bee9b5ba..0902dc3c1825 100644
>> --- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> +++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
>> @@ -2320,7 +2320,7 @@ int phy_ConfigBBWithParaFile(
>> }
>> }
>> } else {
>> -if (pBufLen && (*pBufLen == 0) && !pBuf) {
>> +if (pBufLen && pBuf) {
>> memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
>
> The existing code is clearly garbage.
> It only ever does memcpy(tgt, NULL, 0).
>
> Under the assumption that the code has been tested the copy clearly isn't
> needed at all
> and can be deleted completely!
>
> OTOH if the code hasn't been tested maybe the entire source file should be
> removed :-)
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: hal: Fix memcpy calls
memcpy() in phy_ConfigBBWithParaFile() and PHY_ConfigRFWithParaFile() is
called with "src == NULL && len == 0". This is an undefined behavior.
Moreover this if pre-condition "pBufLen && (*pBufLen == 0) && !pBuf"
is constantly false because it is a nested if in the else brach, i.e.,
"if (cond) { ... } else { if (cond) {...} }". This patch alters the
if condition to check "pBufLen && pBuf" pointers are not NULL.
Cc: Greg Kroah-Hartman
Cc: Hans de Goede
Cc: Bastien Nocera
Cc: Larry Finger
Cc: Jes Sorensen
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov
---
Not tested. I don't have the hardware. The fix is based on my guess.
drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
index 6539bee9b5ba..0902dc3c1825 100644
--- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
@@ -2320,7 +2320,7 @@ int phy_ConfigBBWithParaFile(
}
}
} else {
- if (pBufLen && (*pBufLen == 0) && !pBuf) {
+ if (pBufLen && pBuf) {
memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
rtStatus = _SUCCESS;
} else
@@ -2752,7 +2752,7 @@ int PHY_ConfigRFWithParaFile(
}
}
} else {
- if (pBufLen && (*pBufLen == 0) && !pBuf) {
+ if (pBufLen && pBuf) {
memcpy(pHalData->para_file_buf, pBuf, *pBufLen);
rtStatus = _SUCCESS;
} else
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND v3 00/26] Add definition for the number of standard PCI BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END, but this is error-prone because it requires "i <= PCI_STD_RESOURCE_END" rather than something like "i < PCI_STD_NUM_BARS". We could add such a definition and use it the same way PCI_SRIOV_NUM_BARS is used. The patchset also replaces constant (6) with new define PCI_STD_NUM_BARS where appropriate and removes local declarations for the number of PCI BARs. Changes in v3: - Updated commits description. - Refactored "< PCI_ROM_RESOURCE" with "< PCI_STD_NUM_BARS" in loops. - Refactored "<= BAR_5" with "< PCI_STD_NUM_BARS" in loops. - Removed local define GASKET_NUM_BARS. - Removed local define PCI_NUM_BAR_RESOURCES. Changes in v2: - Reversed checks in pci_iomap_range,pci_iomap_wc_range. - Refactored loops in vfio_pci to keep PCI_STD_RESOURCES. - Added 2 new patches to replace the magic constant with new define. - Splitted net patch in v1 to separate stmmac and dwc-xlgmac patches. Denis Efremov (26): PCI: Add define for the number of standard PCI BARs PCI: hv: Use PCI_STD_NUM_BARS PCI: dwc: Use PCI_STD_NUM_BARS PCI: endpoint: Use PCI_STD_NUM_BARS misc: pci_endpoint_test: Use PCI_STD_NUM_BARS s390/pci: Use PCI_STD_NUM_BARS x86/PCI: Loop using PCI_STD_NUM_BARS alpha/PCI: Use PCI_STD_NUM_BARS ia64: Use PCI_STD_NUM_BARS stmmac: pci: Loop using PCI_STD_NUM_BARS net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS ixgb: use PCI_STD_NUM_BARS e1000: Use PCI_STD_NUM_BARS rapidio/tsi721: Loop using PCI_STD_NUM_BARS efifb: Loop using PCI_STD_NUM_BARS fbmem: use PCI_STD_NUM_BARS vfio_pci: Loop using PCI_STD_NUM_BARS scsi: pm80xx: Use PCI_STD_NUM_BARS ata: sata_nv: Use PCI_STD_NUM_BARS staging: gasket: Use PCI_STD_NUM_BARS serial: 8250_pci: Use PCI_STD_NUM_BARS pata_atp867x: Use PCI_STD_NUM_BARS memstick: use PCI_STD_NUM_BARS USB: core: Use PCI_STD_NUM_BARS usb: pci-quirks: Use PCI_STD_NUM_BARS devres: use PCI_STD_NUM_BARS arch/alpha/kernel/pci-sysfs.c | 8 ++--- arch/ia64/sn/pci/pcibr/pcibr_dma.c| 4 +-- arch/s390/include/asm/pci.h | 5 +-- arch/s390/include/asm/pci_clp.h | 6 ++-- arch/s390/pci/pci.c | 16 +- arch/s390/pci/pci_clp.c | 6 ++-- arch/x86/pci/common.c | 2 +- arch/x86/pci/intel_mid_pci.c | 2 +- drivers/ata/pata_atp867x.c| 2 +- drivers/ata/sata_nv.c | 2 +- drivers/memstick/host/jmb38x_ms.c | 2 +- drivers/misc/pci_endpoint_test.c | 8 ++--- drivers/net/ethernet/intel/e1000/e1000.h | 1 - drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +- drivers/net/ethernet/intel/ixgb/ixgb.h| 1 - drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +- .../net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +-- .../net/ethernet/synopsys/dwc-xlgmac-pci.c| 2 +- drivers/pci/controller/dwc/pci-dra7xx.c | 2 +- .../pci/controller/dwc/pci-layerscape-ep.c| 2 +- drivers/pci/controller/dwc/pcie-artpec6.c | 2 +- .../pci/controller/dwc/pcie-designware-plat.c | 2 +- drivers/pci/controller/dwc/pcie-designware.h | 2 +- drivers/pci/controller/pci-hyperv.c | 10 +++--- drivers/pci/endpoint/functions/pci-epf-test.c | 10 +++--- drivers/pci/pci-sysfs.c | 4 +-- drivers/pci/pci.c | 13 drivers/pci/proc.c| 4 +-- drivers/pci/quirks.c | 4 +-- drivers/rapidio/devices/tsi721.c | 2 +- drivers/scsi/pm8001/pm8001_hwi.c | 2 +- drivers/scsi/pm8001/pm8001_init.c | 2 +- drivers/staging/gasket/gasket_constants.h | 3 -- drivers/staging/gasket/gasket_core.c | 12 +++ drivers/staging/gasket/gasket_core.h | 4 +-- drivers/tty/serial/8250/8250_pci.c| 8 ++--- drivers/usb/core/hcd-pci.c| 2 +- drivers/usb/host/pci-quirks.c | 2 +- drivers/vfio/pci/vfio_pci.c | 11 --- drivers/vfio/pci/vfio_pci_config.c| 32 ++- drivers/vfio/pci/vfio_pci_private.h | 4 +-- drivers/video/fbdev/core/fbmem.c | 4 +-- drivers/video/fbdev/efifb.c | 2 +- include/linux/pci-epc.h | 2 +- include/linux/pci.h | 2 +- include/uapi/linux/pci_regs.h | 1 + lib/devres.c | 2 +- 47 files changed, 112 insertions(+), 115 deletions(-) -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: fix HighestRate check in odm_ARFBRefresh_8188E()
It's incorrect to compare HighestRate with 0x0b twice in the following manner "if (HighestRate > 0x0b) ... else if (HighestRate > 0x0b) ...". The "else if" branch is constantly false. The second comparision should be with 0x03 according to the max_rate_idx in ODM_RAInfo_Init(). Cc: Larry Finger Cc: Greg Kroah-Hartman Cc: Michael Straube Cc: sta...@vger.kernel.org Signed-off-by: Denis Efremov --- drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c index 9ddd51685063..5792f491b59a 100644 --- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c +++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c @@ -409,7 +409,7 @@ static int odm_ARFBRefresh_8188E(struct odm_dm_struct *dm_odm, struct odm_ra_inf pRaInfo->PTModeSS = 3; else if (pRaInfo->HighestRate > 0x0b) pRaInfo->PTModeSS = 2; - else if (pRaInfo->HighestRate > 0x0b) + else if (pRaInfo->HighestRate > 0x03) pRaInfo->PTModeSS = 1; else pRaInfo->PTModeSS = 0; -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 20/26] staging: gasket: Use PCI_STD_NUM_BARS
Remove local definition GASKET_NUM_BARS for the number of PCI BARs and use
global one PCI_STD_NUM_BARS instead.
Cc: Rob Springer
Cc: Todd Poynor
Cc: Ben Chan
Signed-off-by: Denis Efremov
---
drivers/staging/gasket/gasket_constants.h | 3 ---
drivers/staging/gasket/gasket_core.c | 12 ++--
drivers/staging/gasket/gasket_core.h | 4 ++--
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/gasket/gasket_constants.h
b/drivers/staging/gasket/gasket_constants.h
index 50d87c7b178c..9ea9c8833f27 100644
--- a/drivers/staging/gasket/gasket_constants.h
+++ b/drivers/staging/gasket/gasket_constants.h
@@ -13,9 +13,6 @@
/* The maximum devices per each type. */
#define GASKET_DEV_MAX 256
-/* The number of supported (and possible) PCI BARs. */
-#define GASKET_NUM_BARS 6
-
/* The number of supported Gasket page tables per device. */
#define GASKET_MAX_NUM_PAGE_TABLES 1
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging/gasket/gasket_core.c
index 13179f063a61..cd8be80d2076 100644
--- a/drivers/staging/gasket/gasket_core.c
+++ b/drivers/staging/gasket/gasket_core.c
@@ -371,7 +371,7 @@ static int gasket_setup_pci(struct pci_dev *pci_dev,
{
int i, mapped_bars, ret;
- for (i = 0; i < GASKET_NUM_BARS; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
ret = gasket_map_pci_bar(gasket_dev, i);
if (ret) {
mapped_bars = i;
@@ -393,7 +393,7 @@ static void gasket_cleanup_pci(struct gasket_dev
*gasket_dev)
{
int i;
- for (i = 0; i < GASKET_NUM_BARS; i++)
+ for (i = 0; i < PCI_STD_NUM_BARS; i++)
gasket_unmap_pci_bar(gasket_dev, i);
}
@@ -493,7 +493,7 @@ static ssize_t gasket_sysfs_data_show(struct device *device,
(enum gasket_sysfs_attribute_type)gasket_attr->data.attr_type;
switch (sysfs_type) {
case ATTR_BAR_OFFSETS:
- for (i = 0; i < GASKET_NUM_BARS; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
bar_desc = _desc->bar_descriptions[i];
if (bar_desc->size == 0)
continue;
@@ -505,7 +505,7 @@ static ssize_t gasket_sysfs_data_show(struct device *device,
}
break;
case ATTR_BAR_SIZES:
- for (i = 0; i < GASKET_NUM_BARS; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
bar_desc = _desc->bar_descriptions[i];
if (bar_desc->size == 0)
continue;
@@ -556,7 +556,7 @@ static ssize_t gasket_sysfs_data_show(struct device *device,
ret = snprintf(buf, PAGE_SIZE, "%d\n", gasket_dev->reset_count);
break;
case ATTR_USER_MEM_RANGES:
- for (i = 0; i < GASKET_NUM_BARS; ++i) {
+ for (i = 0; i < PCI_STD_NUM_BARS; ++i) {
current_written =
gasket_write_mappable_regions(buf, driver_desc,
i);
@@ -736,7 +736,7 @@ static int gasket_get_bar_index(const struct gasket_dev
*gasket_dev,
const struct gasket_driver_desc *driver_desc;
driver_desc = gasket_dev->internal_desc->driver_desc;
- for (i = 0; i < GASKET_NUM_BARS; ++i) {
+ for (i = 0; i < PCI_STD_NUM_BARS; ++i) {
struct gasket_bar_desc bar_desc =
driver_desc->bar_descriptions[i];
diff --git a/drivers/staging/gasket/gasket_core.h
b/drivers/staging/gasket/gasket_core.h
index be44ac1e3118..c417acadb0d5 100644
--- a/drivers/staging/gasket/gasket_core.h
+++ b/drivers/staging/gasket/gasket_core.h
@@ -268,7 +268,7 @@ struct gasket_dev {
char kobj_name[GASKET_NAME_MAX];
/* Virtual address of mapped BAR memory range. */
- struct gasket_bar_data bar_data[GASKET_NUM_BARS];
+ struct gasket_bar_data bar_data[PCI_STD_NUM_BARS];
/* Coherent buffer. */
struct gasket_coherent_buffer coherent_buffer;
@@ -369,7 +369,7 @@ struct gasket_driver_desc {
/* Set of 6 bar descriptions that describe all PCIe bars.
* Note that BUS/AXI devices (i.e. non PCI devices) use those.
*/
- struct gasket_bar_desc bar_descriptions[GASKET_NUM_BARS];
+ struct gasket_bar_desc bar_descriptions[PCI_STD_NUM_BARS];
/*
* Coherent buffer description.
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 00/26] Add definition for the number of standard PCI BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END, but this is error-prone because it requires "i <= PCI_STD_RESOURCE_END" rather than something like "i < PCI_STD_NUM_BARS". We could add such a definition and use it the same way PCI_SRIOV_NUM_BARS is used. The patchset also replaces constant (6) with new define PCI_STD_NUM_BARS where appropriate and removes local declarations for the number of PCI BARs. Changes in v3: - Updated commits description. - Refactored "< PCI_ROM_RESOURCE" with "< PCI_STD_NUM_BARS" in loops. - Refactored "<= BAR_5" with "< PCI_STD_NUM_BARS" in loops. - Removed local define GASKET_NUM_BARS. - Removed local define PCI_NUM_BAR_RESOURCES. Changes in v2: - Reversed checks in pci_iomap_range,pci_iomap_wc_range. - Refactored loops in vfio_pci to keep PCI_STD_RESOURCES. - Added 2 new patches to replace the magic constant with new define. - Splitted net patch in v1 to separate stmmac and dwc-xlgmac patches. Denis Efremov (26): PCI: Add define for the number of standard PCI BARs PCI: hv: Use PCI_STD_NUM_BARS PCI: dwc: Use PCI_STD_NUM_BARS PCI: endpoint: Use PCI_STD_NUM_BARS misc: pci_endpoint_test: Use PCI_STD_NUM_BARS s390/pci: Use PCI_STD_NUM_BARS x86/PCI: Loop using PCI_STD_NUM_BARS alpha/PCI: Use PCI_STD_NUM_BARS ia64: Use PCI_STD_NUM_BARS stmmac: pci: Loop using PCI_STD_NUM_BARS net: dwc-xlgmac: Loop using PCI_STD_NUM_BARS ixgb: use PCI_STD_NUM_BARS e1000: Use PCI_STD_NUM_BARS rapidio/tsi721: Loop using PCI_STD_NUM_BARS efifb: Loop using PCI_STD_NUM_BARS fbmem: use PCI_STD_NUM_BARS vfio_pci: Loop using PCI_STD_NUM_BARS scsi: pm80xx: Use PCI_STD_NUM_BARS ata: sata_nv: Use PCI_STD_NUM_BARS staging: gasket: Use PCI_STD_NUM_BARS serial: 8250_pci: Use PCI_STD_NUM_BARS pata_atp867x: Use PCI_STD_NUM_BARS memstick: use PCI_STD_NUM_BARS USB: core: Use PCI_STD_NUM_BARS usb: pci-quirks: Use PCI_STD_NUM_BARS devres: use PCI_STD_NUM_BARS arch/alpha/kernel/pci-sysfs.c | 8 ++--- arch/ia64/sn/pci/pcibr/pcibr_dma.c| 4 +-- arch/s390/include/asm/pci.h | 5 +-- arch/s390/include/asm/pci_clp.h | 6 ++-- arch/s390/pci/pci.c | 16 +- arch/s390/pci/pci_clp.c | 6 ++-- arch/x86/pci/common.c | 2 +- arch/x86/pci/intel_mid_pci.c | 2 +- drivers/ata/pata_atp867x.c| 2 +- drivers/ata/sata_nv.c | 2 +- drivers/memstick/host/jmb38x_ms.c | 2 +- drivers/misc/pci_endpoint_test.c | 8 ++--- drivers/net/ethernet/intel/e1000/e1000.h | 1 - drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +- drivers/net/ethernet/intel/ixgb/ixgb.h| 1 - drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +- .../net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +-- .../net/ethernet/synopsys/dwc-xlgmac-pci.c| 2 +- drivers/pci/controller/dwc/pci-dra7xx.c | 2 +- .../pci/controller/dwc/pci-layerscape-ep.c| 2 +- drivers/pci/controller/dwc/pcie-artpec6.c | 2 +- .../pci/controller/dwc/pcie-designware-plat.c | 2 +- drivers/pci/controller/dwc/pcie-designware.h | 2 +- drivers/pci/controller/pci-hyperv.c | 10 +++--- drivers/pci/endpoint/functions/pci-epf-test.c | 10 +++--- drivers/pci/pci-sysfs.c | 4 +-- drivers/pci/pci.c | 13 drivers/pci/proc.c| 4 +-- drivers/pci/quirks.c | 4 +-- drivers/rapidio/devices/tsi721.c | 2 +- drivers/scsi/pm8001/pm8001_hwi.c | 2 +- drivers/scsi/pm8001/pm8001_init.c | 2 +- drivers/staging/gasket/gasket_constants.h | 3 -- drivers/staging/gasket/gasket_core.c | 12 +++ drivers/staging/gasket/gasket_core.h | 4 +-- drivers/tty/serial/8250/8250_pci.c| 8 ++--- drivers/usb/core/hcd-pci.c| 2 +- drivers/usb/host/pci-quirks.c | 2 +- drivers/vfio/pci/vfio_pci.c | 11 --- drivers/vfio/pci/vfio_pci_config.c| 32 ++- drivers/vfio/pci/vfio_pci_private.h | 4 +-- drivers/video/fbdev/core/fbmem.c | 4 +-- drivers/video/fbdev/efifb.c | 2 +- include/linux/pci-epc.h | 2 +- include/linux/pci.h | 2 +- include/uapi/linux/pci_regs.h | 1 + lib/devres.c | 2 +- 47 files changed, 112 insertions(+), 115 deletions(-) -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
