On Tue, Sep 08, 2015 at 11:23:07AM +0900, Tony Cho wrote: > > > On 2015년 09월 08일 00:36, Chaehyun Lim wrote: > >This patch use kmalloc with GFP_ATOMIC instead of WILC_MALLOC. > >It is inside the spin lock region. > > > >Signed-off-by: Chaehyun Lim <chaehyun.lim@xxxxxxxxx> > >--- > > drivers/staging/wilc1000/wilc_msgqueue.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c b/drivers/staging/wilc1000/wilc_msgqueue.c > >index 76d2e63..41244ce 100644 > >--- a/drivers/staging/wilc1000/wilc_msgqueue.c > >+++ b/drivers/staging/wilc1000/wilc_msgqueue.c > >@@ -72,7 +72,7 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle, > > WILC_NULLCHECK(s32RetStatus, pstrMessage); > > pstrMessage->u32Length = u32SendBufferSize; > > pstrMessage->pstrNext = NULL; > >- pstrMessage->pvBuffer = WILC_MALLOC(u32SendBufferSize); > >+ pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC); > > WILC_NULLCHECK(s32RetStatus, pstrMessage->pvBuffer); > > memcpy(pstrMessage->pvBuffer, pvSendBuffer, u32SendBufferSize); > > I want just to let you know this file will be soon changed. That doesn't matter, the first one to submit a change goes "first", everything that comes afterward needs to deal with that. We never tell someone that a patch isn't ok just because at some time in the future something else might change. That drives away developers and was one of the primary reasons other open source kernels have failed in the past. greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
