linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Enrico Weigelt, metux IT consult" <info@metux.net>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH] usb: make usb_interrupt_msg() a static inline
Date: Wed, 4 Dec 2019 18:20:42 +0100	[thread overview]
Message-ID: <20191204172042.GE3627415@kroah.com> (raw)
In-Reply-To: <20191204143035.31751-1-info@metux.net>

On Wed, Dec 04, 2019 at 03:30:35PM +0100, Enrico Weigelt, metux IT consult wrote:
> usb_interrupt_msg() effectively is just an alias for usb_bulk_msg(),
> no need for being an real function, thus converting it to an
> inline function.

Why?  What did you just save/help with here?

This actually made the code worse:

>  /**
> - * usb_interrupt_msg - Builds an interrupt urb, sends it off and waits for completion
> - * @usb_dev: pointer to the usb device to send the message to
> - * @pipe: endpoint "pipe" to send the message to
> - * @data: pointer to the data to send
> - * @len: length in bytes of the data to send
> - * @actual_length: pointer to a location to put the actual length transferred
> - *	in bytes
> - * @timeout: time in msecs to wait for the message to complete before
> - *	timing out (if 0 the wait is forever)
> - *
> - * Context: !in_interrupt ()
> - *
> - * 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. 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
> - * bytes transferred will be stored in the @actual_length parameter.
> - */
> -int usb_interrupt_msg(struct usb_device *usb_dev, unsigned int pipe,
> -		      void *data, int len, int *actual_length, int timeout)
> -{
> -	return usb_bulk_msg(usb_dev, pipe, data, len, actual_length, timeout);
> -}
> -EXPORT_SYMBOL_GPL(usb_interrupt_msg);

You now lost all of that wonderful documentation on how to use this
function, makeing the kernel harder to use instead of easier.

So this is a net-loss overall, ick, why???

greg k-h

  reply	other threads:[~2019-12-04 17:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 14:30 [PATCH] usb: make usb_interrupt_msg() a static inline Enrico Weigelt, metux IT consult
2019-12-04 17:20 ` Greg KH [this message]
2019-12-04 17:21 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191204172042.GE3627415@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=info@metux.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).