HID: usbmouse: Avoid GFP_ATOMIC when GFP_KERNEL is possible

probe in usb don't need to be atomic. So GFP_KERNEL can be used here,
instead of GFP_ATOMIC.

Signed-off-by: Hyeonggon Yoo <redacted>
---
 drivers/hid/usbhid/usbmouse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
index 073127e65ac1..c89332017d5d 100644
--- a/drivers/hid/usbhid/usbmouse.c
+++ b/drivers/hid/usbhid/usbmouse.c

@@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
 	if (!mouse || !input_dev)
 		goto fail1;
 
-	mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
+	mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
 	if (!mouse->data)
 		goto fail1;
 

-- 
2.25.1

On Mon, May 24, 2021 at 11:57:43PM +0900, Hyeonggon Yoo wrote:

Hello for me it was simple and obvious patch.
Is there something wrong about it?

Then please let me know about it!

Thanks,
Hyeonggon

On Fri, May 28, 2021 at 01:45:17AM +0900, Hyeonggon Yoo wrote:

On Mon, May 24, 2021 at 11:57:43PM +0900, Hyeonggon Yoo wrote:

quoted

probe in usb don't need to be atomic. So GFP_KERNEL can be used here,
instead of GFP_ATOMIC.

Signed-off-by: Hyeonggon Yoo <redacted>
---
 drivers/hid/usbhid/usbmouse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c
index 073127e65ac1..c89332017d5d 100644
--- a/drivers/hid/usbhid/usbmouse.c
+++ b/drivers/hid/usbhid/usbmouse.c

@@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i
 	if (!mouse || !input_dev)
 		goto fail1;
 
-	mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma);
+	mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma);
 	if (!mouse->data)
 		goto fail1;
 

-- 
2.25.1

Hello for me it was simple and obvious patch.
Is there something wrong about it?

It has been only 4 days.  For a non-bugfix and for something that is
only a "cleanup" change, give it at least 2 weeks please.

Relax, there is no rush for stuff like this.

thanks,

greg k-h

On Thu, May 27, 2021 at 06:54:07PM +0200, Greg KH wrote:

It has been only 4 days.  For a non-bugfix and for something that is
only a "cleanup" change, give it at least 2 weeks please.

Relax, there is no rush for stuff like this.

Hello Greg!

Okay You are right. I'll relax...

I think I need to be familiar with the process :)

Thank you!
Hyeonggon

On Fri, May 28, 2021 at 02:05:36AM +0900, Hyeonggon Yoo wrote:

On Thu, May 27, 2021 at 06:54:07PM +0200, Greg KH wrote:

quoted

It has been only 4 days.  For a non-bugfix and for something that is
only a "cleanup" change, give it at least 2 weeks please.

Relax, there is no rush for stuff like this.

Hello Greg!

Okay You are right. I'll relax...

I think I need to be familiar with the process :)

Please go read Documentation/process/ for all of that while you wait :)

On Thu, May 27, 2021 at 07:11:24PM +0200, Greg KH wrote:

On Fri, May 28, 2021 at 02:05:36AM +0900, Hyeonggon Yoo wrote:

quoted

On Thu, May 27, 2021 at 06:54:07PM +0200, Greg KH wrote:

quoted

It has been only 4 days.  For a non-bugfix and for something that is
only a "cleanup" change, give it at least 2 weeks please.

Relax, there is no rush for stuff like this.

Hello Greg!

Okay You are right. I'll relax...

I think I need to be familiar with the process :)

Please go read Documentation/process/ for all of that while you wait :)

I'm reading it and Thanks for letting me know it.
it helps a lot... I should read it many times.

and the patch seems already applied to linux-next :)

Thanks,
Hyeonggon