public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Richard Leitner <richard.leitner@skidata.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, robh+dt@kernel.org,
	mark.rutland@arm.com, dev@g0hl1n.net
Subject: Re: [PATCH v2] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver
Date: Mon, 6 Feb 2017 12:55:52 +0100	[thread overview]
Message-ID: <20170206115552.GA31808@kroah.com> (raw)
In-Reply-To: <686ee231-57b2-036f-f97a-dad508e94e39@skidata.com>

On Mon, Feb 06, 2017 at 12:19:40PM +0100, Richard Leitner wrote:
> On 02/05/2017 08:42 AM, Greg KH wrote:
> > On Fri, Feb 03, 2017 at 11:55:24AM +0100, Richard Leitner wrote:
> >> +/**
> >> + * ascii2utf16le() - Helper routine for producing UTF-16LE string descriptors
> >> + * @s: Null-terminated ASCII (actually ISO-8859-1) string
> >> + * @buf: Buffer for UTF-16LE string
> >> + * @len: Length (in bytes; may be odd) of UTF-16LE buffer.
> >> + *
> >> + * Return: The number of bytes filled in: 2*strlen(s) or @len, whichever is less
> >> + *
> >> + * Note:
> >> + * The UTF-16LE USB String descriptors can contain at most 31 characters (as
> >> + * specified in the datasheet); input strings longer than that are truncated.
> >> + *
> >> + * Based on ascii2desc from drivers/usb/core/hcd.c
> >> + */
> > 
> > Don't we have a kernel function for this already?  If we need to export
> > ascii2desc() from the USB core, we can do that, or better yet, move both
> > of them to a string library function in the core part of the kernel.  We
> > shouldn't have to duplicate this type of thin in an individual driver.
> 
> Ok. So I'll move the ascii2utf16le function to lib/string.c (?) and call
> it from ascii2desc in drivers/usb/core/hcd.c (due to the fact ascii2desc
> also prepends 2 bytes) and the USB251xB driver? Would that be OK?

That sounds good to me.

> >> --- /dev/null
> >> +++ b/include/linux/platform_data/usb251xb.h
> >> @@ -0,0 +1,33 @@
> > 
> > Do you need a platform data structure here?  Shouldn't we be only using
> > DT now?
> 
> I don't need the platform data support at all. I just added it because
> it is also available in the USB3503 driver. So if it's OK for you I'd be
> glad to remove it.

Great, please remove it! :)

thanks,

greg k-h

      reply	other threads:[~2017-02-06 11:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03 10:55 [PATCH v2] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver Richard Leitner
2017-02-05  7:42 ` Greg KH
2017-02-06 11:19   ` Richard Leitner
2017-02-06 11:55     ` Greg KH [this message]

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=20170206115552.GA31808@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=dev@g0hl1n.net \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=richard.leitner@skidata.com \
    --cc=robh+dt@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