Re: [PATCH v7 00/17] wilc1000: move out of staging
On Wed, 1 Jul 2020 at 09:55, Pali Rohár wrote: > > On Tuesday 30 June 2020 03:17:01 ajay.kat...@microchip.com wrote: > > On 29/06/20 6:56 pm, Pali Rohár wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know > > > the content is safe > > > > > > On Tuesday 23 June 2020 11:00:04 ajay.kat...@microchip.com wrote: > > >> This patch series is to review and move wilc1000 driver out of staging. > > >> Most of the review comments received in [1] & [2] are addressed in the > > >> latest code. > > >> Please review and provide your inputs. > > > > > > Hello Ajay! Could you please move SDIO vendor/device ID definitions from > > > driver code wilc1000/sdio.c to common file include/linux/mmc/sdio_ids.h? > > > > > > > Currently, the wilc1000 driver movement changes are present in topic > > branch and yet to be merged to master branch. Would it be okay to submit > > the new patch once driver is merged to 'wireless-driver-next' master and > > branch is pulled into Greg's staging repo. > > I think it should be OK. But maybe Ulf as maintainer of mmc subsystem > could have opinion or react on this. That should be fine. Just keep me on cc so I can ack it. Potentially we may get some mergeconflict between the trees, but let's resolve that if/when that happens. Kind regards Uffe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH][next] staging: wfx: fix uninitialized variable bytes_done
From: Colin Ian King
The variable bytes_done is not initialized and hence the first
FIFO size check on bytes_done may be breaking prematurely from
the loop if bytes_done contains a large bogus uninitialized value.
Fix this by initializing bytes_done to zero.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: a9408ad79ff3 ("staging: wfx: load the firmware faster")
Signed-off-by: Colin Ian King
---
drivers/staging/wfx/fwio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/fwio.c b/drivers/staging/wfx/fwio.c
index d9a886f3e64b..206c6cf6511c 100644
--- a/drivers/staging/wfx/fwio.c
+++ b/drivers/staging/wfx/fwio.c
@@ -177,7 +177,7 @@ static int wait_ncp_status(struct wfx_dev *wdev, u32 status)
static int upload_firmware(struct wfx_dev *wdev, const u8 *data, size_t len)
{
int ret;
- u32 offs, bytes_done;
+ u32 offs, bytes_done = 0;
ktime_t now, start;
if (len % DNLD_BLOCK_SIZE) {
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][next] staging: wfx: fix uninitialized variable bytes_done
On Monday 6 July 2020 15:20:17 CEST Colin King wrote:
>
> From: Colin Ian King
>
> The variable bytes_done is not initialized and hence the first
> FIFO size check on bytes_done may be breaking prematurely from
> the loop if bytes_done contains a large bogus uninitialized value.
> Fix this by initializing bytes_done to zero.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: a9408ad79ff3 ("staging: wfx: load the firmware faster")
> Signed-off-by: Colin Ian King
Good catch!
I am surprised that my gcc hasn't caught that.
Reviewed-by: Jérôme Pouiller
> ---
> drivers/staging/wfx/fwio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wfx/fwio.c b/drivers/staging/wfx/fwio.c
> index d9a886f3e64b..206c6cf6511c 100644
> --- a/drivers/staging/wfx/fwio.c
> +++ b/drivers/staging/wfx/fwio.c
> @@ -177,7 +177,7 @@ static int wait_ncp_status(struct wfx_dev *wdev, u32
> status)
> static int upload_firmware(struct wfx_dev *wdev, const u8 *data, size_t len)
> {
> int ret;
> - u32 offs, bytes_done;
> + u32 offs, bytes_done = 0;
> ktime_t now, start;
>
> if (len % DNLD_BLOCK_SIZE) {
> --
> 2.27.0
>
>
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: Using comparison to true is error prone
clear below issues reported by checkpatch.pl:
CHECK: Using comparison to false is error prone
Signed-off-by: John Oldman
---
drivers/staging/rtl8192u/r8192U_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c
b/drivers/staging/rtl8192u/r8192U_dm.c
index c23e43b095d9..6b301acb584e 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -2240,7 +2240,7 @@ static void dm_ctstoself(struct net_device *dev)
unsigned long curTxOkCnt = 0;
unsigned long curRxOkCnt = 0;
- if (priv->ieee80211->bCTSToSelfEnable != true) {
+ if (!priv->ieee80211->bCTSToSelfEnable) {
pHTInfo->IOTAction &= ~HT_IOT_ACT_FORCED_CTS2SELF;
return;
}
@@ -2944,7 +2944,7 @@ static void dm_dynamic_txpower(struct net_device *dev)
unsigned int txhipower_threshold = 0;
unsigned int txlowpower_threshold = 0;
- if (priv->ieee80211->bdynamic_txpower_enable != true) {
+ if (!priv->ieee80211->bdynamic_txpower_enable) {
priv->bDynamicTxHighPower = false;
priv->bDynamicTxLowPower = false;
return;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
Hi Andy, Sorry for the delay in response. I will do what you suggest in your email. I do have one response to one of your comments below. On Thu, Jul 2, 2020 at 4:43 AM Andy Shevchenko wrote: > > On Wed, Jul 01, 2020 at 05:21:38PM -0400, Jim Quinlan wrote: > > The new field 'dma_range_map' in struct device is used to facilitate the > > use of single or multiple offsets between mapping regions of cpu addrs and > > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only > > capable of holding a single uniform offset and had no region bounds > > checking. > > > > The function of_dma_get_range() has been modified so that it takes a single > > argument -- the device node -- and returns a map, NULL, or an error code. > > The map is an array that holds the information regarding the DMA regions. > > Each range entry contains the address offset, the cpu_start address, the > > dma_start address, and the size of the region. > > > > of_dma_configure() is the typical manner to set range offsets but there are > > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel > > driver code. These cases now invoke the function > > dma_attach_offset_range(dev, cpu_addr, dma_addr, size). > > ... > > > + if (dev && dev->dma_range_map) > > + pfn -= (unsigned long)PFN_DOWN(dma_offset_from_phys_addr(dev, > > PFN_PHYS(pfn))); > > Instead of casting use PHYS_PFN() and it will be consistent with latter in > the same line. > > > + if (dev && dev->dma_range_map) > > + pfn += (unsigned long)PFN_DOWN(dma_offset_from_dma_addr(dev, > > addr)); > > Ditto. > > ... > > > + dev_err(dev, "set dma_offset%08llx%s\n", > > KEYSTONE_HIGH_PHYS_START > > + - KEYSTONE_LOW_PHYS_START, ret ? " failed" : ""); > > Please, avoid such indentation. > Better split it to the three lines, argument per line (expect dev which will > go > on the first one). > > This applies to all similar places. > > ... > > > unsigned long pfn = (dma_handle >> PAGE_SHIFT); > > PHYS_PFN() / PFN_DOWN() ? > > > + if (!WARN_ON(!dev) && dev->dma_range_map) > > + pfn += (unsigned long)PFN_DOWN(dma_offset_from_dma_addr(dev, > > dma_handle)); > > PHYS_PFN() ? > > ... > > > + r = kcalloc(num_ranges + 1, sizeof(struct bus_dma_region), > > GFP_KERNEL); > > sizeof(*r) ? > > > + if (!r) > > + return ERR_PTR(-ENOMEM); > > ... > > > + ret = IS_ERR(map) ? PTR_ERR(map) : 0; > > PTR_ERR_OR_ZERO() > > ... > > > + /* We want the offset map to be device-managed, so alloc & > > copy */ > > + dev->dma_range_map = devm_kcalloc(dev, num_ranges + 1, > > sizeof(*r), > > + GFP_KERNEL); > > The question is how many times per device lifetime this can be called? Someone else questioned this. There are two cases that come to mind: our overnight test which load/unloads the RC driver over and over, and a customer that does an unbind/bind of the RC driver when their EP is hung and wants to restart. Both cases are atypical and are weak arguments to justify the second copy. I will drop the copy. Thanks, Jim Quinlan Broadcom STB > > ... > > > > + if (!dev->dma_range_map) > > + return -ENOMEM; > > + memcpy((void *)dev->dma_range_map, map, sizeof(*r) * > > num_ranges + 1); > > If it's continuous, perhaps kmemdup() ? > > ... > > > + rc = IS_ERR(map) ? PTR_ERR(map) : 0; > > PTR_ERR_OR_ZERO() > > ... > > > + = dma_offset_from_phys_addr(dev, > > PFN_PHYS(mem->pfn_base)); > > + > > + return (dma_addr_t)PFN_PHYS(mem->pfn_base) - dma_offset; > > Looking at this more, I think you need to introduce in the same header (pfn.h) > something like: > > #define PFN_DMA_ADDR() > #define DMA_ADDR_PFN() > > -- > With Best Regards, > Andy Shevchenko > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE; KINDLY ACCEPT MY FUND PROPOSAL
From: Mrs. Maria Nelsoma I am Mrs. Maria Nelsoma Who married to Mr. Robert Nelsoma who worked in Many Embassy like USA, AUSTRALIA AND FRANCE before he finally end up in Benin Republic. We were married for 25 years without a child. He died after a brief illness that lasted for only four days. Before his death we were both born again Christian. Since his death I decided not to remarry or get a child outside my matrimonial home which the Bible is against. When my late husband was alive he deposited the sum of $4.2 Four Million Two hundred Thousand Dollars (4.2) Million U.S. Dollars) in the bank here in a fixed suspense account and he declare the fund where made for our family intending business, Presently, I am very sick at the Centre National Hospitalier et Universitaire (CNHU) Hospital here in Benin Republic, my doctor told me that I have serious cancer which the doctor gave me no assurance of surviving it and I have few time to live here on earth. I decided to use that fund to help the orphanages, widows, and the Less Privilege ones all over the world. Having known my condition according to the doctor I decided to donate this fund to a church or individual that will utilize this money the way I wish by helping the house of God or building. The Bible made us to understand that blessed is the hand that giveth. I took this decision because I don’t have any child that will inherit this money. I don’t want a situation where this money will be used in an ungodly way. This is why I am taking this decision. I am not afraid of death hence I know where I am going. I know that I am going to be in the bosom of the Lord. With God all things are possible. As soon as I receive your reply I shall give you the contact of the bank here in Benin Republic where my husband deposited the money. I want you and the church to always pray for me because the lord is my shepherd, my happiness is that I lived a life of a worthy of emulations. Whosoever that wants to serve the Lord must serve him in spirit and Truth. Please always be prayerful all through your life. Please assure me that you will act accordingly as I Stated herein. That you will not betray me or you shall take an Oath of this fund that you will never go against my last wish. Do not be afraid of the bank where the fund was deposited because the bank my husband deposited this fund has as Corresponding or Affiliated Bank in Europe and United State. Remain blessed in the Lord. Yours, Mrs. Maria Nelsoma ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
