I just want to send v2 patch with new mail thread with subject [PATCH v2] not reply I don't understand why v2 patch mail is followed previous mail thread. --no-chain-reply-to : fail ( this is wrong option for in this case) --subject-prefix "PATCH v2" : fail.. why? This is what I did for send patch file. git send-email --to stern@xxxxxxxxxxxxxxxxxxx --to gregkh@xxxxxxxxxxxxxxxxxxx --cc linux-usb@xxxxxxxxxxxxxxx --subject-prefix "PATCH v2" --annotate v2-0001-usb-core-update-comments-for-send-message-functio.patch Please, anybody help me to send patch with new mail thread with subject [PATCH v#] I am really sorry for noisy mail thread. Thanks jaejoong 2017-01-18 12:05 GMT+09:00 Jaejoong Kim <climbbb.kim@xxxxxxxxx>: > The commonly use of bottom halves are tasklet and workqueue. The big > difference between tasklet and workqueue is that the tasklet runs in > an interrupt context and the workqueue runs in a process context, > which means it can sleep if need be. > > The comment for usb_control/interrupt/bulk_msg() functions note that do > not use this function within an interrupt context, like a 'bottom half' > handler. With this comment, it makes confuse about usage of these > functions. > > To more clarify, remove 'bottom half' comment. > > Signed-off-by: Jaejoong Kim <climbbb.kim@xxxxxxxxx> > --- > Changes in v2: > - reformat comments within 80 column <Alan Stern> > - fix checkpatch warning about 75 column in commit message > --- > drivers/usb/core/message.c | 33 +++++++++++++++------------------ > 1 file changed, 15 insertions(+), 18 deletions(-) > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c > index dea5591..2184ef4 100644 > --- a/drivers/usb/core/message.c > +++ b/drivers/usb/core/message.c > @@ -122,12 +122,11 @@ static int usb_internal_control_msg(struct usb_device *usb_dev, > * This function sends a simple control message to a specified endpoint and > * waits for the message to complete, or timeout. > * > - * Don't use this function from within an interrupt context, like a bottom half > - * handler. If you need an asynchronous message, or need to send a message > - * from within interrupt context, use usb_submit_urb(). > - * If a thread in your driver uses this call, make sure your disconnect() > - * method can wait for it to complete. Since you don't have a handle on the > - * URB used, you can't cancel the request. > + * Don't use this function from within an interrupt context. If you need > + * an asynchronous message, or need to send a message from within interrupt > + * context, use usb_submit_urb(). If a thread in your driver uses this call, > + * make sure your disconnect() method can wait for it to complete. Since you > + * don't have a handle on the URB used, you can't cancel the request. > * > * Return: If successful, the number of bytes transferred. Otherwise, a negative > * error number. > @@ -173,12 +172,11 @@ EXPORT_SYMBOL_GPL(usb_control_msg); > * This function sends a simple interrupt message to a specified endpoint and > * waits for the message to complete, or timeout. > * > - * Don't use this function from within an interrupt context, like a bottom half > - * handler. If you need an asynchronous message, or need to send a message > - * from within interrupt context, use usb_submit_urb() If a thread in your > - * driver uses this call, make sure your disconnect() method can wait for it to > - * complete. Since you don't have a handle on the URB used, you can't cancel > - * the request. > + * Don't use this function from within an interrupt context. If you need > + * an asynchronous message, or need to send a message from within interrupt > + * context, use usb_submit_urb() If a thread in your driver uses this call, > + * make sure your disconnect() method can wait for it to complete. Since you > + * don't have a handle on the URB used, you can't cancel the request. > * > * Return: > * If successful, 0. Otherwise a negative error number. The number of actual > @@ -207,12 +205,11 @@ EXPORT_SYMBOL_GPL(usb_interrupt_msg); > * This function sends a simple bulk message to a specified endpoint > * and waits for the message to complete, or timeout. > * > - * Don't use this function from within an interrupt context, like a bottom half > - * handler. If you need an asynchronous message, or need to send a message > - * from within interrupt context, use usb_submit_urb() If a thread in your > - * driver uses this call, make sure your disconnect() method can wait for it to > - * complete. Since you don't have a handle on the URB used, you can't cancel > - * the request. > + * Don't use this function from within an interrupt context. If you need > + * an asynchronous message, or need to send a message from within interrupt > + * context, use usb_submit_urb() If a thread in your driver uses this call, > + * make sure your disconnect() method can wait for it to complete. Since you > + * don't have a handle on the URB used, you can't cancel the request. > * > * Because there is no usb_interrupt_msg() and no USBDEVFS_INTERRUPT ioctl, > * users are forced to abuse this routine by using it to submit URBs for > -- > 2.7.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
