From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Felipe Balbi <balbi@kernel.org>,
Jakob Koschel <jakobkoschel@gmail.com>,
Randy Dunlap <rdunlap@infradead.org>,
Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH] USB: gadget: dummy_hcd: switch char * to u8 *
Date: Sun, 23 Oct 2022 17:53:19 +0200 [thread overview]
Message-ID: <Y1Vjb9v2ggSjhRbc@kroah.com> (raw)
In-Reply-To: <CAHk-=wggc19mf+WR=eg7h7MfVVNbE1c8b5vcOc6wmDASNTMddg@mail.gmail.com>
On Fri, Oct 21, 2022 at 10:30:37AM -0700, Linus Torvalds wrote:
> On Thu, Oct 20, 2022 at 11:44 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > The function handle_control_request() casts the urb buffer to a char *,
> > and then treats it like a unsigned char buffer when assigning data to
> > it. On some architectures, "char" is really signed, so let's just
> > properly set this pointer to a u8 to take away any potential problems as
> > that's what is really wanted here.
>
> I think you might as well also remove the cast that was always a bit odd:
>
> buf[0] = (u8)dum->devstatus;
>
> although maybe it's intentional ("look, ma, I'm truncating this
> value") because 'devstatus' is a 'u16' type?
(adding Alan as he's the owner of this file now)
Yes, devstatus is a u16 as that's what the USB spec says it should be,
but so far only 7 of the lower bits have been used. I guess to do this
properly we should also copy the upper 8 bits in to buf[1], eventhough
in reality it's only ever going to be 0x00 for now.
Although if we ever do get another 2 status bits defined, this code will
break so we probably should do that too.
I'll go do that for a v2 of this and properly comment it.
> I suspect a comment would be more readable than an odd cast that
> doesn't actually change anything (since the assignment does it
> anyway).
>
> Or maybe people wrote it that way on purpose, and used that variable
> name on purpose.
>
> Because 'dum' is Swedish for 'stupid', and maybe there's a coded
> message in that driver?
That whole driver is called "dummy" as it's a "fake" driver, not a
"stupid" one :)
thanks,
greg k-h
next prev parent reply other threads:[~2022-10-23 15:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 6:44 [PATCH] USB: gadget: dummy_hcd: switch char * to u8 * Greg Kroah-Hartman
2022-10-21 17:30 ` Linus Torvalds
2022-10-21 22:02 ` David Laight
2022-10-23 15:53 ` Greg Kroah-Hartman [this message]
2022-10-23 16:04 ` Greg Kroah-Hartman
2022-10-23 16:46 ` Linus Torvalds
2022-10-23 16:46 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2024-03-26 16:03 Greg Kroah-Hartman
2024-03-26 16:16 ` Linus Torvalds
2024-03-26 16:29 ` Greg Kroah-Hartman
2024-03-26 16:26 ` Alan Stern
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=Y1Vjb9v2ggSjhRbc@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=balbi@kernel.org \
--cc=ira.weiny@intel.com \
--cc=jakobkoschel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=torvalds@linux-foundation.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 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.