From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: kernel test robot <lkp@intel.com>,
Norihiko Hama <Norihiko.Hama@alpsalpine.com>,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
linux-usb@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [usb:usb-testing 17/35] drivers/usb/storage/usb.c:141:21: error: incompatible pointer types passing 'unsigned int *' to parameter of type 'uint64_t *' (aka 'unsigned long long *')
Date: Wed, 1 May 2024 08:50:36 +0200 [thread overview]
Message-ID: <2024050141-remote-mockup-f933@gregkh> (raw)
In-Reply-To: <202405011431.PvaZHpRK-lkp@intel.com>
On Wed, May 01, 2024 at 02:32:56PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> head: ac6a205c5bef39d65ecd9f5dd2c1d75652c35405
> commit: 70d66b8e47e6fa031f541291e9dd3d7f0c44b41e [17/35] usb-storage: Optimize scan delay more precisely
I'm going to drop this commit from my tree now.
But really, it feels odd to have this parsing logic in a random driver
for something like handling floating point numbers "properly" from
userspace. Why isn't this in the core kernel somewhere? And, as that
was a rhetorical question, the answer is we probably shouldn't be
handling floating point number parsing in the kernel...
I understand the quest for handling error time outs "faster" when you
assume that you know that the error will never happen, but what's the
odds that it will end up happening...
there has to be a better way to do this.
thanks,
greg k-h
next prev parent reply other threads:[~2024-05-01 6:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 6:32 [usb:usb-testing 17/35] drivers/usb/storage/usb.c:141:21: error: incompatible pointer types passing 'unsigned int *' to parameter of type 'uint64_t *' (aka 'unsigned long long *') kernel test robot
2024-05-01 6:50 ` Greg Kroah-Hartman [this message]
2024-05-01 14:03 ` Alan Stern
2024-05-02 8:04 ` Norihiko Hama
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=2024050141-remote-mockup-f933@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Norihiko.Hama@alpsalpine.com \
--cc=linux-usb@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.