[PATCH] FBTFT: fb_sh: Changed udelay() to usleep_range() based on the Document, Documentation/timers/timers-howto.rst Excerpt from the document: -SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms): * U

--- drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c index ec97ad27..471a145e3c00 100644 --- a/drivers/staging/fbtft/fb_agm1264k-fl.c +++

Your opportunity

Greetings, Find this mail very confidential. reply for more details Thanks. Peter Wong This email was sent by the shareware version of Postman Professional. ___ devel mailing list

Your opportunity

Greetings, Find this mail very confidential. reply for more details Thanks. Peter Wong This email was sent by the shareware version of Postman Professional. ___ devel mailing list

[PATCH v2] staging: wfx: Fix a memory leak in 'wfx_upload_beacon'

The current code is a no-op, because all it can do is 'dev_kfree_skb(NULL)' Remove the test before 'dev_kfree_skb()' Signed-off-by: Christophe JAILLET --- V2: remove the 'if(...)', 'dev_kfree_skb()' can handle NULL. --- drivers/staging/wfx/sta.c | 3 +-- 1 file changed, 1 insertion(+), 2

Re: [PATCH] staging: rtl8192u: fix potential infinite loop because loop counter being too small

Am 01.11.2019 15:51, schrieb Dan Carpenter: > On Fri, Nov 01, 2019 at 02:26:04PM +, Colin King wrote: >> From: Colin Ian King >> >> Currently the for-loop counter i is a u8 however it is being checked >> against a maximum value priv->ieee80211->LinkDetectInfo.SlotNum which is a >> u16.

Re: [PATCH resend] staging: vc04_services: replace g_free_fragments_mutex with spinlock

On Fri, Nov 01, 2019 at 11:29:49AM -0700, Davidlohr Bueso wrote: > There is no need to be using a semaphore, or a sleeping lock > in the first place: critical region is extremely short, does not > call into any blocking calls and furthermore lock and unlocking > operations occur in the same

Re: [PATCH resend] staging: vc04_services: replace g_free_fragments_mutex with spinlock

Hi Davidlohr, Am 01.11.19 um 19:29 schrieb Davidlohr Bueso: > There is no need to be using a semaphore, or a sleeping lock > in the first place: critical region is extremely short, does not > call into any blocking calls and furthermore lock and unlocking > operations occur in the same context. >

Re: [PATCH] staging: wfx: Fix a memory leak in 'wfx_upload_beacon'

On Fri, Nov 01, 2019 at 06:21:51PM +0100, Christophe JAILLET wrote: > The current code is a no-op, because all it can do is 'dev_kfree_skb(NULL)' > Revert the test to free skb, if not NULL. > > Signed-off-by: Christophe JAILLET > --- > This patch is purely speculative. > > The 'if (...)' could