Re: [GIT PULL] USB-serial fix for v4.20-rc6

2018-12-06 Thread Greg Kroah-Hartman
On Thu, Dec 06, 2018 at 05:33:46PM +0100, Johan Hovold wrote:
> The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
> 
>   Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.20-rc6
> 
> for you to fetch changes up to f51ccf46217c28758b1f3b5bc0ccfc00eca658b2:
> 
>   USB: serial: console: fix reported terminal settings (2018-12-05 11:29:10 
> +0100)
> 
> 
> USB-serial fix for v4.20-rc6
> 
> Here's a fix for a reported USB-console regression in 4.18 which
> revealed a long-standing bug in the console implementation.
> 
> The patch has been in linux-next over night with no reported issues.
> 
> Signed-off-by: Johan Hovold 

Pulled and pushed out, thanks.

greg k-h


Re: [PATCH 0/3] Small improvements to the appledisplay driver

2018-12-05 Thread Greg Kroah-Hartman
On Tue, Dec 04, 2018 at 11:43:34PM +0100, alex.theis...@me.com wrote:
> With the exception of the first patch I am not entirely sure if my changes are
> correct and justified. This is my first contribution and I am equally 
> satisfied
> if someone could point out why my changes are not correct.
> 
> The added display is my own and works well with the driver.

All looks good to me, thanks for the patches!

greg k-h


Re: [PATCH v2 1/3] staging: typec: fusb302: Rename fcs,extcon-name to linux,extcon-name

2018-12-05 Thread Greg Kroah-Hartman
On Mon, Dec 03, 2018 at 09:23:44PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 15, 2018 at 04:53:03PM +0200, Heikki Krogerus wrote:
> > On Thu, Nov 15, 2018 at 03:16:19PM +0200, Andy Shevchenko wrote:
> > > Since we are going to use the same in Designware USB 3 driver,
> > > rename the property to be consistent across the drivers.
> > > 
> > > No functional change intended.
> > > 
> > > Signed-off-by: Andy Shevchenko 
> > > Cc: Hans de Goede 
> > > Cc: Guenter Roeck 
> > > Acked-by: Hans de Goede 
> > > Acked-by: Guenter Roeck 
> > 
> > FWIW, the series:
> > Reviewed-by: Heikki Krogerus 
> 
> Greg, can you pick up this patch (first in the series, since dwc3 went 
> through Felipe's tree)?

Sorry for the delay, now queued up.

greg k-h


Re: [GIT PULL] USB fixes for v4.20-rc4

2018-11-29 Thread Greg Kroah-Hartman
On Thu, Nov 29, 2018 at 12:26:29PM +0200, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's my second pull request for the current -rc cycle. Looks like
> things are really calm this merge window.
> 
> Let me know if you want anything to be changed.
> 
> cheers
> 
> The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436:
> 
>   Linux 4.20-rc4 (2018-11-25 14:19:31 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.20-rc4

Pulled and pushed out, thanks.

greg k-h


Re: [GIT PULL] usb fixes for v4.20-rc2

2018-11-14 Thread Greg Kroah-Hartman
On Wed, Nov 14, 2018 at 01:33:10PM +0200, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's the first set of fixes for v4.20-rc cycle. Nothing really major,
> actually.
> 
> Let me now if you want anything to be changed

Now pulled, thanks.

greg k-h


Re: [PATCH] usb: dwc3: debugfs: Dump internal states

2018-11-07 Thread Greg Kroah-Hartman
On Wed, Nov 07, 2018 at 12:45:50PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Greg Kroah-Hartman  writes:
> >> Thinh Nguyen  writes:
> >> >>>>> +static ssize_t dwc3_internal_states_write(struct file *file,
> >> >>>>> +const char __user *ubuf, size_t count, loff_t *ppos)
> >> >>>> why is this necessary? Seems like it would be nicer to create a
> >> >>>> directory structure if the current operating mode is host so that we
> >> >>>> don't need to write anything.
> >> >>> Can you clarify more about the directory structure? Actually, I was
> >> >>> wondering what's the best way to do this also. The reason I want to
> >> >>> write to it is because the LSP selection for host is quite large 
> >> >>> (2^14).
> >> >> right, turn each of those into a directory of its own. If you don't want
> >> >> to or can't disclose proper names for those directories, just call them
> >> >> lsp0, lsp1, lsp2, and so on. Then a read of the file under lsp1
> >> >> directory would write and read the correct registers.
> >> >>
> >> >> Everything remains read-only.
> >> >
> >> > This means that there will be 16384 + 256 files create for host. It also
> >> > means that we need to kmalloc at least (16384 + 256) * (size of each
> >> > selection) so that each file knows what to print. On top of that, when
> >> > we change mode of operation (e.g. device->host), then we need to
> >> > create/destroy all these files. Is this the way to do it?
> >> 
> >> Hmm... indeed that's a lot. But since this is used only for debugging I
> >> wonder if we should care. Greg, Alan, what do you guys think? Do we
> >> create 16k files under debugfs or single file that needs to be written
> >> to before being read?
> >
> > 16k files under debugfs is crazy, don't do that :)
> 
> one file with write followed by read it is then :-p
> 
> > What type of interface would ever want such a thing?  I have not been
> > paying attention, but what is the end goal here?  What do you want to
> > expose in debugfs that is actually going to be useful?
> 
> internal debug information from dwc3's list processor (the HW
> itself). It's only useful for synopsys, really, as the content of such
> registers lacks documentation about how to decode it.

Ok, one file with crazy semantics is fine, remember the only "rule" for
debugfs is "there are no rules" :)

And of course, the normal operation of the driver should never require
debugfs to be present or even working.

thanks,

greg k-h


Re: [PATCH] usb: dwc3: debugfs: Dump internal states

2018-11-07 Thread Greg Kroah-Hartman
On Wed, Nov 07, 2018 at 08:39:41AM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Thinh Nguyen  writes:
> > +static ssize_t dwc3_internal_states_write(struct file *file,
> > +   const char __user *ubuf, size_t count, loff_t *ppos)
>  why is this necessary? Seems like it would be nicer to create a
>  directory structure if the current operating mode is host so that we
>  don't need to write anything.
> >>> Can you clarify more about the directory structure? Actually, I was
> >>> wondering what's the best way to do this also. The reason I want to
> >>> write to it is because the LSP selection for host is quite large (2^14).
> >> right, turn each of those into a directory of its own. If you don't want
> >> to or can't disclose proper names for those directories, just call them
> >> lsp0, lsp1, lsp2, and so on. Then a read of the file under lsp1
> >> directory would write and read the correct registers.
> >>
> >> Everything remains read-only.
> >
> > This means that there will be 16384 + 256 files create for host. It also
> > means that we need to kmalloc at least (16384 + 256) * (size of each
> > selection) so that each file knows what to print. On top of that, when
> > we change mode of operation (e.g. device->host), then we need to
> > create/destroy all these files. Is this the way to do it?
> 
> Hmm... indeed that's a lot. But since this is used only for debugging I
> wonder if we should care. Greg, Alan, what do you guys think? Do we
> create 16k files under debugfs or single file that needs to be written
> to before being read?

16k files under debugfs is crazy, don't do that :)

What type of interface would ever want such a thing?  I have not been
paying attention, but what is the end goal here?  What do you want to
expose in debugfs that is actually going to be useful?

thanks,

greg k-h


Re: [GIT PULL] USB-serial updates for v4.20-rc1

2018-10-18 Thread Greg Kroah-Hartman
On Thu, Oct 18, 2018 at 12:55:42PM +0200, Johan Hovold wrote:
> The following changes since commit 7876320f88802b22d4e2daf7eb027dd14175a0f8:
> 
>   Linux 4.19-rc4 (2018-09-16 11:52:37 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.20-rc1
> 
> for you to fetch changes up to 17c42e34997ae172c794f84fefe47f00bec13f9a:
> 
>   USB: serial: cypress_m8: remove set but not used variable 'iflag' 
> (2018-10-05 08:58:42 +0200)

Now merged, thanks

greg k-h


Re: [GIT PULL] usb: chipidea: changes for v4.20-rc1

2018-10-08 Thread Greg Kroah-Hartman
On Mon, Oct 08, 2018 at 01:58:00AM +, Peter Chen wrote:
> The following changes since commit 1652a83fa494b12e20fc02a2cc3ddbcd75d53170:
> 
>   Merge 4.19-rc4 into usb-next (2018-09-16 22:44:14 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.20-rc1

Now merged, thanks.

greg k-h


Re: [GIT PULL] USB for v4.20 merge window

2018-10-05 Thread Greg Kroah-Hartman
On Fri, Oct 05, 2018 at 11:07:31AM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> Here's my pull request for v4.20 merge window. Most of the changes are
> on the UVC gadget driver. Seems like we'll have a calm merge window for
> USB folks this time around.

Now pulled and pushed out, thanks.

greg k-h


Re: [GIT PULL] USB-serial fixes for v4.19-rc7

2018-10-01 Thread Greg Kroah-Hartman
On Sun, Sep 30, 2018 at 06:27:17PM +0200, Johan Hovold wrote:
> Hi Greg,
> 
> Here are some device-id patches for 4.19-rc7 (unless you prefer to hold them
> off for 4.20).
> 
> The option patches are a bit more intrusive than the usual device-id patches,
> but allows us to support a particular Quectel modem in non-standard
> configurations. To simplify dealing with stable-backports these also carry a
> stable tag.

Now pulled, thanks.

greg k-h


Re: fixes for ioctl() of usbtmc in testing tree

2018-09-28 Thread Greg Kroah-Hartman
On Fri, Sep 28, 2018 at 08:30:41AM +, gu...@kiener-muenchen.de wrote:
> 
> Zitat von Greg Kroah-Hartman :
> 
> > On Mon, Sep 24, 2018 at 12:20:42PM +, gu...@kiener-muenchen.de wrote:
> > > 
> > > Zitat von Oliver Neukum :
> > > 
> > > > On Mo, 2018-09-24 at 10:56 +, gu...@kiener-muenchen.de wrote:
> > > > > Zitat von Greg Kroah-Hartman :
> > > > >
> > > > > > On Mon, Sep 24, 2018 at 11:24:10AM +0200, Oliver Neukum wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > how should I mark fixes intended for the testing branch?
> > > > > > > I got one for the usbtmc driver.
> > > > > >
> > > > > > Just send it like normal.  You can do a "Fixes:" tag with the
> > > sha1, that
> > > > > > should be fine.  I need to push out my testing branch now, 0-day 
> > > > > > seems
> > > > > > to be stalled :(
> > > > > >
> > > > >
> > > > > Big sorry! There is a superflous kmalloc line 1270 til 1272.
> > > > > Shall I send the fix?
> > > >
> > > > Damn. That is the same allocation repeated, not a reuse of the buffer.
> > > > I'll resend. There is also a leak in the error case.
> > > >
> > > 
> > > I do not see a leak in the error case. kfree(NULL) should be ok.
> > > Sorry, I referred the line 1270 to the mail of Dan Carpenter. I mean the
> > > lines:
> > > 
> > > diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> > > index 0fcb81a1399b..dfbcf418dad7 100644
> > > --- a/drivers/usb/class/usbtmc.c
> > > +++ b/drivers/usb/class/usbtmc.c
> > > @@ -1895,10 +1895,6 @@ static int usbtmc_ioctl_request(struct
> > > usbtmc_device_data *data,
> > > if (res)
> > > return -EFAULT;
> > > 
> > > -   buffer = kmalloc(request.req.wLength, GFP_KERNEL);
> > > -   if (!buffer)
> > > -   return -ENOMEM;
> > > -
> > > if (request.req.wLength > USBTMC_BUFSIZE)
> > > return -EMSGSIZE;
> > > 
> > > @Oliver: Where do send (resend) the fix? Is this an official fix or
> > > do you just fix your internal build system?
> > > And I still have to make an official fix, isn't it?
> > 
> > Yes, you need to send a "real" patch for anyone to be able to pick it
> > up.
> 
> I sent the patch series: https://patchwork.kernel.org/cover/10612963/
> Anything else I can do to relieve my bad conscience?

All now queued up, thanks.

greg k-h


Re: [PATCH -next] USB: core: remove set but not used variable 'udev'

2018-09-28 Thread Greg Kroah-Hartman
On Sat, Sep 22, 2018 at 06:31:26AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/usb/core/driver.c: In function 'usb_driver_claim_interface':
> drivers/usb/core/driver.c:513:21: warning:
>  variable 'udev' set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: YueHaibing 
> Acked-by: Alan Stern 
> ---
>  drivers/usb/core/driver.c | 3 ---
>  1 file changed, 3 deletions(-)

This patch breaks the build, which is not ok :(


Re: fixes for ioctl() of usbtmc in testing tree

2018-09-24 Thread Greg Kroah-Hartman
On Mon, Sep 24, 2018 at 12:20:42PM +, gu...@kiener-muenchen.de wrote:
> 
> Zitat von Oliver Neukum :
> 
> > On Mo, 2018-09-24 at 10:56 +, gu...@kiener-muenchen.de wrote:
> > > Zitat von Greg Kroah-Hartman :
> > > 
> > > > On Mon, Sep 24, 2018 at 11:24:10AM +0200, Oliver Neukum wrote:
> > > > > Hi,
> > > > >
> > > > > how should I mark fixes intended for the testing branch?
> > > > > I got one for the usbtmc driver.
> > > >
> > > > Just send it like normal.  You can do a "Fixes:" tag with the sha1, that
> > > > should be fine.  I need to push out my testing branch now, 0-day seems
> > > > to be stalled :(
> > > >
> > > 
> > > Big sorry! There is a superflous kmalloc line 1270 til 1272.
> > > Shall I send the fix?
> > 
> > Damn. That is the same allocation repeated, not a reuse of the buffer.
> > I'll resend. There is also a leak in the error case.
> > 
> 
> I do not see a leak in the error case. kfree(NULL) should be ok.
> Sorry, I referred the line 1270 to the mail of Dan Carpenter. I mean the
> lines:
> 
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index 0fcb81a1399b..dfbcf418dad7 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -1895,10 +1895,6 @@ static int usbtmc_ioctl_request(struct
> usbtmc_device_data *data,
> if (res)
> return -EFAULT;
> 
> -   buffer = kmalloc(request.req.wLength, GFP_KERNEL);
> -   if (!buffer)
> -   return -ENOMEM;
> -
> if (request.req.wLength > USBTMC_BUFSIZE)
> return -EMSGSIZE;
> 
> @Oliver: Where do send (resend) the fix? Is this an official fix or
> do you just fix your internal build system?
> And I still have to make an official fix, isn't it?

Yes, you need to send a "real" patch for anyone to be able to pick it
up.

thanks,

greg k-h


Re: fixes for ioctl() of usbtmc in testing tree

2018-09-24 Thread Greg Kroah-Hartman
On Mon, Sep 24, 2018 at 11:24:10AM +0200, Oliver Neukum wrote:
> Hi,
> 
> how should I mark fixes intended for the testing branch?
> I got one for the usbtmc driver.

Just send it like normal.  You can do a "Fixes:" tag with the sha1, that
should be fine.  I need to push out my testing branch now, 0-day seems
to be stalled :(

thanks,

greg k-h


Re: [PATCH v4 00/10] usb: typec: A few more improvements for Intel CHT

2018-09-20 Thread Greg Kroah-Hartman
On Wed, Sep 12, 2018 at 11:00:55AM +0300, Heikki Krogerus wrote:
> Hi,
> 
> On Tue, Sep 11, 2018 at 07:36:34PM +0200, Hans de Goede wrote:
> > On 11-09-18 12:10, Heikki Krogerus wrote:
> > > This is fourth version of this series. There was one bug in patch 2/10
> > > that Hans noticed. It should be fixed now.
> > > 
> > > The commit message from v3:
> > > 
> > > These patches will introduce a few improvements to the USB Type-C
> > > support on Intel CHT platform. In this series I'm preparing Intel CHT
> > > mux handling for DisplayPort Alt Mode support, but please note that,
> > > after these patches the DisplayPort alternate mode will still not work
> > > out of the box on CHT platform. Changes to the fusb302.c, and possibly
> > > tcpm.c are still needed.
> > > 
> > > This version will only fix the issue Hans pointed out in v2. Instead
> > > of replacing the connection that assigned the mux to the USB Type-C
> > > port with a connection that assigns the mux to the alternate mode
> > > device, we keep all the existing connections and add a new one for the
> > > alternate mode device. That way USB3 devices continue to be enumerated
> > > as USB3 devices instead of USB2 devices.
> > > 
> > > The origin thread can be read here:
> > > https://www.spinics.net/lists/linux-usb/msg172033.html
> > 
> > Thanks, the entire series looks good to me and has been tested by
> > me on a GPD win with a fusb302 tcpm controller:
> > 
> > Acked-by: Hans de Goede 
> > Tested-by: Hans de Goede 
> > 
> > Greg, the previous version of this series also was:
> > 
> > "
> > Acked-by: Andy Shevchenko 
> > 
> > for PDx86 bits on condition that Hans is fine with them.
> > "
> > 
> > With the intend that the entire series would be merged
> > through the USB tree with Andy's ack for the
> > "platform: x86: ..." patches.
> 
> Thanks Hans!
> 
> I've now applied these to my tree:
> https://github.com/krohei/linux/commits/typec-next
> 
> I will resend them together with the other Type-C patches I've
> collected next week after v4.19-rc4 unless Greg takes the patches
> himself before that. The idea is to take care of a conflict for Greg.

That would be great if you could do that.

thanks,

greg k-h


Re: [PATCHv2] usb: typec: Group all TCPCI/TCPM code together

2018-09-20 Thread Greg Kroah-Hartman
On Tue, Sep 11, 2018 at 05:51:36PM +0300, Heikki Krogerus wrote:
> On Mon, Sep 10, 2018 at 06:21:04AM -0700, Guenter Roeck wrote:
> > On 09/10/2018 04:58 AM, Heikki Krogerus wrote:
> > > Moving all the drivers that depend on the Port Controller
> > > Manager under a new directory drivers/usb/typec/tcpm/ and
> > > making Guenter Roeck the designated reviewer of that code.
> > > 
> > > Signed-off-by: Heikki Krogerus 
> > 
> > Acked-by: Guenter Roeck 
> 
> Thanks!
> 
> To avoid the little conflict this patch will cause, I'll resend it
> together with the other Type-C patches I've collected next week to
> Greg (assuming he does not pick them himself before that).
> 
> I have all the patches here:
> https://github.com/krohei/linux/commits/typec-next

Yes, please send all of the patches in the correct order as I am
confused as to what needs to be applied where at the moment.

thanks,

greg k-h


Re: [GIT PULL] USB: fixes for v4.19-rc2

2018-09-06 Thread Greg Kroah-Hartman
On Thu, Sep 06, 2018 at 11:07:57AM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's my first pull request for the current -rc cycle. Not much has
> been going on when it comes to fixes. Hopefully we won't have a lot of
> late fixes.
> 
> Let me know if you want anything to be changed.

Looks good, now pulled and pushed out, thanks.

greg k-h


Re: [GIT PULL] USB-serial fixes for v4.19-rc3

2018-09-05 Thread Greg Kroah-Hartman
On Wed, Sep 05, 2018 at 04:02:23PM +0200, Johan Hovold wrote:
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> 
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.19-rc3

Now pulled and pushed out.

thanks,

greg k-h


Re: [PATCH 2/2] usb storage: remove inherited SCSI dependency for USB_STORAGE subentries

2018-08-09 Thread Greg Kroah-Hartman
On Thu, Aug 09, 2018 at 09:38:40AM +0200, Oliver Neukum wrote:
> On Do, 2018-08-09 at 01:01 +0300, Vladimir Zapolskiy wrote:
> > Because USB_STORAGE build symbol strictly depends on SCSI build
> > symbol, there is no need to specify it again for USB_UAS and
> > USB_STORAGE_ENE_UB6250 build options.
> 
> [..]
> 
> >  config USB_UAS
> > tristate "USB Attached SCSI"
> > -   depends on SCSI
> > help
> >   The USB Attached SCSI protocol is supported by some USB
> >   storage devices.  It permits higher performance by supporting
> 
> Hi,
> 
> I am sorry, but this is wrong. You can build and use UAS without
> old style storage support. I do not recommend that you do so,
> but in theory it is possible.
> And UAS very much depends on storage.

But today UAS depends on SCSI and USB_STORAGE, so if this is true, it's
not very obvious :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] usb storage: group dependent USB storage Kconfig entries together

2018-08-09 Thread Greg Kroah-Hartman
On Thu, Aug 09, 2018 at 01:01:54AM +0300, Vladimir Zapolskiy wrote:
> Instead of explicit setting of USB_STORAGE dependency for every
> underlying build entries, exploit if USB_STORAGE / endif block.

Why change this?  What benifit does this provide?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: ehci-sh: convert to SPDX identifiers

2018-08-02 Thread Greg Kroah-Hartman
On Thu, Aug 02, 2018 at 01:46:40AM +, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> Signed-off-by: Kuninori Morimoto 
> ---
>  include/linux/platform_data/ehci-sh.h | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)

I can not take patches without any changelog text at all, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB changes for v4.19

2018-07-30 Thread Greg Kroah-Hartman
On Mon, Jul 30, 2018 at 10:53:52AM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's my pull request for v4.19. It's not very large this time around
> with only 37 commits. Patches have been soaking for a while without any
> reported incidents.
> 
> Let me know if you want anything to be changed.
> 
> Cheers
> 
> The following changes since commit d72e90f33aa4709ebecc5005562f52335e106a60:
> 
>   Linux 4.18-rc6 (2018-07-22 14:12:20 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.19

Now pulled in, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB-serial updates for v4.19-rc1

2018-07-20 Thread Greg Kroah-Hartman
On Fri, Jul 20, 2018 at 06:56:11PM +0200, Johan Hovold wrote:
> The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819:
> 
>   Linux 4.18-rc2 (2018-06-24 20:54:29 +0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.19-rc1

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: gadget: f_fs: Only return delayed status when len is 0

2018-07-20 Thread Greg Kroah-Hartman
On Thu, Jul 19, 2018 at 08:48:32AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Jerry Zhang  writes:
> > Commit 1b9ba000 ("Allow function drivers to pause control
> > transfers") states that USB_GADGET_DELAYED_STATUS is only
> > supported if data phase is 0 bytes.
> >
> > It seems that when the length is not 0 bytes, there is no
> > need to explicitly delay the data stage since the transfer
> > is not completed until the user responds. However, when the
> > length is 0, there is no data stage and the transfer is
> > finished once setup() returns, hence there is a need to
> > explicitly delay completion.
> >
> > This manifests as the following bugs:
> >
> > Prior to 946ef68ad4e4 ('Let setup() return
> > USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs
> > would require user to queue a 0 byte request in order to
> > clear setup state. However, that 0 byte request was actually
> > not needed and would hang and cause errors in other setup
> > requests.
> >
> > After the above commit, 0 byte setups work since the gadget
> > now accepts empty queues to ep0 to clear the delay, but all
> > other setups hang.
> >
> > Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS")
> > Signed-off-by: Jerry Zhang 
> 
> Greg, can you pick this one manually?
> 
> Acked-by: Felipe Balbi 

Yes, I'll pick it up, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 5/5] USB: serial: cp210x: improve line-speed handling for CP2104 and CP2105

2018-07-18 Thread Greg Kroah-Hartman
On Wed, Jul 18, 2018 at 02:25:01PM +0200, Johan Hovold wrote:
> CP2104 and the ECI interface of CP2105 support further baud rates than
> the ones specified in AN205 table 1, and we can use the same equations
> as for CP2102N to determine and report back the actual baud rates used.
> 
> Note that this could eventually be generalised also to CP2108, which
> uses a different base clock. There appears to be an error in the CP2108
> equations which needs to be confirmed on actual hardware first however
> (specifically, the subtraction of one from the divisor appears to be
> incorrect as it introduces larger errors).
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/cp210x.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/5] USB: serial: cp210x: improve baudrate support for CP2102N

2018-07-18 Thread Greg Kroah-Hartman
On Wed, Jul 18, 2018 at 02:24:59PM +0200, Johan Hovold wrote:
> From: Karoly Pados 
> 
> CP2102N devices support a lot more baudrates than earlier chips by
> SiLabs. These devices are not constrained anymore by the table in AN205,
> and are able to generate almost any baudrate in the supported range
> with only minimal errors. This has also been verified with a scope on
> a physical device. This patch adds support for all baudrates supported
> by the CP2102N.
> 
> Signed-off-by: Karoly Pados 
> [ johan: rework on top of an205 and max-speed patches ]
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/cp210x.c | 39 -
>  1 file changed, 34 insertions(+), 5 deletions(-)

Reviewed-by: Greg Kroah-Hartman 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/5] USB: serial: cp210x: generalise CP2102N line-speed handling

2018-07-18 Thread Greg Kroah-Hartman
On Wed, Jul 18, 2018 at 02:25:00PM +0200, Johan Hovold wrote:
> The CP2102N equations for determining the actual baud rate can be used
> also for other device types, so let's factor it out.
> 
> Note that this removes the now unused cp210x_is_cp2102n() helper.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/cp210x.c | 50 -
>  1 file changed, 27 insertions(+), 23 deletions(-)

Reviewed-by: Greg Kroah-Hartman 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] USB: serial: cp210x: honour device-type maximum line speed

2018-07-18 Thread Greg Kroah-Hartman
On Wed, Jul 18, 2018 at 02:24:58PM +0200, Johan Hovold wrote:
> Newer cp210x devices support higher line speeds than the older ones
> which supported a discrete set of speeds up to 921.6 kbaud.
> 
> To support these higher speeds, we have for some time mapped speeds
> lower than 1 Mbaud to the speeds supported by older devices, while
> allowing the device to pick the closest possible rate for higher speeds
> (without trying to guess and report back what rate was actually chosen).
> 
> As this implementation can lead to undefined behaviour for older devices
> which do not support the higher rates, let's use the later-added
> device-type detection to determine the maximum supported speed.
> 
> This will also be useful when adding support for cp2102n which can
> handle rates up to 3 Mbaud.
> 
> As per the data sheets the following maximum speeds are used
> 
>   cp2101  921.6 kbaud
>   cp2102/31 Mbaud
>   cp2104/82 Mbaud
>   cp2105
>- ECI port 2 Mbaud
>- SCI port 921.6 kbaud
> 
> while keeping the maximum 2 Mbaud for unknown device types in order to
> avoid any regressions.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/cp210x.c | 41 ++++++++++---
>  1 file changed, 38 insertions(+), 3 deletions(-)

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/5] USB: serial: cp210x: make line-speed quantisation data driven

2018-07-18 Thread Greg Kroah-Hartman
On Wed, Jul 18, 2018 at 02:24:57PM +0200, Johan Hovold wrote:
> Older cp210x devices only support a fixed set of line speeds to which a
> requested speed is mapped. Reimplement this mapping using a table
> instead of a long if-else construct.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/cp210x.c | 99 +
>  1 file changed, 56 insertions(+), 43 deletions(-)

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB fixes for v4.18-rc5

2018-07-17 Thread Greg Kroah-Hartman
On Tue, Jul 17, 2018 at 10:20:33AM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> after a couple weeks break, here's another pull request for the current
> rc. I've rebase on top of your usb-linus branch this time to make sure I
> don't pick any patches you have already picked.
> 
> Let me know if you want anything to be changed.
> 
> cheers
> 
> The following changes since commit 24dd9ba1c55f7e00352f4b8d7449fc0cbecb1f54:
> 
>   Merge tag 'phy-for-4.18-rc' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus 
> (2018-07-16 13:28:40 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.18-rc5

Looks good, now pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] usb: chipidea: fixes for usb-linus

2018-07-16 Thread Greg Kroah-Hartman
On Tue, Jul 10, 2018 at 06:21:35AM +, Peter Chen wrote:
> The following changes since commit 90f26cc6bb90b35040f4da0347f480ea9df6e2fc:
> 
>   usb: chipidea: host: fix disconnection detect issue (2018-06-26 09:59:34 
> +0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.18-rc4

Now pulled in, thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB-serial fixes for v4.18-rc4

2018-07-06 Thread Greg Kroah-Hartman
On Fri, Jul 06, 2018 at 02:01:34PM +0200, Johan Hovold wrote:
> The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:
> 
>   Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.18-rc4

Pulled and pushed out, thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] Documentation: usb: Add docs for configfs control requests

2018-07-03 Thread Greg Kroah-Hartman
On Mon, Jul 02, 2018 at 03:01:03PM -0700, Jerry Zhang wrote:
> Signed-off-by: Jerry Zhang 
> ---
>  Documentation/usb/gadget_configfs.txt | 34 +++
>  1 file changed, 34 insertions(+)

I can't take patches without any changelog text at all, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [usb:usb-next 36/38] drivers/usb/typec/tcpci.c:549: undefined reference to `__devm_regmap_init_i2c'

2018-07-02 Thread Greg Kroah-Hartman
On Fri, Jun 29, 2018 at 03:42:02PM -0700, Guenter Roeck wrote:
> On Fri, Jun 29, 2018 at 12:52:34PM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
> > usb-next
> > head:   aaf3f4e925dc2bdc4715142103660285632a245c
> > commit: 990da41530b31ed7de29340ce1d78c04bee9670c [36/38] staging: typec: 
> > tcpci: move tcpci drivers out of staging
> > config: x86_64-randconfig-a0-06290727 (attached as .config)
> > compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> > reproduce:
> > git checkout 990da41530b31ed7de29340ce1d78c04bee9670c
> > # save the attached .config to linux build tree
> > make ARCH=x86_64 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >drivers/usb/typec/tcpci.o: In function `tcpci_probe':
> > >> drivers/usb/typec/tcpci.c:549: undefined reference to 
> > >> `__devm_regmap_init_i2c'
> >drivers/usb/typec/tcpci.o: In function `tcpci_i2c_driver_init':
> > >> drivers/usb/typec/tcpci.c:609: undefined reference to 
> > >> `i2c_register_driver'
> >drivers/usb/typec/tcpci.o: In function `tcpci_i2c_driver_exit':
> > >> drivers/usb/typec/tcpci.c:609: undefined reference to `i2c_del_driver'
> >drivers/usb/typec/tcpci_rt1711h.o: In function `rt1711h_check_revision':
> > >> drivers/usb/typec/tcpci_rt1711h.c:218: undefined reference to 
> > >> `i2c_smbus_read_word_data'
> >drivers/usb/typec/tcpci_rt1711h.c:225: undefined reference to 
> > `i2c_smbus_read_word_data'
> >drivers/usb/typec/tcpci_rt1711h.o: In function `rt1711h_probe':
> > >> drivers/usb/typec/tcpci_rt1711h.c:251: undefined reference to 
> > >> `__devm_regmap_init_i2c'
> >drivers/usb/typec/tcpci_rt1711h.o: In function `rt1711h_i2c_driver_init':
> > >> drivers/usb/typec/tcpci_rt1711h.c:308: undefined reference to 
> > >> `i2c_register_driver'
> >drivers/usb/typec/tcpci_rt1711h.o: In function `rt1711h_i2c_driver_exit':
> > >> drivers/usb/typec/tcpci_rt1711h.c:308: undefined reference to 
> > >> `i2c_del_driver'
> > 
> 
> This is because CONFIG_I2C=m but CONFIG_TYPEC_TCPCI=y. I didn't know this
> was even possible given the dependencies. When I load the configuration
> into menuconfig and save it, or if I run "make olddefconfig", the problem
> disappears.
> 
> Puzzled. Greg, did you update the patch already ?

Nope, this might be due to the merge, it should be "all fixed" now, if
not, please let me know.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB-serial fixes for v4.18-rc3

2018-06-28 Thread Greg Kroah-Hartman
On Wed, Jun 27, 2018 at 01:43:53PM +0200, Johan Hovold wrote:
> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
> 
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.18-rc3

Pulled in but will take a while to hit kernel.org due to my lack of a
solid internet connection...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] USB: serial: digi_acceleport: rename tty flag variable

2018-06-26 Thread Greg Kroah-Hartman
On Tue, Jun 26, 2018 at 03:43:13PM +0200, Johan Hovold wrote:
> Add a "tty_" prefix to the tty "flag" variable to avoid any future
> mixups with the recently added irq-mask "flags" one.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] usb: chipidea: fixes for v4.18-rc

2018-06-25 Thread Greg Kroah-Hartman
On Tue, Jun 26, 2018 at 02:26:02AM +, Peter Chen wrote:
> The following changes since commit d5a4f93511b7000183c0d528739b824752139f79:
> 
>   usb: typec: tcpm: fix logbuffer index is wrong if _tcpm_log is re-entered 
> (2018-06-25 21:43:35 +0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.18-rc3

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] usb: typec: ucsi: Fix for incorrect status data issue

2018-06-25 Thread Greg Kroah-Hartman
On Mon, Jun 25, 2018 at 05:48:05PM +0300, Heikki Krogerus wrote:
> On Mon, Jun 25, 2018 at 08:37:25PM +0800, Greg Kroah-Hartman wrote:
> > On Thu, Jun 21, 2018 at 04:43:19PM +0300, Heikki Krogerus wrote:
> > > According to UCSI Specification, Connector Change Event only
> > > means a change in the Connector Status and Operation Mode
> > > fields of the STATUS data structure. So any other change
> > > should create another event.
> > > 
> > > Unfortunately on some platforms the firmware acting as PPM
> > > (platform policy manager - usually embedded controller
> > > firmware) still does not report any other status changes if
> > > there is a connector change event. So if the connector power
> > > or data role was changed when a device was plugged to the
> > > connector, the driver does not get any indication about
> > > that. The port will show wrong roles if that happens.
> > > 
> > > To fix the issue, always checking the data and power role
> > > together with a connector change event.
> > > 
> > > Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
> > > Signed-off-by: Heikki Krogerus 
> > > ---
> > 
> > No stable kernel marking for this? odd...
> 
> I forgot to put it there. Sorry.
> 
> I noticed you picked this patch already, but can I still resend it?

I already added that tag :)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB fixes for v4.18-rc1

2018-06-25 Thread Greg Kroah-Hartman
On Wed, Jun 20, 2018 at 02:14:57PM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's the first set of fixes for current -rc cycle. Patches have been
> soaking for a while and I've also tested on some of our platforms from
> the lab.
> 
> Let me know if you want anything to be changed.

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] usb: typec: ucsi: Fix for incorrect status data issue

2018-06-25 Thread Greg Kroah-Hartman
On Thu, Jun 21, 2018 at 04:43:19PM +0300, Heikki Krogerus wrote:
> According to UCSI Specification, Connector Change Event only
> means a change in the Connector Status and Operation Mode
> fields of the STATUS data structure. So any other change
> should create another event.
> 
> Unfortunately on some platforms the firmware acting as PPM
> (platform policy manager - usually embedded controller
> firmware) still does not report any other status changes if
> there is a connector change event. So if the connector power
> or data role was changed when a device was plugged to the
> connector, the driver does not get any indication about
> that. The port will show wrong roles if that happens.
> 
> To fix the issue, always checking the data and power role
> together with a connector change event.
> 
> Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
> Signed-off-by: Heikki Krogerus 
> ---

No stable kernel marking for this? odd...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH v4 1/8] usb: pd: include kernel.h

2018-06-11 Thread Greg Kroah-Hartman
On Fri, Jun 08, 2018 at 02:29:34PM +0300, Heikki Krogerus wrote:
> Some of the macros use le16_to_cpu().

What macros?

Is this causing build errors today?  If so, why should it not be
included now?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 02/22 v2] USB: typec: fsusb302: no need to check return value of debugfs_create_dir()

2018-05-31 Thread Greg Kroah-Hartman
On Thu, May 31, 2018 at 06:16:27AM -0700, Guenter Roeck wrote:
> On 05/31/2018 04:08 AM, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Clean up the fsusb302 driver to not care if the root directory was
> > created, as the code should work properly either way.
> > 
> > Cc: Heikki Krogerus 
> > Cc: Guenter Roeck 
> > Cc: Hans de Goede 
> > Cc: Andy Shevchenko 
> > Cc: Adam Thomson 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Reviewed-by: Guenter Roeck 

Thanks for the review.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/22 v2] USB: typec: fsusb302: no need to check return value of debugfs_create_dir()

2018-05-31 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Clean up the fsusb302 driver to not care if the root directory was
created, as the code should work properly either way.

Cc: Heikki Krogerus 
Cc: Guenter Roeck 
Cc: Hans de Goede 
Cc: Andy Shevchenko 
Cc: Adam Thomson 
Signed-off-by: Greg Kroah-Hartman 
---

v2: changes based on review from Guenter, we still need to keep
chip->dentry and the removal of the rootdir is properly reference
counted, making this patch a lot smaller.

 drivers/usb/typec/fusb302/fusb302.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 9c1eba9ea004..1e68da10bf17 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -215,20 +215,15 @@ DEFINE_SHOW_ATTRIBUTE(fusb302_debug);
 
 static struct dentry *rootdir;
 
-static int fusb302_debugfs_init(struct fusb302_chip *chip)
+static void fusb302_debugfs_init(struct fusb302_chip *chip)
 {
mutex_init(>logbuffer_lock);
-   if (!rootdir) {
+   if (!rootdir)
rootdir = debugfs_create_dir("fusb302", NULL);
-   if (!rootdir)
-   return -ENOMEM;
-   }
 
chip->dentry = debugfs_create_file(dev_name(chip->dev),
   S_IFREG | 0444, rootdir,
   chip, _debug_fops);
-
-   return 0;
 }
 
 static void fusb302_debugfs_exit(struct fusb302_chip *chip)
@@ -241,7 +236,7 @@ static void fusb302_debugfs_exit(struct fusb302_chip *chip)
 
 static void fusb302_log(const struct fusb302_chip *chip,
const char *fmt, ...) { }
-static int fusb302_debugfs_init(const struct fusb302_chip *chip) { return 0; }
+static void fusb302_debugfs_init(const struct fusb302_chip *chip) { }
 static void fusb302_debugfs_exit(const struct fusb302_chip *chip) { }
 
 #endif
@@ -1773,9 +1768,7 @@ static int fusb302_probe(struct i2c_client *client,
return -EPROBE_DEFER;
}
 
-   ret = fusb302_debugfs_init(chip);
-   if (ret < 0)
-   return ret;
+   fusb302_debugfs_init(chip);
 
chip->wq = create_singlethread_workqueue(dev_name(chip->dev));
if (!chip->wq) {
-- 
2.17.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 01/22] USB: typec: tcpm: no need to check return value of debugfs_create_dir()

2018-05-31 Thread Greg Kroah-Hartman
On Wed, May 30, 2018 at 06:42:49AM -0700, Guenter Roeck wrote:
> On 05/30/2018 03:36 AM, Greg Kroah-Hartman wrote:
> > On Wed, May 30, 2018 at 01:30:20PM +0300, Heikki Krogerus wrote:
> > > +Guenter
> > > 
> > > On Tue, May 29, 2018 at 05:30:46PM +0200, Greg Kroah-Hartman wrote:
> > > > When calling debugfs functions, there is no need to ever check the
> > > > return value.  The function can work or not, but the code logic should
> > > > never do something different based on this.
> > > > 
> > > > Clean up the tcpm.c code to not care about this, turns out no one was
> > > > even checking the return value of this function, so it didn't matter.
> > > > 
> > > > Note, I do not think this code can be removed in a running system, as
> > > > the debugfs root directory will stick around, that should be fixed
> > > > someday...
> > 
> > As Guenter pointed out to a different patch in this series, the code is
> > correct as-is, I read it wrong.  I'll delete this sentance from the
> > changelog when I apply it.
> > 
> Well, maybe I did not have enough coffee, but after looking into the code,
> I do think it is missing
>   debugfs_remove(rootdir);
> in the removal path. See commit c9359f416 in linux-next. You had tried
> to replace that with debugfs_remove_recursive() in the fusb302 driver.

Yes, I think you are correct.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 17/22] USB: udc: atmel_usba_udc: no need to check return value of debugfs_create functions

2018-05-31 Thread Greg Kroah-Hartman
On Wed, May 30, 2018 at 08:20:50PM +0200, Alexandre Belloni wrote:
> On 29/05/2018 17:31:02+0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > There is also no need to keep the file dentries around at all, so remove
> > those variables from the device structure.
> > 
> > Cc: Nicolas Ferre 
> > Cc: Felipe Balbi 
> > Cc: Alexandre Belloni 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Reviewed-by: Alexandre Belloni 

Thanks for reviewing this.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 13/22] USB: chipidea: no need to check return value of debugfs_create functions

2018-05-31 Thread Greg Kroah-Hartman
On Wed, May 30, 2018 at 01:58:18AM +, Peter Chen wrote:
>  
> > 
> > When calling debugfs functions, there is no need to ever check the return 
> > value.  The
> > function can work or not, but the code logic should never do something 
> > different
> > based on this.
> > 
> > Cc: Peter Chen 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Tested on imx6sx-sdb board.
> 
> Acked-by: Peter Chen 

Thanks for testing!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 21/22] USB: gadget: udc: renesas_usb3: no need to check return value of debugfs_create functions

2018-05-31 Thread Greg Kroah-Hartman
On Wed, May 30, 2018 at 07:38:24AM +, Yoshihiro Shimoda wrote:
> > From: Greg Kroah-Hartman, Sent: Wednesday, May 30, 2018 12:31 AM
> > 
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Cc: Felipe Balbi 
> > Cc: Yoshihiro Shimoda 
> > Cc: Simon Horman 
> > Cc: Geert Uytterhoeven 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> 
> I tested on r8a7795-salvator-xs. So,
> 
> Acked-by: Yoshihiro Shimoda 

Thanks for testing!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB-serial updates for v4.18-rc1

2018-05-31 Thread Greg Kroah-Hartman
On Thu, May 31, 2018 at 11:24:13AM +0200, Johan Hovold wrote:
> The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
> 
>   Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.18-rc1
> 
> for you to fetch changes up to 7041d9c3f01b365daa50340a5d2dce84a09ea813:
> 
>   USB: serial: pl2303: add support for tx xon/xoff flow control (2018-05-22 
> 10:08:05 +0200)

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 17/22] USB: udc: atmel_usba_udc: no need to check return value of debugfs_create functions

2018-05-30 Thread Greg Kroah-Hartman
On Wed, May 30, 2018 at 07:31:13PM +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 29/05/2018 17:31:02+0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > There is also no need to keep the file dentries around at all, so remove
> > those variables from the device structure.
> > 
> > Cc: Nicolas Ferre 
> > Cc: Felipe Balbi 
> > Cc: Alexandre Belloni 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  drivers/usb/gadget/udc/atmel_usba_udc.c | 71 -
> >  drivers/usb/gadget/udc/atmel_usba_udc.h |  4 --
> >  2 files changed, 11 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> > b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > index 2f586f2bda7e..a4d99bf50f2f 100644
> > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> > @@ -206,94 +206,45 @@ static void usba_ep_init_debugfs(struct usba_udc *udc,
> > struct dentry *ep_root;
> >  
> > ep_root = debugfs_create_dir(ep->ep.name, udc->debugfs_root);
> > -   if (!ep_root)
> > -   goto err_root;
> > ep->debugfs_dir = ep_root;
> >  
> > -   ep->debugfs_queue = debugfs_create_file("queue", 0400, ep_root,
> > -   ep, _dbg_fops);
> > -   if (!ep->debugfs_queue)
> > -   goto err_queue;
> > -
> > -   if (ep->can_dma) {
> > -   ep->debugfs_dma_status
> > -   = debugfs_create_u32("dma_status", 0400, ep_root,
> > -   >last_dma_status);
> > -   if (!ep->debugfs_dma_status)
> > -   goto err_dma_status;
> > -   }
> > -   if (ep_is_control(ep)) {
> > -   ep->debugfs_state
> > -   = debugfs_create_u32("state", 0400, ep_root,
> > -   >state);
> > -   if (!ep->debugfs_state)
> > -   goto err_state;
> > -   }
> > -
> > -   return;
> > -
> > -err_state:
> > +   debugfs_create_file("queue", 0400, ep_root, ep, _dbg_fops);
> 
> What happens here if debugfs_create_dir returned NULL? I guess the file
> will be placed at the root of the debugfs filesystem which is not great.

It doesn't really matter :)

The only way it can return NULL is if something really bad happens to
debugfs, and if that occurs, no one cares.  The function can only return
NULL if you pass a bad dentry into it, or if the directory is being
removed at that exact point in time.  Either of which are bigger issues
and then who cares what happens in debugfs.

No normal code should ever change its functionality based on if debugfs
is working or not.

> Should we stop caring about that and assume that if debugfs_create_dir,
> the following debugfs_create_* calls will fail?

Yes.  You should not care :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 01/22] USB: typec: tcpm: no need to check return value of debugfs_create_dir()

2018-05-30 Thread Greg Kroah-Hartman
On Wed, May 30, 2018 at 01:30:20PM +0300, Heikki Krogerus wrote:
> +Guenter
> 
> On Tue, May 29, 2018 at 05:30:46PM +0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Clean up the tcpm.c code to not care about this, turns out no one was
> > even checking the return value of this function, so it didn't matter.
> > 
> > Note, I do not think this code can be removed in a running system, as
> > the debugfs root directory will stick around, that should be fixed
> > someday...

As Guenter pointed out to a different patch in this series, the code is
correct as-is, I read it wrong.  I'll delete this sentance from the
changelog when I apply it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 05/22] USB: mon: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
On Tue, May 29, 2018 at 11:34:34AM -0500, Pete Zaitcev wrote:
> On Tue, 29 May 2018 17:30:50 +0200
> Greg Kroah-Hartman  wrote:
> 
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> 
> Okay, fair enough. And the code works, surprisingly, even when the
> debugfs is disabled (well, according to my review). I just have one
> question - wouldn't it be cleaner to deprecate and remove the text
> API altogether?

If you think we can do that, sure!  But what's the odds that someone
still uses it?  This patch doesn't change any real functionality.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 02/22] USB: typec: fsusb302: no need to check return value of debugfs_create_dir()

2018-05-29 Thread Greg Kroah-Hartman
On Tue, May 29, 2018 at 09:15:30AM -0700, Guenter Roeck wrote:
> On Tue, May 29, 2018 at 05:30:47PM +0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value.  The function can work or not, but the code logic should
> > never do something different based on this.
> > 
> > Clean up the fsusb302 driver to not care about the dentry being created,
> > or if the root directory was created, as the code should work properly
> > either way.  We do not need to save the dentry anymore as things are
> > properly cleaned up when we remove the root directory.
> > 
> > Note, this driver seems to only work for one device per system,
> > otherwise the debugfs directories are going to get confused when a
> > device is removed.
> > 
> > Cc: Heikki Krogerus 
> > Cc: Guenter Roeck 
> > Cc: Hans de Goede 
> > Cc: Andy Shevchenko 
> > Cc: Adam Thomson 
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  drivers/usb/typec/fusb302/fusb302.c | 24 +++-
> >  1 file changed, 7 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/usb/typec/fusb302/fusb302.c 
> > b/drivers/usb/typec/fusb302/fusb302.c
> > index 9c1eba9ea004..07b07ddf6af0 100644
> > --- a/drivers/usb/typec/fusb302/fusb302.c
> > +++ b/drivers/usb/typec/fusb302/fusb302.c
> > @@ -117,7 +117,6 @@ struct fusb302_chip {
> > u32 snk_pdo[PDO_MAX_OBJECTS];
> >  
> >  #ifdef CONFIG_DEBUG_FS
> > -   struct dentry *dentry;
> > /* lock for log buffer access */
> > struct mutex logbuffer_lock;
> > int logbuffer_head;
> > @@ -215,33 +214,26 @@ DEFINE_SHOW_ATTRIBUTE(fusb302_debug);
> >  
> >  static struct dentry *rootdir;
> >  
> > -static int fusb302_debugfs_init(struct fusb302_chip *chip)
> > +static void fusb302_debugfs_init(struct fusb302_chip *chip)
> >  {
> > mutex_init(>logbuffer_lock);
> > -   if (!rootdir) {
> > +   if (!rootdir)
> > rootdir = debugfs_create_dir("fusb302", NULL);
> > -   if (!rootdir)
> > -   return -ENOMEM;
> > -   }
> > -
> > -   chip->dentry = debugfs_create_file(dev_name(chip->dev),
> > -  S_IFREG | 0444, rootdir,
> > -  chip, _debug_fops);
> >  
> > -   return 0;
> > +   debugfs_create_file(dev_name(chip->dev), S_IFREG | 0444, rootdir, chip,
> > +   _debug_fops);
> >  }
> >  
> >  static void fusb302_debugfs_exit(struct fusb302_chip *chip)
> >  {
> > -   debugfs_remove(chip->dentry);
> > -   debugfs_remove(rootdir);
> > +   debugfs_remove_recursive(rootdir);
> 
> The idea was that debugfs_remove() would only remove the root directory
> if nothing else was in it. This was the reason for the preceding
> debugfs_remove(chip->dentry) followed by debugfs_remove(). Your patch
> changes this behavior. "... this driver seems to only work for one
> device per system" is introduced by your patch and was not previously
> the case.

Ah, that makes more sense.  Nice hack :)

Why not just have a new directory per device like "most" drivers have?
That would make this a bit simpler to manage.  Mind of I change the code
that way?  Hm, you still end up having to save off a dentry that way,
ah, it's the same either way...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 14/22] USB: core: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Johan Hovold 
Cc: Kai-Heng Feng 
Cc: Peter Chen 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/core/usb.c | 26 +-
 1 file changed, 5 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 0adb6345ff2e..623be3174fb3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -1167,30 +1167,16 @@ static struct notifier_block usb_bus_nb = {
 struct dentry *usb_debug_root;
 EXPORT_SYMBOL_GPL(usb_debug_root);
 
-static struct dentry *usb_debug_devices;
-
-static int usb_debugfs_init(void)
+static void usb_debugfs_init(void)
 {
usb_debug_root = debugfs_create_dir("usb", NULL);
-   if (!usb_debug_root)
-   return -ENOENT;
-
-   usb_debug_devices = debugfs_create_file("devices", 0444,
-   usb_debug_root, NULL,
-   _devices_fops);
-   if (!usb_debug_devices) {
-   debugfs_remove(usb_debug_root);
-   usb_debug_root = NULL;
-   return -ENOENT;
-   }
-
-   return 0;
+   debugfs_create_file("devices", 0444, usb_debug_root, NULL,
+   _devices_fops);
 }
 
 static void usb_debugfs_cleanup(void)
 {
-   debugfs_remove(usb_debug_devices);
-   debugfs_remove(usb_debug_root);
+   debugfs_remove_recursive(usb_debug_root);
 }
 
 /*
@@ -1205,9 +1191,7 @@ static int __init usb_init(void)
}
usb_init_pool_max();
 
-   retval = usb_debugfs_init();
-   if (retval)
-   goto out;
+   usb_debugfs_init();
 
usb_acpi_register();
retval = bus_register(_bus_type);
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 04/22] USB: mtu3: no need to check return value of debugfs_create_dir()

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Chunfeng Yun 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/mtu3/mtu3_dr.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index 8c3bbf732bc4..ac60e9c8564e 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -378,10 +378,6 @@ static void ssusb_debugfs_init(struct ssusb_mtk *ssusb)
struct dentry *root;
 
root = debugfs_create_dir(dev_name(ssusb->dev), usb_debug_root);
-   if (!root) {
-   dev_err(ssusb->dev, "create debugfs root failed\n");
-   return;
-   }
ssusb->dbgfs_root = root;
 
debugfs_create_file("mode", 0644, root, ssusb, _mode_fops);
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 11/22] USB: fhci-hcd: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

There is also no need to keep the file dentries around at all, so remove
those variables from the host controller structure.

Cc: Felipe Balbi 
Cc: Andy Shevchenko 
Cc: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/fhci-dbg.c | 23 +--
 drivers/usb/host/fhci.h |  2 --
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/host/fhci-dbg.c b/drivers/usb/host/fhci-dbg.c
index ebf9bb219f75..100048b3bd17 100644
--- a/drivers/usb/host/fhci-dbg.c
+++ b/drivers/usb/host/fhci-dbg.c
@@ -83,27 +83,14 @@ void fhci_dfs_create(struct fhci_hcd *fhci)
struct device *dev = fhci_to_hcd(fhci)->self.controller;
 
fhci->dfs_root = debugfs_create_dir(dev_name(dev), usb_debug_root);
-   if (!fhci->dfs_root) {
-   WARN_ON(1);
-   return;
-   }
-
-   fhci->dfs_regs = debugfs_create_file("regs", S_IFREG | S_IRUGO,
-   fhci->dfs_root, fhci, _dfs_regs_fops);
 
-   fhci->dfs_irq_stat = debugfs_create_file("irq_stat",
-   S_IFREG | S_IRUGO, fhci->dfs_root, fhci,
-   _dfs_irq_stat_fops);
-
-   WARN_ON(!fhci->dfs_regs || !fhci->dfs_irq_stat);
+   debugfs_create_file("regs", S_IFREG | S_IRUGO, fhci->dfs_root, fhci,
+   _dfs_regs_fops);
+   debugfs_create_file("irq_stat", S_IFREG | S_IRUGO, fhci->dfs_root, fhci,
+   _dfs_irq_stat_fops);
 }
 
 void fhci_dfs_destroy(struct fhci_hcd *fhci)
 {
-   if (!fhci->dfs_root)
-   return;
-
-   debugfs_remove(fhci->dfs_irq_stat);
-   debugfs_remove(fhci->dfs_regs);
-   debugfs_remove(fhci->dfs_root);
+   debugfs_remove_recursive(fhci->dfs_root);
 }
diff --git a/drivers/usb/host/fhci.h b/drivers/usb/host/fhci.h
index e7ec41d62410..2ce5031d866d 100644
--- a/drivers/usb/host/fhci.h
+++ b/drivers/usb/host/fhci.h
@@ -262,8 +262,6 @@ struct fhci_hcd {
 #ifdef CONFIG_FHCI_DEBUG
int usb_irq_stat[13];
struct dentry *dfs_root;
-   struct dentry *dfs_regs;
-   struct dentry *dfs_irq_stat;
 #endif
 };
 
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 13/22] USB: chipidea: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Peter Chen 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/chipidea/ci.h|  2 +-
 drivers/usb/chipidea/core.c  |  4 +--
 drivers/usb/chipidea/debug.c | 56 ++--
 3 files changed, 17 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 98b7cb3d0064..0bf244d50544 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -450,7 +450,7 @@ void hw_phymode_configure(struct ci_hdrc *ci);
 
 void ci_platform_configure(struct ci_hdrc *ci);
 
-int dbg_create_files(struct ci_hdrc *ci);
+void dbg_create_files(struct ci_hdrc *ci);
 
 void dbg_remove_files(struct ci_hdrc *ci);
 #endif /* __DRIVERS_USB_CHIPIDEA_CI_H */
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 33ae87fa3ff3..85fc6db48e44 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -1062,9 +1062,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci_hdrc_otg_fsm_start(ci);
 
device_set_wakeup_capable(>dev, true);
-   ret = dbg_create_files(ci);
-   if (ret)
-   goto stop;
+   dbg_create_files(ci);
 
ret = sysfs_create_group(>kobj, _attr_group);
if (ret)
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index ce648cb3ed94..fcc91a338875 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -340,54 +340,28 @@ DEFINE_SHOW_ATTRIBUTE(ci_registers);
  *
  * This function returns an error code
  */
-int dbg_create_files(struct ci_hdrc *ci)
+void dbg_create_files(struct ci_hdrc *ci)
 {
-   struct dentry *dent;
-
ci->debugfs = debugfs_create_dir(dev_name(ci->dev), NULL);
-   if (!ci->debugfs)
-   return -ENOMEM;
-
-   dent = debugfs_create_file("device", S_IRUGO, ci->debugfs, ci,
-  _device_fops);
-   if (!dent)
-   goto err;
-
-   dent = debugfs_create_file("port_test", S_IRUGO | S_IWUSR, ci->debugfs,
-  ci, _port_test_fops);
-   if (!dent)
-   goto err;
-
-   dent = debugfs_create_file("qheads", S_IRUGO, ci->debugfs, ci,
-  _qheads_fops);
-   if (!dent)
-   goto err;
 
-   dent = debugfs_create_file("requests", S_IRUGO, ci->debugfs, ci,
-  _requests_fops);
-   if (!dent)
-   goto err;
+   debugfs_create_file("device", S_IRUGO, ci->debugfs, ci,
+   _device_fops);
+   debugfs_create_file("port_test", S_IRUGO | S_IWUSR, ci->debugfs, ci,
+   _port_test_fops);
+   debugfs_create_file("qheads", S_IRUGO, ci->debugfs, ci,
+   _qheads_fops);
+   debugfs_create_file("requests", S_IRUGO, ci->debugfs, ci,
+   _requests_fops);
 
if (ci_otg_is_fsm_mode(ci)) {
-   dent = debugfs_create_file("otg", S_IRUGO, ci->debugfs, ci,
-   _otg_fops);
-   if (!dent)
-   goto err;
+   debugfs_create_file("otg", S_IRUGO, ci->debugfs, ci,
+   _otg_fops);
}
 
-   dent = debugfs_create_file("role", S_IRUGO | S_IWUSR, ci->debugfs, ci,
-  _role_fops);
-   if (!dent)
-   goto err;
-
-   dent = debugfs_create_file("registers", S_IRUGO, ci->debugfs, ci,
-   _registers_fops);
-
-   if (dent)
-   return 0;
-err:
-   debugfs_remove_recursive(ci->debugfs);
-   return -ENOMEM;
+   debugfs_create_file("role", S_IRUGO | S_IWUSR, ci->debugfs, ci,
+   _role_fops);
+   debugfs_create_file("registers", S_IRUGO, ci->debugfs, ci,
+   _registers_fops);
 }
 
 /**
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 16/22] USB: dwc3: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc3/debugfs.c | 43 ++
 1 file changed, 11 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 2f07be1e1f31..df8e73ec3342 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -716,9 +716,6 @@ static void dwc3_debugfs_create_endpoint_dir(struct dwc3_ep 
*dep,
struct dentry   *dir;
 
dir = debugfs_create_dir(dep->name, parent);
-   if (IS_ERR_OR_NULL(dir))
-   return;
-
dwc3_debugfs_create_endpoint_files(dep, dir);
 }
 
@@ -740,49 +737,31 @@ static void dwc3_debugfs_create_endpoint_dirs(struct dwc3 
*dwc,
 void dwc3_debugfs_init(struct dwc3 *dwc)
 {
struct dentry   *root;
-   struct dentry   *file;
-
-   root = debugfs_create_dir(dev_name(dwc->dev), NULL);
-   if (IS_ERR_OR_NULL(root)) {
-   if (!root)
-   dev_err(dwc->dev, "Can't create debugfs root\n");
-   return;
-   }
-   dwc->root = root;
 
dwc->regset = kzalloc(sizeof(*dwc->regset), GFP_KERNEL);
-   if (!dwc->regset) {
-   debugfs_remove_recursive(root);
+   if (!dwc->regset)
return;
-   }
 
dwc->regset->regs = dwc3_regs;
dwc->regset->nregs = ARRAY_SIZE(dwc3_regs);
dwc->regset->base = dwc->regs - DWC3_GLOBALS_REGS_START;
 
-   file = debugfs_create_regset32("regdump", S_IRUGO, root, dwc->regset);
-   if (!file)
-   dev_dbg(dwc->dev, "Can't create debugfs regdump\n");
+   root = debugfs_create_dir(dev_name(dwc->dev), NULL);
+   dwc->root = root;
+
+   debugfs_create_regset32("regdump", S_IRUGO, root, dwc->regset);
 
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
-   file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
-   dwc, _mode_fops);
-   if (!file)
-   dev_dbg(dwc->dev, "Can't create debugfs mode\n");
+   debugfs_create_file("mode", S_IRUGO | S_IWUSR, root, dwc,
+   _mode_fops);
}
 
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE) ||
IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
-   file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
-   dwc, _testmode_fops);
-   if (!file)
-   dev_dbg(dwc->dev, "Can't create debugfs testmode\n");
-
-   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
-   root, dwc, _link_state_fops);
-   if (!file)
-   dev_dbg(dwc->dev, "Can't create debugfs link_state\n");
-
+   debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root, dwc,
+   _testmode_fops);
+   debugfs_create_file("link_state", S_IRUGO | S_IWUSR, root, dwc,
+   _link_state_fops);
dwc3_debugfs_create_endpoint_dirs(dwc, root);
}
 }
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 18/22] USB: gadget: udc: bcm63xx_udc: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

There is also no need to keep the file dentries around at all, so remove
those variables from the device structure.

Cc: Kevin Cernekee 
Cc: Felipe Balbi 
Cc: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/gadget/udc/bcm63xx_udc.c | 37 
 1 file changed, 5 insertions(+), 32 deletions(-)

diff --git a/drivers/usb/gadget/udc/bcm63xx_udc.c 
b/drivers/usb/gadget/udc/bcm63xx_udc.c
index 3a8df8601074..c1fcc77403ea 100644
--- a/drivers/usb/gadget/udc/bcm63xx_udc.c
+++ b/drivers/usb/gadget/udc/bcm63xx_udc.c
@@ -288,8 +288,6 @@ struct bcm63xx_req {
  * @ep0_reply: Pending reply from gadget driver.
  * @ep0_request: Outstanding ep0 request.
  * @debugfs_root: debugfs directory: /sys/kernel/debug/.
- * @debugfs_usbd: debugfs file "usbd" for controller state.
- * @debugfs_iudma: debugfs file "usbd" for IUDMA state.
  */
 struct bcm63xx_udc {
spinlock_t  lock;
@@ -330,8 +328,6 @@ struct bcm63xx_udc {
struct usb_request  *ep0_request;
 
struct dentry   *debugfs_root;
-   struct dentry   *debugfs_usbd;
-   struct dentry   *debugfs_iudma;
 };
 
 static const struct usb_ep_ops bcm63xx_udc_ep_ops;
@@ -2247,34 +2243,16 @@ DEFINE_SHOW_ATTRIBUTE(bcm63xx_iudma_dbg);
  */
 static void bcm63xx_udc_init_debugfs(struct bcm63xx_udc *udc)
 {
-   struct dentry *root, *usbd, *iudma;
+   struct dentry *root;
 
if (!IS_ENABLED(CONFIG_USB_GADGET_DEBUG_FS))
return;
 
root = debugfs_create_dir(udc->gadget.name, NULL);
-   if (IS_ERR(root) || !root)
-   goto err_root;
-
-   usbd = debugfs_create_file("usbd", 0400, root, udc,
-   _usbd_dbg_fops);
-   if (!usbd)
-   goto err_usbd;
-   iudma = debugfs_create_file("iudma", 0400, root, udc,
-   _iudma_dbg_fops);
-   if (!iudma)
-   goto err_iudma;
-
udc->debugfs_root = root;
-   udc->debugfs_usbd = usbd;
-   udc->debugfs_iudma = iudma;
-   return;
-err_iudma:
-   debugfs_remove(usbd);
-err_usbd:
-   debugfs_remove(root);
-err_root:
-   dev_err(udc->dev, "debugfs is not available\n");
+
+   debugfs_create_file("usbd", 0400, root, udc, _usbd_dbg_fops);
+   debugfs_create_file("iudma", 0400, root, udc, _iudma_dbg_fops);
 }
 
 /**
@@ -2285,12 +2263,7 @@ static void bcm63xx_udc_init_debugfs(struct bcm63xx_udc 
*udc)
  */
 static void bcm63xx_udc_cleanup_debugfs(struct bcm63xx_udc *udc)
 {
-   debugfs_remove(udc->debugfs_iudma);
-   debugfs_remove(udc->debugfs_usbd);
-   debugfs_remove(udc->debugfs_root);
-   udc->debugfs_iudma = NULL;
-   udc->debugfs_usbd = NULL;
-   udc->debugfs_root = NULL;
+   debugfs_remove_recursive(udc->debugfs_root);
 }
 
 /***
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 07/22] USB: ohci: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

There is also no need to keep the file dentries around at all, so remove
those variables from the host controller structure.

Cc: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/ohci-dbg.c | 45 -
 drivers/usb/host/ohci-hcd.c |  5 -
 drivers/usb/host/ohci.h |  3 ---
 3 files changed, 9 insertions(+), 44 deletions(-)

diff --git a/drivers/usb/host/ohci-dbg.c b/drivers/usb/host/ohci-dbg.c
index ac7d4ac34b02..d3ee1f52aaab 100644
--- a/drivers/usb/host/ohci-dbg.c
+++ b/drivers/usb/host/ohci-dbg.c
@@ -762,50 +762,23 @@ static int debug_registers_open(struct inode *inode, 
struct file *file)
 static inline void create_debug_files (struct ohci_hcd *ohci)
 {
struct usb_bus *bus = _to_hcd(ohci)->self;
+   struct dentry *root;
 
-   ohci->debug_dir = debugfs_create_dir(bus->bus_name, ohci_debug_root);
-   if (!ohci->debug_dir)
-   goto dir_error;
+   root = debugfs_create_dir(bus->bus_name, ohci_debug_root);
+   ohci->debug_dir = root;
 
-   ohci->debug_async = debugfs_create_file("async", S_IRUGO,
-   ohci->debug_dir, ohci,
-   _async_fops);
-   if (!ohci->debug_async)
-   goto async_error;
-
-   ohci->debug_periodic = debugfs_create_file("periodic", S_IRUGO,
-  ohci->debug_dir, ohci,
-  _periodic_fops);
-   if (!ohci->debug_periodic)
-   goto periodic_error;
-
-   ohci->debug_registers = debugfs_create_file("registers", S_IRUGO,
-   ohci->debug_dir, ohci,
-   _registers_fops);
-   if (!ohci->debug_registers)
-   goto registers_error;
+   debugfs_create_file("async", S_IRUGO, root, ohci, _async_fops);
+   debugfs_create_file("periodic", S_IRUGO, root, ohci,
+   _periodic_fops);
+   debugfs_create_file("registers", S_IRUGO, root, ohci,
+   _registers_fops);
 
ohci_dbg (ohci, "created debug files\n");
-   return;
-
-registers_error:
-   debugfs_remove(ohci->debug_periodic);
-periodic_error:
-   debugfs_remove(ohci->debug_async);
-async_error:
-   debugfs_remove(ohci->debug_dir);
-dir_error:
-   ohci->debug_periodic = NULL;
-   ohci->debug_async = NULL;
-   ohci->debug_dir = NULL;
 }
 
 static inline void remove_debug_files (struct ohci_hcd *ohci)
 {
-   debugfs_remove(ohci->debug_registers);
-   debugfs_remove(ohci->debug_periodic);
-   debugfs_remove(ohci->debug_async);
-   debugfs_remove(ohci->debug_dir);
+   debugfs_remove_recursive(ohci->debug_dir);
 }
 
 /*-*/
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 4806e0f9e8d4..210181fd98d2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1258,10 +1258,6 @@ static int __init ohci_hcd_mod_init(void)
set_bit(USB_OHCI_LOADED, _hcds_loaded);
 
ohci_debug_root = debugfs_create_dir("ohci", usb_debug_root);
-   if (!ohci_debug_root) {
-   retval = -ENOENT;
-   goto error_debug;
-   }
 
 #ifdef PS3_SYSTEM_BUS_DRIVER
retval = ps3_ohci_driver_register(_SYSTEM_BUS_DRIVER);
@@ -1318,7 +1314,6 @@ static int __init ohci_hcd_mod_init(void)
 #endif
debugfs_remove(ohci_debug_root);
ohci_debug_root = NULL;
- error_debug:
 
clear_bit(USB_OHCI_LOADED, _hcds_loaded);
return retval;
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index 508a803139dd..ef4813bfc5bf 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -431,9 +431,6 @@ struct ohci_hcd {
struct work_struct  nec_work;   /* Worker for NEC quirk */
 
struct dentry   *debug_dir;
-   struct dentry   *debug_async;
-   struct dentry   *debug_periodic;
-   struct dentry   *debug_registers;
 
/* platform-specific data -- must come last */
unsigned long   priv[0] __aligned(sizeof(s64));
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 15/22] USB: dwc2: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Minas Harutyunyan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/debugfs.c | 78 --
 1 file changed, 16 insertions(+), 62 deletions(-)

diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c
index 7e6618ad9f21..d0bdb7997557 100644
--- a/drivers/usb/dwc2/debugfs.c
+++ b/drivers/usb/dwc2/debugfs.c
@@ -294,52 +294,30 @@ DEFINE_SHOW_ATTRIBUTE(ep);
 static void dwc2_hsotg_create_debug(struct dwc2_hsotg *hsotg)
 {
struct dentry *root;
-   struct dentry *file;
unsigned int epidx;
 
root = hsotg->debug_root;
 
/* create general state file */
-
-   file = debugfs_create_file("state", 0444, root, hsotg, _fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "%s: failed to create state\n", __func__);
-
-   file = debugfs_create_file("testmode", 0644, root, hsotg,
-  _fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "%s: failed to create testmode\n",
-   __func__);
-
-   file = debugfs_create_file("fifo", 0444, root, hsotg, _fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "%s: failed to create fifo\n", __func__);
+   debugfs_create_file("state", 0444, root, hsotg, _fops);
+   debugfs_create_file("testmode", 0644, root, hsotg, _fops);
+   debugfs_create_file("fifo", 0444, root, hsotg, _fops);
 
/* Create one file for each out endpoint */
for (epidx = 0; epidx < hsotg->num_of_eps; epidx++) {
struct dwc2_hsotg_ep *ep;
 
ep = hsotg->eps_out[epidx];
-   if (ep) {
-   file = debugfs_create_file(ep->name, 0444,
-  root, ep, _fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "failed to create %s debug 
file\n",
-   ep->name);
-   }
+   if (ep)
+   debugfs_create_file(ep->name, 0444, root, ep, _fops);
}
/* Create one file for each in endpoint. EP0 is handled with out eps */
for (epidx = 1; epidx < hsotg->num_of_eps; epidx++) {
struct dwc2_hsotg_ep *ep;
 
ep = hsotg->eps_in[epidx];
-   if (ep) {
-   file = debugfs_create_file(ep->name, 0444,
-  root, ep, _fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "failed to create %s debug 
file\n",
-   ep->name);
-   }
+   if (ep)
+   debugfs_create_file(ep->name, 0444, root, ep, _fops);
}
 }
 #else
@@ -792,32 +770,14 @@ DEFINE_SHOW_ATTRIBUTE(dr_mode);
 int dwc2_debugfs_init(struct dwc2_hsotg *hsotg)
 {
int ret;
-   struct dentry   *file;
+   struct dentry   *root;
 
-   hsotg->debug_root = debugfs_create_dir(dev_name(hsotg->dev), NULL);
-   if (!hsotg->debug_root) {
-   ret = -ENOMEM;
-   goto err0;
-   }
+   root = debugfs_create_dir(dev_name(hsotg->dev), NULL);
+   hsotg->debug_root = root;
 
-   file = debugfs_create_file("params", 0444,
-  hsotg->debug_root,
-  hsotg, _fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "%s: failed to create params\n", __func__);
-
-   file = debugfs_create_file("hw_params", 0444,
-  hsotg->debug_root,
-  hsotg, _params_fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "%s: failed to create hw_params\n",
-   __func__);
-
-   file = debugfs_create_file("dr_mode", 0444,
-  hsotg->debug_root,
-  hsotg, _mode_fops);
-   if (IS_ERR(file))
-   dev_err(hsotg->dev, "%s: failed to create dr_mode\n", __func__);
+   debugfs_create_file("params", 0444, root, hsotg, _fops);
+   debugfs_create_file("hw_params", 0444, root, hsotg, _params_fops);
+   debugfs_create_file("dr_mode", 0444, root, hsotg, _mode_fops);
 
/* Add gadget debugfs nodes */
dwc2_hsotg_create_debug(hsotg);
@@ -826,24 +786,18 @@ int dwc2_debugfs_init(struct dwc2_hsotg *hsotg)

[PATCH 22/22] USB: gadget: udc: s3c2410_udc: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Felipe Balbi 
Cc: Li Yang 
Cc: Nicolas Ferre 
Cc: Robert Jarzmik 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/gadget/udc/s3c2410_udc.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c 
b/drivers/usb/gadget/udc/s3c2410_udc.c
index f154f49e98c8..8bf5ad7a59ad 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -1871,13 +1871,9 @@ static int s3c2410_udc_probe(struct platform_device 
*pdev)
if (retval)
goto err_add_udc;
 
-   if (s3c2410_udc_debugfs_root) {
-   udc->regs_info = debugfs_create_file("registers", S_IRUGO,
-   s3c2410_udc_debugfs_root,
-   udc, _udc_debugfs_fops);
-   if (!udc->regs_info)
-   dev_warn(dev, "debugfs file creation failed\n");
-   }
+   udc->regs_info = debugfs_create_file("registers", S_IRUGO,
+s3c2410_udc_debugfs_root, udc,
+_udc_debugfs_fops);
 
dev_dbg(dev, "probe ok\n");
 
@@ -1994,11 +1990,6 @@ static int __init udc_init(void)
dprintk(DEBUG_NORMAL, "%s\n", gadget_name);
 
s3c2410_udc_debugfs_root = debugfs_create_dir(gadget_name, NULL);
-   if (IS_ERR(s3c2410_udc_debugfs_root)) {
-   pr_err("%s: debugfs dir creation failed %ld\n",
-   gadget_name, PTR_ERR(s3c2410_udc_debugfs_root));
-   s3c2410_udc_debugfs_root = NULL;
-   }
 
retval = platform_driver_register(_driver_24x0);
if (retval)
@@ -2014,7 +2005,7 @@ static int __init udc_init(void)
 static void __exit udc_exit(void)
 {
platform_driver_unregister(_driver_24x0);
-   debugfs_remove(s3c2410_udc_debugfs_root);
+   debugfs_remove_recursive(s3c2410_udc_debugfs_root);
 }
 
 module_init(udc_init);
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 19/22] USB: gadget: udc: gr_udc: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

There is also no need to keep the file dentries around at all, so remove
those variables from the device structure.

Cc: Felipe Balbi 
Cc: Andy Shevchenko 
Cc: "Paul E. McKenney" 
Cc: Mark Rutland 
Cc: Jaejoong Kim 
Cc: Li Yang 
Cc: Johan Hovold 
Cc: Robert Jarzmik 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/gadget/udc/gr_udc.c | 7 ++-
 drivers/usb/gadget/udc/gr_udc.h | 1 -
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index ca83c15d8ea4..729e60e49564 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -209,15 +209,12 @@ static void gr_dfs_create(struct gr_udc *dev)
const char *name = "gr_udc_state";
 
dev->dfs_root = debugfs_create_dir(dev_name(dev->dev), NULL);
-   dev->dfs_state = debugfs_create_file(name, 0444, dev->dfs_root, dev,
-_dfs_fops);
+   debugfs_create_file(name, 0444, dev->dfs_root, dev, _dfs_fops);
 }
 
 static void gr_dfs_delete(struct gr_udc *dev)
 {
-   /* Handles NULL and ERR pointers internally */
-   debugfs_remove(dev->dfs_state);
-   debugfs_remove(dev->dfs_root);
+   debugfs_remove_recursive(dev->dfs_root);
 }
 
 #else /* !CONFIG_USB_GADGET_DEBUG_FS */
diff --git a/drivers/usb/gadget/udc/gr_udc.h b/drivers/usb/gadget/udc/gr_udc.h
index 3e913268c8c5..417ad2aa2cc7 100644
--- a/drivers/usb/gadget/udc/gr_udc.h
+++ b/drivers/usb/gadget/udc/gr_udc.h
@@ -217,7 +217,6 @@ struct gr_udc {
spinlock_t lock; /* General lock, a.k.a. "dev->lock" in comments */
 
struct dentry *dfs_root;
-   struct dentry *dfs_state;
 };
 
 #define to_gr_udc(gadget)  (container_of((gadget), struct gr_udc, gadget))
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 03/22] USB: musb: clean up debugfs file and directory creation

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Because of this, lots of init functions do not need to have return
values, so this cleans up a lot of unused error handling code that never
could have triggered in the past.

Cc: Bin Liu 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/musb/musb_core.c|  5 +---
 drivers/usb/musb/musb_debug.h   |  5 ++--
 drivers/usb/musb/musb_debugfs.c | 44 ++---
 drivers/usb/musb/musb_dsps.c|  9 +--
 4 files changed, 11 insertions(+), 52 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 5cc64980058b..b7d56272f9d1 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2387,9 +2387,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
if (status < 0)
goto fail3;
 
-   status = musb_init_debugfs(musb);
-   if (status < 0)
-   goto fail4;
+   musb_init_debugfs(musb);
 
status = sysfs_create_group(>controller->kobj, _attr_group);
if (status)
@@ -2404,7 +2402,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 fail5:
musb_exit_debugfs(musb);
 
-fail4:
musb_gadget_cleanup(musb);
musb_host_cleanup(musb);
 
diff --git a/drivers/usb/musb/musb_debug.h b/drivers/usb/musb/musb_debug.h
index 5e0f079dde21..c444a80fe1da 100644
--- a/drivers/usb/musb/musb_debug.h
+++ b/drivers/usb/musb/musb_debug.h
@@ -20,12 +20,11 @@
 void musb_dbg(struct musb *musb, const char *fmt, ...);
 
 #ifdef CONFIG_DEBUG_FS
-int musb_init_debugfs(struct musb *musb);
+void musb_init_debugfs(struct musb *musb);
 void musb_exit_debugfs(struct musb *musb);
 #else
-static inline int musb_init_debugfs(struct musb *musb)
+static inline void musb_init_debugfs(struct musb *musb)
 {
-   return 0;
 }
 static inline void musb_exit_debugfs(struct musb *musb)
 {
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index e2050cac3eae..f42858e2b54c 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -321,48 +321,18 @@ static const struct file_operations musb_softconnect_fops 
= {
.release= single_release,
 };
 
-int musb_init_debugfs(struct musb *musb)
+void musb_init_debugfs(struct musb *musb)
 {
-   struct dentry   *root;
-   struct dentry   *file;
-   int ret;
+   struct dentry *root;
 
root = debugfs_create_dir(dev_name(musb->controller), NULL);
-   if (!root) {
-   ret = -ENOMEM;
-   goto err0;
-   }
-
-   file = debugfs_create_file("regdump", S_IRUGO, root, musb,
-   _regdump_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR,
-   root, musb, _test_mode_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   file = debugfs_create_file("softconnect", S_IRUGO | S_IWUSR,
-   root, musb, _softconnect_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
musb->debugfs_root = root;
 
-   return 0;
-
-err1:
-   debugfs_remove_recursive(root);
-
-err0:
-   return ret;
+   debugfs_create_file("regdump", S_IRUGO, root, musb, _regdump_fops);
+   debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root, musb,
+   _test_mode_fops);
+   debugfs_create_file("softconnect", S_IRUGO | S_IWUSR, root, musb,
+   _softconnect_fops);
 }
 
 void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index cfe6bfcbeb5d..fb871eabcc10 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -399,24 +399,17 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
 {
struct dentry *root;
-   struct dentry *file;
char buf[128];
 
sprintf(buf, "%s.dsps", dev_name(musb->controller));
root = debugfs_create_dir(buf, NULL);
-   if (!root)
-   return -ENOMEM;
glue->dbgfs_root = root;
 
glue->regset.regs = dsps_musb_regs;
glue->regset.nregs = ARRAY_SIZE(dsps_musb_regs);
glue->regset.base = musb->ctrl_base;
 
-   file = debugfs_create_regset32("regdump", S_IRUGO, root, >regset);
-   if (!file) {
-   debugfs_remove_recursive(root);
-   return -ENOMEM;
-   }
+

[PATCH 06/22] USB: uhci: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/uhci-hcd.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index f9c3947577fc..6218bfe54f52 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -590,14 +590,10 @@ static int uhci_start(struct usb_hcd *hcd)
init_waitqueue_head(>waitqh);
 
 #ifdef UHCI_DEBUG_OPS
-   dentry = debugfs_create_file(hcd->self.bus_name,
-   S_IFREG|S_IRUGO|S_IWUSR, uhci_debugfs_root,
-   uhci, _debug_operations);
-   if (!dentry) {
-   dev_err(uhci_dev(uhci), "couldn't create uhci debugfs entry\n");
-   return -ENOMEM;
-   }
-   uhci->dentry = dentry;
+   uhci->dentry = debugfs_create_file(hcd->self.bus_name,
+  S_IFREG|S_IRUGO|S_IWUSR,
+  uhci_debugfs_root, uhci,
+  _debug_operations);
 #endif
 
uhci->frame = dma_zalloc_coherent(uhci_dev(uhci),
@@ -882,8 +878,6 @@ static int __init uhci_hcd_init(void)
if (!errbuf)
goto errbuf_failed;
uhci_debugfs_root = debugfs_create_dir("uhci", usb_debug_root);
-   if (!uhci_debugfs_root)
-   goto debug_failed;
 #endif
 
uhci_up_cachep = kmem_cache_create("uhci_urb_priv",
@@ -918,7 +912,6 @@ static int __init uhci_hcd_init(void)
 #if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG)
debugfs_remove(uhci_debugfs_root);
 
-debug_failed:
kfree(errbuf);
 
 errbuf_failed:
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 09/22] USB: imx21-hcd: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Felipe Balbi 
Cc: Johan Hovold 
Cc: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/imx21-dbg.c | 44 
 1 file changed, 10 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/host/imx21-dbg.c b/drivers/usb/host/imx21-dbg.c
index a213ed6f07b5..7fcf1d9dd7f3 100644
--- a/drivers/usb/host/imx21-dbg.c
+++ b/drivers/usb/host/imx21-dbg.c
@@ -417,46 +417,22 @@ DEFINE_SHOW_ATTRIBUTE(debug_isoc);
 
 static void create_debug_files(struct imx21 *imx21)
 {
-   imx21->debug_root = debugfs_create_dir(dev_name(imx21->dev), NULL);
-   if (!imx21->debug_root)
-   goto failed_create_rootdir;
+   struct dentry *root;
 
-   if (!debugfs_create_file("status", S_IRUGO,
-   imx21->debug_root, imx21, _status_fops))
-   goto failed_create;
+   root = debugfs_create_dir(dev_name(imx21->dev), NULL);
+   imx21->debug_root = root;
 
-   if (!debugfs_create_file("dmem", S_IRUGO,
-   imx21->debug_root, imx21, _dmem_fops))
-   goto failed_create;
-
-   if (!debugfs_create_file("etd", S_IRUGO,
-   imx21->debug_root, imx21, _etd_fops))
-   goto failed_create;
-
-   if (!debugfs_create_file("statistics", S_IRUGO,
-   imx21->debug_root, imx21, _statistics_fops))
-   goto failed_create;
-
-   if (!debugfs_create_file("isoc", S_IRUGO,
-   imx21->debug_root, imx21, _isoc_fops))
-   goto failed_create;
-
-   return;
-
-failed_create:
-   debugfs_remove_recursive(imx21->debug_root);
-
-failed_create_rootdir:
-   imx21->debug_root = NULL;
+   debugfs_create_file("status", S_IRUGO, root, imx21, _status_fops);
+   debugfs_create_file("dmem", S_IRUGO, root, imx21, _dmem_fops);
+   debugfs_create_file("etd", S_IRUGO, root, imx21, _etd_fops);
+   debugfs_create_file("statistics", S_IRUGO, root, imx21,
+   _statistics_fops);
+   debugfs_create_file("isoc", S_IRUGO, root, imx21, _isoc_fops);
 }
 
-
 static void remove_debug_files(struct imx21 *imx21)
 {
-   if (imx21->debug_root) {
-   debugfs_remove_recursive(imx21->debug_root);
-   imx21->debug_root = NULL;
-   }
+   debugfs_remove_recursive(imx21->debug_root);
 }
 
 #endif
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 08/22] USB: isp116x-hcd: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Olav Kongas 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/isp116x-hcd.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/isp116x-hcd.c b/drivers/usb/host/isp116x-hcd.c
index 4602ed801f0a..74da136d322a 100644
--- a/drivers/usb/host/isp116x-hcd.c
+++ b/drivers/usb/host/isp116x-hcd.c
@@ -1198,14 +1198,11 @@ static int isp116x_debug_show(struct seq_file *s, void 
*unused)
 }
 DEFINE_SHOW_ATTRIBUTE(isp116x_debug);
 
-static int create_debug_file(struct isp116x *isp116x)
+static void create_debug_file(struct isp116x *isp116x)
 {
isp116x->dentry = debugfs_create_file(hcd_name,
  S_IRUGO, NULL, isp116x,
  _debug_fops);
-   if (!isp116x->dentry)
-   return -ENOMEM;
-   return 0;
 }
 
 static void remove_debug_file(struct isp116x *isp116x)
@@ -1215,8 +1212,8 @@ static void remove_debug_file(struct isp116x *isp116x)
 
 #else
 
-#definecreate_debug_file(d)0
-#defineremove_debug_file(d)do{}while(0)
+static inline void create_debug_file(struct isp116x *isp116x) { }
+static inline void remove_debug_file(struct isp116x *isp116x) { }
 
 #endif /* CONFIG_DEBUG_FS */
 
@@ -1643,16 +1640,10 @@ static int isp116x_probe(struct platform_device *pdev)
 
device_wakeup_enable(hcd->self.controller);
 
-   ret = create_debug_file(isp116x);
-   if (ret) {
-   ERR("Couldn't create debugfs entry\n");
-   goto err7;
-   }
+   create_debug_file(isp116x);
 
return 0;
 
-  err7:
-   usb_remove_hcd(hcd);
   err6:
usb_put_hcd(hcd);
   err5:
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 10/22] USB: fotg210-hcd: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Felipe Balbi 
Cc: Alan Stern 
Cc: Johan Hovold 
Cc: Kuppuswamy Sathyanarayanan 
Cc: Vasyl Gomonovych 
Cc: Mariusz Skamra 
Cc: "Gustavo A. R. Silva" 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/fotg210-hcd.c | 34 +-
 1 file changed, 9 insertions(+), 25 deletions(-)

diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index d8abf401918a..e64eb47770c8 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -844,28 +844,16 @@ static int debug_registers_open(struct inode *inode, 
struct file *file)
 static inline void create_debug_files(struct fotg210_hcd *fotg210)
 {
struct usb_bus *bus = _to_hcd(fotg210)->self;
+   struct dentry *root;
 
-   fotg210->debug_dir = debugfs_create_dir(bus->bus_name,
-   fotg210_debug_root);
-   if (!fotg210->debug_dir)
-   return;
-
-   if (!debugfs_create_file("async", S_IRUGO, fotg210->debug_dir, bus,
-   _async_fops))
-   goto file_error;
-
-   if (!debugfs_create_file("periodic", S_IRUGO, fotg210->debug_dir, bus,
-   _periodic_fops))
-   goto file_error;
+   root = debugfs_create_dir(bus->bus_name, fotg210_debug_root);
+   fotg210->debug_dir = root;
 
-   if (!debugfs_create_file("registers", S_IRUGO, fotg210->debug_dir, bus,
-   _registers_fops))
-   goto file_error;
-
-   return;
-
-file_error:
-   debugfs_remove_recursive(fotg210->debug_dir);
+   debugfs_create_file("async", S_IRUGO, root, bus, _async_fops);
+   debugfs_create_file("periodic", S_IRUGO, root, bus,
+   _periodic_fops);
+   debugfs_create_file("registers", S_IRUGO, root, bus,
+   _registers_fops);
 }
 
 static inline void remove_debug_files(struct fotg210_hcd *fotg210)
@@ -5686,10 +5674,6 @@ static int __init fotg210_hcd_init(void)
sizeof(struct fotg210_itd));
 
fotg210_debug_root = debugfs_create_dir("fotg210", usb_debug_root);
-   if (!fotg210_debug_root) {
-   retval = -ENOENT;
-   goto err_debug;
-   }
 
retval = platform_driver_register(_hcd_driver);
if (retval < 0)
@@ -5699,7 +5683,7 @@ static int __init fotg210_hcd_init(void)
 clean:
debugfs_remove(fotg210_debug_root);
fotg210_debug_root = NULL;
-err_debug:
+
clear_bit(USB_EHCI_LOADED, _hcds_loaded);
return retval;
 }
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/22] USB: typec: tcpm: no need to check return value of debugfs_create_dir()

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Clean up the tcpm.c code to not care about this, turns out no one was
even checking the return value of this function, so it didn't matter.

Note, I do not think this code can be removed in a running system, as
the debugfs root directory will stick around, that should be fixed
someday...

Cc: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/typec/tcpm.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 0ccd2ce1eb59..8a201dd53d36 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -566,21 +566,16 @@ DEFINE_SHOW_ATTRIBUTE(tcpm_debug);
 
 static struct dentry *rootdir;
 
-static int tcpm_debugfs_init(struct tcpm_port *port)
+static void tcpm_debugfs_init(struct tcpm_port *port)
 {
mutex_init(>logbuffer_lock);
/* /sys/kernel/debug/tcpm/usbcX */
-   if (!rootdir) {
+   if (!rootdir)
rootdir = debugfs_create_dir("tcpm", NULL);
-   if (!rootdir)
-   return -ENOMEM;
-   }
 
port->dentry = debugfs_create_file(dev_name(port->dev),
   S_IFREG | 0444, rootdir,
   port, _debug_fops);
-
-   return 0;
 }
 
 static void tcpm_debugfs_exit(struct tcpm_port *port)
@@ -595,7 +590,7 @@ static void tcpm_log(const struct tcpm_port *port, const 
char *fmt, ...) { }
 __printf(2, 3)
 static void tcpm_log_force(struct tcpm_port *port, const char *fmt, ...) { }
 static void tcpm_log_source_caps(struct tcpm_port *port) { }
-static int tcpm_debugfs_init(const struct tcpm_port *port) { return 0; }
+static void tcpm_debugfs_init(const struct tcpm_port *port) { }
 static void tcpm_debugfs_exit(const struct tcpm_port *port) { }
 
 #endif
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/22] USB: typec: fsusb302: no need to check return value of debugfs_create_dir()

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Clean up the fsusb302 driver to not care about the dentry being created,
or if the root directory was created, as the code should work properly
either way.  We do not need to save the dentry anymore as things are
properly cleaned up when we remove the root directory.

Note, this driver seems to only work for one device per system,
otherwise the debugfs directories are going to get confused when a
device is removed.

Cc: Heikki Krogerus 
Cc: Guenter Roeck 
Cc: Hans de Goede 
Cc: Andy Shevchenko 
Cc: Adam Thomson 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/typec/fusb302/fusb302.c | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 9c1eba9ea004..07b07ddf6af0 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -117,7 +117,6 @@ struct fusb302_chip {
u32 snk_pdo[PDO_MAX_OBJECTS];
 
 #ifdef CONFIG_DEBUG_FS
-   struct dentry *dentry;
/* lock for log buffer access */
struct mutex logbuffer_lock;
int logbuffer_head;
@@ -215,33 +214,26 @@ DEFINE_SHOW_ATTRIBUTE(fusb302_debug);
 
 static struct dentry *rootdir;
 
-static int fusb302_debugfs_init(struct fusb302_chip *chip)
+static void fusb302_debugfs_init(struct fusb302_chip *chip)
 {
mutex_init(>logbuffer_lock);
-   if (!rootdir) {
+   if (!rootdir)
rootdir = debugfs_create_dir("fusb302", NULL);
-   if (!rootdir)
-   return -ENOMEM;
-   }
-
-   chip->dentry = debugfs_create_file(dev_name(chip->dev),
-  S_IFREG | 0444, rootdir,
-  chip, _debug_fops);
 
-   return 0;
+   debugfs_create_file(dev_name(chip->dev), S_IFREG | 0444, rootdir, chip,
+   _debug_fops);
 }
 
 static void fusb302_debugfs_exit(struct fusb302_chip *chip)
 {
-   debugfs_remove(chip->dentry);
-   debugfs_remove(rootdir);
+   debugfs_remove_recursive(rootdir);
 }
 
 #else
 
 static void fusb302_log(const struct fusb302_chip *chip,
const char *fmt, ...) { }
-static int fusb302_debugfs_init(const struct fusb302_chip *chip) { return 0; }
+static void fusb302_debugfs_init(const struct fusb302_chip *chip) { }
 static void fusb302_debugfs_exit(const struct fusb302_chip *chip) { }
 
 #endif
@@ -1773,9 +1765,7 @@ static int fusb302_probe(struct i2c_client *client,
return -EPROBE_DEFER;
}
 
-   ret = fusb302_debugfs_init(chip);
-   if (ret < 0)
-   return ret;
+   fusb302_debugfs_init(chip);
 
chip->wq = create_singlethread_workqueue(dev_name(chip->dev));
if (!chip->wq) {
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 20/22] USB: gadget: udc: pxa27x_udc: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

There is also no need to keep the file dentries around at all, so remove
those variables from the device structure.

Cc: Daniel Mack 
Cc: Haojian Zhuang 
Cc: Robert Jarzmik 
Cc: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/gadget/udc/pxa27x_udc.c | 43 -
 drivers/usb/gadget/udc/pxa27x_udc.h |  3 --
 2 files changed, 6 insertions(+), 40 deletions(-)

diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c 
b/drivers/usb/gadget/udc/pxa27x_udc.c
index a58242e901df..014233252299 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -205,50 +205,19 @@ DEFINE_SHOW_ATTRIBUTE(eps_dbg);
 
 static void pxa_init_debugfs(struct pxa_udc *udc)
 {
-   struct dentry *root, *state, *queues, *eps;
+   struct dentry *root;
 
root = debugfs_create_dir(udc->gadget.name, NULL);
-   if (IS_ERR(root) || !root)
-   goto err_root;
-
-   state = debugfs_create_file("udcstate", 0400, root, udc,
-   _dbg_fops);
-   if (!state)
-   goto err_state;
-   queues = debugfs_create_file("queues", 0400, root, udc,
-   _dbg_fops);
-   if (!queues)
-   goto err_queues;
-   eps = debugfs_create_file("epstate", 0400, root, udc,
-   _dbg_fops);
-   if (!eps)
-   goto err_eps;
-
udc->debugfs_root = root;
-   udc->debugfs_state = state;
-   udc->debugfs_queues = queues;
-   udc->debugfs_eps = eps;
-   return;
-err_eps:
-   debugfs_remove(eps);
-err_queues:
-   debugfs_remove(queues);
-err_state:
-   debugfs_remove(root);
-err_root:
-   dev_err(udc->dev, "debugfs is not available\n");
+
+   debugfs_create_file("udcstate", 0400, root, udc, _dbg_fops);
+   debugfs_create_file("queues", 0400, root, udc, _dbg_fops);
+   debugfs_create_file("epstate", 0400, root, udc, _dbg_fops);
 }
 
 static void pxa_cleanup_debugfs(struct pxa_udc *udc)
 {
-   debugfs_remove(udc->debugfs_eps);
-   debugfs_remove(udc->debugfs_queues);
-   debugfs_remove(udc->debugfs_state);
-   debugfs_remove(udc->debugfs_root);
-   udc->debugfs_eps = NULL;
-   udc->debugfs_queues = NULL;
-   udc->debugfs_state = NULL;
-   udc->debugfs_root = NULL;
+   debugfs_remove_recursive(udc->debugfs_root);
 }
 
 #else
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.h 
b/drivers/usb/gadget/udc/pxa27x_udc.h
index 1128d39a4255..13b2977399ab 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.h
+++ b/drivers/usb/gadget/udc/pxa27x_udc.h
@@ -476,9 +476,6 @@ struct pxa_udc {
 #endif
 #ifdef CONFIG_USB_GADGET_DEBUG_FS
struct dentry   *debugfs_root;
-   struct dentry   *debugfs_state;
-   struct dentry   *debugfs_queues;
-   struct dentry   *debugfs_eps;
 #endif
 };
 #define to_pxa(g)  (container_of((g), struct pxa_udc, gadget))
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 12/22] USB: ehci-hcd: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/host/ehci-dbg.c | 30 --
 drivers/usb/host/ehci-hcd.c |  5 -
 2 files changed, 8 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index 3ed75aaa09d9..7619cfb06883 100644
--- a/drivers/usb/host/ehci-dbg.c
+++ b/drivers/usb/host/ehci-dbg.c
@@ -1028,29 +1028,15 @@ static inline void create_debug_files(struct ehci_hcd 
*ehci)
struct usb_bus *bus = _to_hcd(ehci)->self;
 
ehci->debug_dir = debugfs_create_dir(bus->bus_name, ehci_debug_root);
-   if (!ehci->debug_dir)
-   return;
 
-   if (!debugfs_create_file("async", S_IRUGO, ehci->debug_dir, bus,
-   _async_fops))
-   goto file_error;
-
-   if (!debugfs_create_file("bandwidth", S_IRUGO, ehci->debug_dir, bus,
-   _bandwidth_fops))
-   goto file_error;
-
-   if (!debugfs_create_file("periodic", S_IRUGO, ehci->debug_dir, bus,
-   _periodic_fops))
-   goto file_error;
-
-   if (!debugfs_create_file("registers", S_IRUGO, ehci->debug_dir, bus,
-   _registers_fops))
-   goto file_error;
-
-   return;
-
-file_error:
-   debugfs_remove_recursive(ehci->debug_dir);
+   debugfs_create_file("async", S_IRUGO, ehci->debug_dir, bus,
+   _async_fops);
+   debugfs_create_file("bandwidth", S_IRUGO, ehci->debug_dir, bus,
+   _bandwidth_fops);
+   debugfs_create_file("periodic", S_IRUGO, ehci->debug_dir, bus,
+   _periodic_fops);
+   debugfs_create_file("registers", S_IRUGO, ehci->debug_dir, bus,
+   _registers_fops);
 }
 
 static inline void remove_debug_files(struct ehci_hcd *ehci)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index d927adf3afcd..89c47ae5c7d3 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1311,10 +1311,6 @@ static int __init ehci_hcd_init(void)
 
 #ifdef CONFIG_DYNAMIC_DEBUG
ehci_debug_root = debugfs_create_dir("ehci", usb_debug_root);
-   if (!ehci_debug_root) {
-   retval = -ENOENT;
-   goto err_debug;
-   }
 #endif
 
 #ifdef PLATFORM_DRIVER
@@ -1361,7 +1357,6 @@ static int __init ehci_hcd_init(void)
 #ifdef CONFIG_DYNAMIC_DEBUG
debugfs_remove(ehci_debug_root);
ehci_debug_root = NULL;
-err_debug:
 #endif
clear_bit(USB_EHCI_LOADED, _hcds_loaded);
return retval;
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 17/22] USB: udc: atmel_usba_udc: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

There is also no need to keep the file dentries around at all, so remove
those variables from the device structure.

Cc: Nicolas Ferre 
Cc: Felipe Balbi 
Cc: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 71 -
 drivers/usb/gadget/udc/atmel_usba_udc.h |  4 --
 2 files changed, 11 insertions(+), 64 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 2f586f2bda7e..a4d99bf50f2f 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -206,94 +206,45 @@ static void usba_ep_init_debugfs(struct usba_udc *udc,
struct dentry *ep_root;
 
ep_root = debugfs_create_dir(ep->ep.name, udc->debugfs_root);
-   if (!ep_root)
-   goto err_root;
ep->debugfs_dir = ep_root;
 
-   ep->debugfs_queue = debugfs_create_file("queue", 0400, ep_root,
-   ep, _dbg_fops);
-   if (!ep->debugfs_queue)
-   goto err_queue;
-
-   if (ep->can_dma) {
-   ep->debugfs_dma_status
-   = debugfs_create_u32("dma_status", 0400, ep_root,
-   >last_dma_status);
-   if (!ep->debugfs_dma_status)
-   goto err_dma_status;
-   }
-   if (ep_is_control(ep)) {
-   ep->debugfs_state
-   = debugfs_create_u32("state", 0400, ep_root,
-   >state);
-   if (!ep->debugfs_state)
-   goto err_state;
-   }
-
-   return;
-
-err_state:
+   debugfs_create_file("queue", 0400, ep_root, ep, _dbg_fops);
if (ep->can_dma)
-   debugfs_remove(ep->debugfs_dma_status);
-err_dma_status:
-   debugfs_remove(ep->debugfs_queue);
-err_queue:
-   debugfs_remove(ep_root);
-err_root:
-   dev_err(>udc->pdev->dev,
-   "failed to create debugfs directory for %s\n", ep->ep.name);
+   debugfs_create_u32("dma_status", 0400, ep_root,
+  >last_dma_status);
+   if (ep_is_control(ep))
+   debugfs_create_u32("state", 0400, ep_root, >state);
 }
 
 static void usba_ep_cleanup_debugfs(struct usba_ep *ep)
 {
-   debugfs_remove(ep->debugfs_queue);
-   debugfs_remove(ep->debugfs_dma_status);
-   debugfs_remove(ep->debugfs_state);
-   debugfs_remove(ep->debugfs_dir);
-   ep->debugfs_dma_status = NULL;
-   ep->debugfs_dir = NULL;
+   debugfs_remove_recursive(ep->debugfs_dir);
 }
 
 static void usba_init_debugfs(struct usba_udc *udc)
 {
-   struct dentry *root, *regs;
+   struct dentry *root;
struct resource *regs_resource;
 
root = debugfs_create_dir(udc->gadget.name, NULL);
-   if (IS_ERR(root) || !root)
-   goto err_root;
udc->debugfs_root = root;
 
regs_resource = platform_get_resource(udc->pdev, IORESOURCE_MEM,
CTRL_IOMEM_ID);
 
if (regs_resource) {
-   regs = debugfs_create_file_size("regs", 0400, root, udc,
-   _dbg_fops,
-   resource_size(regs_resource));
-   if (!regs)
-   goto err_regs;
-   udc->debugfs_regs = regs;
+   debugfs_create_file_size("regs", 0400, root, udc,
+_dbg_fops,
+resource_size(regs_resource));
}
 
usba_ep_init_debugfs(udc, to_usba_ep(udc->gadget.ep0));
-
-   return;
-
-err_regs:
-   debugfs_remove(root);
-err_root:
-   udc->debugfs_root = NULL;
-   dev_err(>pdev->dev, "debugfs is not available\n");
 }
 
 static void usba_cleanup_debugfs(struct usba_udc *udc)
 {
usba_ep_cleanup_debugfs(to_usba_ep(udc->gadget.ep0));
-   debugfs_remove(udc->debugfs_regs);
-   debugfs_remove(udc->debugfs_root);
-   udc->debugfs_regs = NULL;
-   udc->debugfs_root = NULL;
+   debugfs_remove_recursive(udc->debugfs_root);
 }
 #else
 static inline void usba_ep_init_debugfs(struct usba_udc *udc,
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h 
b/drivers/usb/gadget/udc/atmel_usba_udc.h
index d7eb7cf4fd5c..030bf797cd25 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.h
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
@@ -287,9 +287,6 @@ struct usba_ep {
 #ifdef CONFIG_USB_GA

[PATCH 21/22] USB: gadget: udc: renesas_usb3: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Felipe Balbi 
Cc: Yoshihiro Shimoda 
Cc: Simon Horman 
Cc: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 5caf78bbbf7c..977ea1a02cf9 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2391,22 +2391,10 @@ static const struct file_operations 
renesas_usb3_b_device_fops = {
 static void renesas_usb3_debugfs_init(struct renesas_usb3 *usb3,
  struct device *dev)
 {
-   struct dentry *root, *file;
+   usb3->dentry = debugfs_create_dir(dev_name(dev), NULL);
 
-   root = debugfs_create_dir(dev_name(dev), NULL);
-   if (IS_ERR_OR_NULL(root)) {
-   dev_info(dev, "%s: Can't create the root\n", __func__);
-   return;
-   }
-
-   file = debugfs_create_file("b_device", 0644, root, usb3,
-  _usb3_b_device_fops);
-   if (!file) {
-   dev_info(dev, "%s: Can't create debugfs mode\n", __func__);
-   debugfs_remove_recursive(root);
-   } else {
-   usb3->dentry = root;
-   }
+   debugfs_create_file("b_device", 0644, usb3->dentry, usb3,
+   _usb3_b_device_fops);
 }
 
 /*--- platform_driver */
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 05/22] USB: mon: no need to check return value of debugfs_create functions

2018-05-29 Thread Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

We do need to save the dentries for these files, so keep them around,
but no need to check if they are "valid" or not, as the code works just
as well either way.

Cc: Pete Zaitcev 
Cc: Philippe Ombredanne 
Cc: Fredrik Noring 
Cc: Kate Stewart 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/mon/mon_text.c | 37 +++--
 1 file changed, 7 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/mon/mon_text.c b/drivers/usb/mon/mon_text.c
index 984f7e12a6a5..bc5ecd5ff565 100644
--- a/drivers/usb/mon/mon_text.c
+++ b/drivers/usb/mon/mon_text.c
@@ -700,7 +700,6 @@ static const struct file_operations mon_fops_text_u = {
 
 int mon_text_add(struct mon_bus *mbus, const struct usb_bus *ubus)
 {
-   struct dentry *d;
enum { NAMESZ = 10 };
char name[NAMESZ];
int busnum = ubus? ubus->busnum: 0;
@@ -713,42 +712,32 @@ int mon_text_add(struct mon_bus *mbus, const struct 
usb_bus *ubus)
rc = snprintf(name, NAMESZ, "%dt", busnum);
if (rc <= 0 || rc >= NAMESZ)
goto err_print_t;
-   d = debugfs_create_file(name, 0600, mon_dir, mbus,
+   mbus->dent_t = debugfs_create_file(name, 0600, mon_dir, mbus,
 _fops_text_t);
-   if (d == NULL)
-   goto err_create_t;
-   mbus->dent_t = d;
}
 
rc = snprintf(name, NAMESZ, "%du", busnum);
if (rc <= 0 || rc >= NAMESZ)
goto err_print_u;
-   d = debugfs_create_file(name, 0600, mon_dir, mbus, _fops_text_u);
-   if (d == NULL)
-   goto err_create_u;
-   mbus->dent_u = d;
+   mbus->dent_u = debugfs_create_file(name, 0600, mon_dir, mbus,
+  _fops_text_u);
 
rc = snprintf(name, NAMESZ, "%ds", busnum);
if (rc <= 0 || rc >= NAMESZ)
goto err_print_s;
-   d = debugfs_create_file(name, 0600, mon_dir, mbus, _fops_stat);
-   if (d == NULL)
-   goto err_create_s;
-   mbus->dent_s = d;
+   mbus->dent_s = debugfs_create_file(name, 0600, mon_dir, mbus,
+  _fops_stat);
 
return 1;
 
-err_create_s:
 err_print_s:
debugfs_remove(mbus->dent_u);
mbus->dent_u = NULL;
-err_create_u:
 err_print_u:
if (ubus != NULL) {
debugfs_remove(mbus->dent_t);
mbus->dent_t = NULL;
}
-err_create_t:
 err_print_t:
return 0;
 }
@@ -756,8 +745,7 @@ int mon_text_add(struct mon_bus *mbus, const struct usb_bus 
*ubus)
 void mon_text_del(struct mon_bus *mbus)
 {
debugfs_remove(mbus->dent_u);
-   if (mbus->dent_t != NULL)
-   debugfs_remove(mbus->dent_t);
+   debugfs_remove(mbus->dent_t);
debugfs_remove(mbus->dent_s);
 }
 
@@ -775,18 +763,7 @@ static void mon_text_ctor(void *mem)
 
 int __init mon_text_init(void)
 {
-   struct dentry *mondir;
-
-   mondir = debugfs_create_dir("usbmon", usb_debug_root);
-   if (IS_ERR(mondir)) {
-   /* debugfs not available, but we can use usbmon without it */
-   return 0;
-   }
-   if (mondir == NULL) {
-   printk(KERN_NOTICE TAG ": unable to create usbmon directory\n");
-   return -ENOMEM;
-   }
-   mon_dir = mondir;
+   mon_dir = debugfs_create_dir("usbmon", usb_debug_root);
return 0;
 }
 
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [usb:debugfs_cleanup 109/109] drivers/usb/typec/tcpm.c:580:9: warning: 'return' with a value, in function returning void

2018-05-29 Thread Greg Kroah-Hartman
On Tue, May 29, 2018 at 05:32:48PM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
> debugfs_cleanup
> head:   7b3bcbfe0aeedeec64c83cf9655273e8f42f1c54
> commit: 7b3bcbfe0aeedeec64c83cf9655273e8f42f1c54 [109/109] usb: debugfs 
> cleanup
> config: i386-randconfig-s1-201821 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
> git checkout 7b3bcbfe0aeedeec64c83cf9655273e8f42f1c54
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/usb/typec/tcpm.c: In function 'tcpm_debugfs_init':
> >> drivers/usb/typec/tcpm.c:580:9: warning: 'return' with a value, in 
> >> function returning void
>  return 0;
> ^
>drivers/usb/typec/tcpm.c:569:13: note: declared here
> static void tcpm_debugfs_init(struct tcpm_port *port)
> ^

For the linux-usb crowd, this is a bug in one of my in-work patches, no
need to worry...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device

2018-05-27 Thread Greg Kroah-Hartman
On Sun, May 27, 2018 at 07:48:47AM +0200, Marcus Folkesson wrote:
> On Sat, May 26, 2018 at 10:56:52PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote:
> > > Signed-off-by: Marcus Folkesson <marcus.folkes...@gmail.com>
> > 
> > I can't take patches without any changelog text.  And why would you
> > submit a patch over 1000 lines without any?
> 
> I'm sorry, obviously not much went well for me yesterday.
> The changlelog was "fixup:ed" away and now I noticed that my
> patch version history did not follow for v2.
> 
> Is it better to send a v3 with updated version history or wait for more
> comments?

Nah, that's fine, but I'll let Felipe decide as he is the one that has
to review this, not me.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device

2018-05-26 Thread Greg Kroah-Hartman
On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote:
> Signed-off-by: Marcus Folkesson 

I can't take patches without any changelog text.  And why would you
submit a patch over 1000 lines without any?

Please fix.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

2018-05-25 Thread Greg Kroah-Hartman
On Wed, May 23, 2018 at 10:16:56AM +0800, Nicolas Boichat wrote:
> The "old" enumeration scheme is considerably faster (it takes
> ~294ms instead of ~439ms to get the descriptor).
> 
> It is currently only possible to use the old scheme globally
> (/sys/module/usbcore/parameters/old_scheme_first), which is not
> desirable as the new scheme was introduced to increase compatibility
> with more devices.
> 
> However, in our case, we care about time-to-active for a specific
> USB device (which we make the firmware for), on a specific port
> (that is pogo-pin based: not a standard USB port). This new
> sysfs option makes it possible to use the old scheme on a single
> port only.
> 
> Signed-off-by: Nicolas Boichat 
> ---
> 
> There are other "quirks" that we could add to reduce further
> enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY
> to 10ms instead of 50ms as used currently), but the logic is quite
> similar, so it'd be good to have this reviewed first.
> 
>  drivers/usb/core/hub.c  | 13 +
>  drivers/usb/core/hub.h  |  1 +
>  drivers/usb/core/port.c | 23 +++
>  include/linux/usb.h |  7 +++
>  4 files changed, 40 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index c2d993d3816f0..f900f66a62856 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2636,7 +2636,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
>  #define SET_ADDRESS_TRIES2
>  #define GET_DESCRIPTOR_TRIES 2
>  #define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
> -#define USE_NEW_SCHEME(i)((i) / 2 == (int)old_scheme_first)
> +#define USE_NEW_SCHEME(i, scheme)((i) / 2 == (int)scheme)
>  
>  #define HUB_ROOT_RESET_TIME  60  /* times are in msec */
>  #define HUB_SHORT_RESET_TIME 10
> @@ -2651,12 +2651,16 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
>   * enumeration failures, so disable this enumeration scheme for USB3
>   * devices.
>   */
> -static bool use_new_scheme(struct usb_device *udev, int retry)
> +static bool use_new_scheme(struct usb_device *udev, int retry,
> +struct usb_port *port_dev)
>  {
> + int old_scheme_first_port =
> + port_dev->quirks & USB_PORT_QUIRK_OLD_SCHEME;
> +
>   if (udev->speed >= USB_SPEED_SUPER)
>   return false;
>  
> - return USE_NEW_SCHEME(retry);
> + return USE_NEW_SCHEME(retry, old_scheme_first_port || old_scheme_first);
>  }
>  
>  /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
> @@ -4392,6 +4396,7 @@ hub_port_init(struct usb_hub *hub, struct usb_device 
> *udev, int port1,
>  {
>   struct usb_device   *hdev = hub->hdev;
>   struct usb_hcd  *hcd = bus_to_hcd(hdev->bus);
> + struct usb_port *port_dev = hub->ports[port1 - 1];
>   int retries, operations, retval, i;
>   unsigneddelay = HUB_SHORT_RESET_TIME;
>   enum usb_device_speed   oldspeed = udev->speed;
> @@ -4513,7 +4518,7 @@ hub_port_init(struct usb_hub *hub, struct usb_device 
> *udev, int port1,
>   for (retries = 0; retries < GET_DESCRIPTOR_TRIES; (++retries, 
> msleep(100))) {
>   bool did_new_scheme = false;
>  
> - if (use_new_scheme(udev, retry_counter)) {
> + if (use_new_scheme(udev, retry_counter, port_dev)) {
>   struct usb_device_descriptor *buf;
>   int r = 0;
>  
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 4dc769ee9c740..4accfb63f7dcb 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -98,6 +98,7 @@ struct usb_port {
>   struct mutex status_lock;
>   u32 over_current_count;
>   u8 portnum;
> + u32 quirks;
>   unsigned int is_superspeed:1;
>   unsigned int usb3_lpm_u1_permit:1;
>   unsigned int usb3_lpm_u2_permit:1;
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index 6979bde87d310..4a21431953953 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -50,6 +50,28 @@ static ssize_t over_current_count_show(struct device *dev,
>  }
>  static DEVICE_ATTR_RO(over_current_count);
>  
> +static ssize_t quirks_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + struct usb_port *port_dev = to_usb_port(dev);
> +
> + return sprintf(buf, "%08x\n", port_dev->quirks);
> +}
> +
> +static ssize_t quirks_store(struct device *dev, struct device_attribute 
> *attr,
> + const char *buf, size_t count)
> +{
> + struct usb_port *port_dev = to_usb_port(dev);
> + u32 value;
> +
> + if (kstrtou32(buf, 16, ))
> + return -EINVAL;
> +
> + port_dev->quirks = value;
> + return count;
> +}
> +static DEVICE_ATTR_RW(quirks);
> +
>  static ssize_t usb3_lpm_permit_show(struct device *dev,
> struct 

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

2018-05-25 Thread Greg Kroah-Hartman
On Fri, May 25, 2018 at 06:05:16AM +0800, Nicolas Boichat wrote:
> On Fri, May 25, 2018 at 12:21 AM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Thu, May 24, 2018 at 07:42:00AM +0800, Nicolas Boichat wrote:
> >> On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman
> >> <gre...@linuxfoundation.org> wrote:
> >> > On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote:
> >> >> On Wed, 23 May 2018, Nicolas Boichat wrote:
> >> >>
> >> >> > The "old" enumeration scheme is considerably faster (it takes
> >> >> > ~294ms instead of ~439ms to get the descriptor).
> >> >> >
> >> >> > It is currently only possible to use the old scheme globally
> >> >> > (/sys/module/usbcore/parameters/old_scheme_first), which is not
> >> >> > desirable as the new scheme was introduced to increase compatibility
> >> >> > with more devices.
> >> >> >
> >> >> > However, in our case, we care about time-to-active for a specific
> >> >> > USB device (which we make the firmware for), on a specific port
> >> >> > (that is pogo-pin based: not a standard USB port). This new
> >> >> > sysfs option makes it possible to use the old scheme on a single
> >> >> > port only.
> >> >> >
> >> >> > Signed-off-by: Nicolas Boichat <drink...@chromium.org>
> >> >> > ---
> >> >> >
> >> >> > There are other "quirks" that we could add to reduce further
> >> >> > enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY
> >> >> > to 10ms instead of 50ms as used currently), but the logic is quite
> >> >> > similar, so it'd be good to have this reviewed first.
> >> >>
> >> >> I'm not opposed to the idea in principle, although I don't like your
> >> >> implementation because it breaks the original old_scheme_first
> >> >> parameter.
> >>
> >> I don't think it breaks the original parameter? I mean,
> >> /sys/module/usbcore/parameters/old_scheme_first is still a global
> >> default, while bit 0 of /sys/bus/usb/devices/x/y/z/quirks becomes a
> >> port-specific override.
> >>
> >> >> Let's see what some other people think.
> >> >>
> >> >> Yours is a rather special case, because you know exactly what device
> >> >> will be attached to a specific port.  Still, I can see that sort of
> >> >> thing happening in constrained and special-purpose settings.
> >> >>
> >> >> How do you arrange to set the new quirk before the device is
> >> >> discovered?
> >> >
> >> > Yeah, this last question is what I had when looking at this.  Or does it
> >> > not matter at first boot and only matters for wake-up?
> >>
> >> It does not matter on boot, we have plenty of time to enumerate the
> >> device. We use USB (auto-)suspend and remote wake, so no
> >> re-enumeration there either. It only matters on unplug/replug where
> >> the device needs to be re-enumerated.
> >
> > How does this device get unplugged/replugged if it is connected directly
> > to the device?
> 
> It is external. Essentially, this is a tablet with a detachable
> keyboard/touchpad. The interface between tablet and base is USB, over
> pogo pins. The port is non-standard (pogo, not normal USB), and we
> fully control the firmware on the base side as well, which allows us
> to take shortcuts like this: we know exactly what device will be
> connected on that port.

Ah, ok, that makes more sense, thanks for the explanation.  I'll go
queue this up in a bit.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

2018-05-24 Thread Greg Kroah-Hartman
On Thu, May 24, 2018 at 07:42:00AM +0800, Nicolas Boichat wrote:
> On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> > On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote:
> >> On Wed, 23 May 2018, Nicolas Boichat wrote:
> >>
> >> > The "old" enumeration scheme is considerably faster (it takes
> >> > ~294ms instead of ~439ms to get the descriptor).
> >> >
> >> > It is currently only possible to use the old scheme globally
> >> > (/sys/module/usbcore/parameters/old_scheme_first), which is not
> >> > desirable as the new scheme was introduced to increase compatibility
> >> > with more devices.
> >> >
> >> > However, in our case, we care about time-to-active for a specific
> >> > USB device (which we make the firmware for), on a specific port
> >> > (that is pogo-pin based: not a standard USB port). This new
> >> > sysfs option makes it possible to use the old scheme on a single
> >> > port only.
> >> >
> >> > Signed-off-by: Nicolas Boichat <drink...@chromium.org>
> >> > ---
> >> >
> >> > There are other "quirks" that we could add to reduce further
> >> > enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY
> >> > to 10ms instead of 50ms as used currently), but the logic is quite
> >> > similar, so it'd be good to have this reviewed first.
> >>
> >> I'm not opposed to the idea in principle, although I don't like your
> >> implementation because it breaks the original old_scheme_first
> >> parameter.
> 
> I don't think it breaks the original parameter? I mean,
> /sys/module/usbcore/parameters/old_scheme_first is still a global
> default, while bit 0 of /sys/bus/usb/devices/x/y/z/quirks becomes a
> port-specific override.
> 
> >> Let's see what some other people think.
> >>
> >> Yours is a rather special case, because you know exactly what device
> >> will be attached to a specific port.  Still, I can see that sort of
> >> thing happening in constrained and special-purpose settings.
> >>
> >> How do you arrange to set the new quirk before the device is
> >> discovered?
> >
> > Yeah, this last question is what I had when looking at this.  Or does it
> > not matter at first boot and only matters for wake-up?
> 
> It does not matter on boot, we have plenty of time to enumerate the
> device. We use USB (auto-)suspend and remote wake, so no
> re-enumeration there either. It only matters on unplug/replug where
> the device needs to be re-enumerated.

How does this device get unplugged/replugged if it is connected directly
to the device?

> Somewhere in an init script, we would do this (we know in advance that
> usb1 port2 is the bus/port where we have our pogo-pin USB interface,
> so we can hard-code the path):
> echo 1 > /sys/bus/usb/devices/usb1/1-0:1.0/usb1-port2/quirks
> 
> We could try to add ACPI support (just like connect_type), but we
> don't strictly need it for our application.

Isn't there an "internal" ACPI flag for USB ports, or is that
what connect_type is?  Why wouldn't that work here instead?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] USB for v4.18 merge window

2018-05-24 Thread Greg Kroah-Hartman
On Mon, May 21, 2018 at 11:25:09AM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> Here's my pull request for v4.18 merge window. Let me know if you want
> anything to be changed.
> 
> For the rest of the week I'll have very scarce access to email, so
> replies may be delayed.
> 
> Cheers
> 
> The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:
> 
>   Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.18

There was a conflict in drivers/usb/mtu3/Kconfig, but I think I fixed it
up properly.  Otherwise all looks good, pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

2018-05-23 Thread Greg Kroah-Hartman
On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote:
> On Wed, 23 May 2018, Nicolas Boichat wrote:
> 
> > The "old" enumeration scheme is considerably faster (it takes
> > ~294ms instead of ~439ms to get the descriptor).
> > 
> > It is currently only possible to use the old scheme globally
> > (/sys/module/usbcore/parameters/old_scheme_first), which is not
> > desirable as the new scheme was introduced to increase compatibility
> > with more devices.
> > 
> > However, in our case, we care about time-to-active for a specific
> > USB device (which we make the firmware for), on a specific port
> > (that is pogo-pin based: not a standard USB port). This new
> > sysfs option makes it possible to use the old scheme on a single
> > port only.
> > 
> > Signed-off-by: Nicolas Boichat 
> > ---
> > 
> > There are other "quirks" that we could add to reduce further
> > enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY
> > to 10ms instead of 50ms as used currently), but the logic is quite
> > similar, so it'd be good to have this reviewed first.
> 
> I'm not opposed to the idea in principle, although I don't like your
> implementation because it breaks the original old_scheme_first
> parameter.
> 
> Let's see what some other people think.
> 
> Yours is a rather special case, because you know exactly what device
> will be attached to a specific port.  Still, I can see that sort of
> thing happening in constrained and special-purpose settings.
> 
> How do you arrange to set the new quirk before the device is 
> discovered?

Yeah, this last question is what I had when looking at this.  Or does it
not matter at first boot and only matters for wake-up?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 01/33] usb: phy: use match_string() helper

2018-05-22 Thread Greg Kroah-Hartman
On Tue, May 22, 2018 at 01:20:01AM +0300, Andy Shevchenko wrote:
> On Mon, May 21, 2018 at 2:57 PM, Yisheng Xie  wrote:
> > match_string() returns the index of an array for a matching string,
> > which can be used intead of open coded variant.
> 
> > -   int err, i;
> > +   int ret;
> 
> int err;
> 
> would still work.

And it reduces churn.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] tty: add missing const to termios hw-change helper

2018-05-21 Thread Greg Kroah-Hartman
On Mon, May 21, 2018 at 01:08:44PM +0200, Johan Hovold wrote:
> Add missing const qualifiers to the termios hw-change helper parameters,
> which is used by few USB serial drivers. This specifically allows the
> pl2303 driver to use const arguments in one of its helper as well.
> 
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Jiri Slaby <jsl...@suse.com>
> Signed-off-by: Johan Hovold <jo...@kernel.org>
> ---
> 
> Greg, are you fine with me taking this one through my tree, or do prefer
> I split out the pl2303 bits?
> 
> Note that this helper is only used by a few USB serial drivers and that
> the pl2303 bits depend on a new patch targeted for -next.

Your tree is fine:

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4] NFC: pn533: don't send USB data off of the stack

2018-05-20 Thread Greg Kroah-Hartman
It's amazing that this driver ever worked, but now that x86 doesn't
allow USB data to be sent off of the stack, it really does not work at
all.  Fix this up by properly allocating the data for the small
"commands" that get sent to the device off of the stack.

We do this for one command by having a whole urb just for ack messages,
as they can be submitted in interrupt context, so we can not use
usb_bulk_msg().  But the poweron command can sleep (and does), so use
usb_bulk_msg() for that transfer.

Reported-by: Carlos Manuel Santos <cmmpsan...@gmail.com>
Cc: Samuel Ortiz <sa...@linux.intel.com>
Cc: Stephen Hemminger <step...@networkplumber.org>
Cc: stable <sta...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
v4: don't use urb transfer buffer flags as the memory is tied to the urb
(thanks to Johan)  Now we have a new static urb, and we use
usb_bulk_msg() for the other message.
v3: actually use the correct buffer (thanks to Arend van Spriel)
use kmemdup (thanks to Johannes Berg and Julia Lawall)
v2: set the urb flags correctly

 drivers/nfc/pn533/usb.c |   42 ++
 1 file changed, 30 insertions(+), 12 deletions(-)

--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -62,6 +62,9 @@ struct pn533_usb_phy {
struct urb *out_urb;
struct urb *in_urb;
 
+   struct urb *ack_urb;
+   u8 *ack_buffer;
+
struct pn533 *priv;
 };
 
@@ -150,13 +153,16 @@ static int pn533_usb_send_ack(struct pn5
struct pn533_usb_phy *phy = dev->phy;
static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
/* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
-   int rc;
 
-   phy->out_urb->transfer_buffer = (u8 *)ack;
-   phy->out_urb->transfer_buffer_length = sizeof(ack);
-   rc = usb_submit_urb(phy->out_urb, flags);
+   if (!phy->ack_buffer) {
+   phy->ack_buffer = kmemdup(ack, sizeof(ack), flags);
+   if (!phy->ack_buffer)
+   return -ENOMEM;
+   }
 
-   return rc;
+   phy->ack_urb->transfer_buffer = phy->ack_buffer;
+   phy->ack_urb->transfer_buffer_length = sizeof(ack);
+   return usb_submit_urb(phy->ack_urb, flags);
 }
 
 static int pn533_usb_send_frame(struct pn533 *dev,
@@ -375,26 +381,31 @@ static int pn533_acr122_poweron_rdr(stru
/* Power on th reader (CCID cmd) */
u8 cmd[10] = {PN533_ACR122_PC_TO_RDR_ICCPOWERON,
  0, 0, 0, 0, 0, 0, 3, 0, 0};
+   char *buffer;
+   int transferred;
int rc;
void *cntx;
struct pn533_acr122_poweron_rdr_arg arg;
 
dev_dbg(>udev->dev, "%s\n", __func__);
 
+   buffer = kmemdup(cmd, sizeof(cmd), GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
init_completion();
cntx = phy->in_urb->context;  /* backup context */
 
phy->in_urb->complete = pn533_acr122_poweron_rdr_resp;
phy->in_urb->context = 
 
-   phy->out_urb->transfer_buffer = cmd;
-   phy->out_urb->transfer_buffer_length = sizeof(cmd);
-
print_hex_dump_debug("ACR122 TX: ", DUMP_PREFIX_NONE, 16, 1,
   cmd, sizeof(cmd), false);
 
-   rc = usb_submit_urb(phy->out_urb, GFP_KERNEL);
-   if (rc) {
+   rc = usb_bulk_msg(phy->udev, phy->out_urb->pipe, buffer, sizeof(cmd),
+ , 0);
+   kfree(buffer);
+   if (rc || (transferred != sizeof(cmd))) {
nfc_err(>udev->dev,
"Reader power on cmd error %d\n", rc);
return rc;
@@ -490,8 +501,9 @@ static int pn533_usb_probe(struct usb_in
 
phy->in_urb = usb_alloc_urb(0, GFP_KERNEL);
phy->out_urb = usb_alloc_urb(0, GFP_KERNEL);
+   phy->ack_urb = usb_alloc_urb(0, GFP_KERNEL);
 
-   if (!phy->in_urb || !phy->out_urb)
+   if (!phy->in_urb || !phy->out_urb || !phy->ack_urb)
goto error;
 
usb_fill_bulk_urb(phy->in_urb, phy->udev,
@@ -501,7 +513,9 @@ static int pn533_usb_probe(struct usb_in
usb_fill_bulk_urb(phy->out_urb, phy->udev,
  usb_sndbulkpipe(phy->udev, out_endpoint),
  NULL, 0, pn533_send_complete, phy);
-
+   usb_fill_bulk_urb(phy->ack_urb, phy->udev,
+ usb_sndbulkpipe(phy->udev, out_endpoint),
+ NULL, 0, pn533_send_complete, phy);
 
switch (id->driver_info) {
case PN533_DEVICE_STD:
@@ -554,6 +568,7 @@ static int pn533_usb_probe(struct usb_in
 error:
usb_free_urb(phy->in_urb);
usb_free_urb(phy->out_urb);
+   usb_free_urb(phy->ack_urb);
usb_put_dev(phy->udev);

Re: [PATCH v3] NFC: pn533: don't send USB data off of the stack

2018-05-19 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 05:48:47PM +0200, Johan Hovold wrote:
> On Fri, May 18, 2018 at 12:38:11PM +0200, Greg Kroah-Hartman wrote:
> > It's amazing that this driver ever worked, but now that x86 doesn't
> > allow USB data to be sent off of the stack, it really does not work at
> > all.  Fix this up by properly allocating the data for the small
> > "commands" that get sent to the device.
> > 
> > The USB stack will free the buffer when the data has been transmitted,
> > that is why there is no kfree() to mirror the call to kmalloc().
> 
> It looks like you're now leaking all but the final transfer buffer that
> is allocated for outgoing commands, as the URBs themselves are not freed
> until disconnect() (and that's when core would free the buffers along
> with the URBs if URB_FREE_BUFFER is set).

Ugh, you are right.  The urb handling in this driver is crazy...

Let me go redo this whole thing, give me a few days...

thanks for the review, much appreciated.

Carlos, it would be good to know if your testing showed that the patch
at least enables the device to work for now.  It will leak memory like
crazy, so I don't recomment relying on the driver, but it should be good
enough to see if my thinking as to why the driver was not working is
correct or not.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 03/12] usb: usbtmc: Add ioctls to set/get usb timeout

2018-05-19 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 10:48:30PM +0300, Andy Shevchenko wrote:
> On Thu, May 17, 2018 at 8:03 PM, Guido Kiener  
> wrote:
> > Add ioctls USBTMC_IOCTL_GET_TIMEOUT / USBTMC_IOCTL_SET_TIMEOUT to
> > get/set I/O timeout for specific file handle.
> 
> 
> 
> 
> > +static int usbtmc_ioctl_get_timeout(struct usbtmc_file_data *file_data,
> > +   void __user *arg)
> > +{
> > +   __u32 timeout;
> > +
> > +   timeout = file_data->timeout;
> 
> Why do you need __u32 on kernel side?
> Would plain u32 work?

Yes, on the kernel side that is the correct type to use after you copy
it over from userspace.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

2018-05-19 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 05:27:22PM -0500, Gustavo A. R. Silva wrote:
> 
> 
> On 05/18/2018 11:06 AM, Shuah Khan wrote:
> > On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote:
> > > On Thu, May 17, 2018 at 03:16:28PM -0500, Gustavo A. R. Silva wrote:
> > > > pdev_nr and rhport can be controlled by user-space, hence leading to
> > > > a potential exploitation of the Spectre variant 1 vulnerability.
> > > > 
> > > > This issue was detected with the help of Smatch:
> > > > drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential 
> > > > spectre issue 'vhcis'
> > > > drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential 
> > > > spectre issue 'vhcis'
> > > > drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential 
> > > > spectre issue 'vhci->vhci_hcd_ss->vdev'
> > > > drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential 
> > > > spectre issue 'vhci->vhci_hcd_hs->vdev'
> > > > 
> > > > Fix this by sanitizing pdev_nr and rhport before using them to index
> > > > vhcis and vhci->vhci_hcd_ss->vdev respectively.
> > > > 
> > > > Notice that given that speculation windows are large, the policy is
> > > > to kill the speculation on the first load and not worry if it can be
> > > > completed with a dependent load/store [1].
> > > > 
> > > > [1] https://marc.info/?l=linux-kernel=152449131114778=2
> > > > 
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com>
> > > > ---
> > > > Changes in v2:
> > > >   - Place the barriers into valid_port.
> > attach_store() doesn't call valid_port() - can you make the change to
> > have attach_store() call valid_port() to protect that code path.
> > 
> > > 
> > > Thanks for the change.  I'll wait for Shuah's ack/review before queueing
> > > this up just as she knows that codebase much better than anyone else.
> > > > 
> > 
> 
> Greg,
> 
> I've been talking with Dan Williams (intel) about this kind of issues [1]
> and it seems my original assumptions are correct. Hence, this patch is not
> useful and, in order to actually prevent speculation here we would need to
> pass the address of pdev_nr and rhport into valid_port, otherwise there may
> be speculation at drivers/usb/usbip/vhci_sysfs.c:235:
> 
> if (!valid_port(pdev_nr, rhport))
> return -EINVAL;
> 
> hcd = platform_get_drvdata(vhcis[pdev_nr].pdev);

Ah, yes, sorry, you do need to pass the address through, my mistake
completely.  But the location for the checking is still the right place
to do it, so I was half-right :)

thanks

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9360/9370

2018-05-18 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 06:08:24PM +0300, Heikki Krogerus wrote:
> 
> Rafael, the problem here with these Dell laptops is that a memory page
> that is used as a mailbox for special communication between EC FW and
> OS (called UCSI mailbox) should be in uncached memory, but the memory
> is marked as cached.
> 
> I'm actually not even sure if the cache mode is something that is set
> based on information from ACPI tables, or is it something that the
> BIOS handles separately?
> 
> If it's information coming from ACPI tables, can we help pin point the
> place the BIOS guys at Dell should fix?

Given that Windows works with this same set of ACPI tables, perhaps the
requirement isn't that this memory location be uncached?

We shouldn't have to fix up ACPI tables just for Linux, we've been down
that path before :(

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] USB: serial: ftdi_sio: fix IXON/IXOFF mixup

2018-05-18 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 04:33:50PM +0200, Johan Hovold wrote:
> On Fri, May 18, 2018 at 03:53:54PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, May 18, 2018 at 03:25:47PM +0200, Johan Hovold wrote:
> > > Since forever this driver has had IXON and IXOFF mixed up, and has used
> > > the latter rather than the former to enable hardware-assisted software
> > > flow control on output.
> 
> > Ugh, that's a huge sign that no one actually uses IXON/IXOFF anymore :(
> 
> Could be that some applications set both IXON and IXOFF "just to be
> safe"; that appears to be the case with minicom at least.
> 
> > Anyway, thanks for fixing this up, should also probably be backported to
> > the stable kernels.
> 
> I considered that, but since its a change in behaviour I figured it was
> best that anyone affected hits this with a major (minor?) kernel version
> update (rather than a stable update). But I'll add a stable tag if you
> think it's warranted?

Fair enough.  If anyone notices we can easily backport it later on if
needed.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] USB: serial: ftdi_sio: clean up flow control management

2018-05-18 Thread Greg Kroah-Hartman
,
> - NULL, 0, WDR_TIMEOUT) < 0) {
> - dev_err(ddev, "urb failed to clear flow 
> control\n");
> - }
> - }
> + dev_dbg(>dev, "disabling flow control\n");
> + index = FTDI_SIO_DISABLE_FLOW_CTRL;
>   }
> +
> + index |= priv->interface;
> +
> + ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> + FTDI_SIO_SET_FLOW_CTRL_REQUEST,
> + FTDI_SIO_SET_FLOW_CTRL_REQUEST_TYPE,
> + value, index, NULL, 0, WDR_TIMEOUT);
> + if (ret < 0)
> + dev_err(>dev, "failed to set flow control: %d\n", ret);
>  }
>  
>  /*

Wow, much simpler, nice work.

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] USB: serial: ftdi_sio: drop unnecessary urb_ variable prefixes

2018-05-18 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 03:25:49PM +0200, Johan Hovold wrote:
> Drop urb_ prefixes from value and index variables used in control
> requests.
> 
> Signed-off-by: Johan Hovold <jo...@kernel.org>
> ---
>  drivers/usb/serial/ftdi_sio.c | 83 +--
>  1 file changed, 41 insertions(+), 42 deletions(-)

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4] USB: serial: ftdi_sio: fix IXON/IXOFF mixup

2018-05-18 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 03:25:47PM +0200, Johan Hovold wrote:
> Since forever this driver has had IXON and IXOFF mixed up, and has used
> the latter rather than the former to enable hardware-assisted software
> flow control on output.
> 
> Signed-off-by: Johan Hovold <jo...@kernel.org>
> ---
>  drivers/usb/serial/ftdi_sio.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 7ea221d42dba..62c99871863c 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -2342,12 +2342,8 @@ static void ftdi_set_termios(struct tty_struct *tty,
>   } else {
>   /*
>* Xon/Xoff code
> -  *
> -  * Check the IXOFF status in the iflag component of the
> -  * termios structure. If IXOFF is not set, the pre-xon/xoff
> -  * code is executed.
>*/
> - if (iflag & IXOFF) {
> + if (iflag & IXON) {
>   dev_dbg(ddev, "%s  request to enable xonxoff 
> iflag=%04x\n",
>   __func__, iflag);
>   /* Try to enable the XON/XOFF on the ftdi_sio
> @@ -2372,7 +2368,7 @@ static void ftdi_set_termios(struct tty_struct *tty,
>   }
>   } else {
>   /* else clause to only run if cflag ! CRTSCTS and iflag
> -  * ! XOFF. CHECKME Assuming XON/XOFF handled by tty
> +  * ! XON. CHECKME Assuming XON/XOFF handled by tty
>* stack - not by device */
>   dev_dbg(ddev, "%s Turning off hardware flow control\n", 
> __func__);
>   if (usb_control_msg(dev,

Ugh, that's a huge sign that no one actually uses IXON/IXOFF anymore :(

Anyway, thanks for fixing this up, should also probably be backported to
the stable kernels.

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4] USB: serial: ftdi_sio: use non-underscore fixed types

2018-05-18 Thread Greg Kroah-Hartman
On Fri, May 18, 2018 at 03:25:48PM +0200, Johan Hovold wrote:
> Replace all __u types with their u counterparts throughout the driver
> (whose structures are not exported to user space).
> 
> Signed-off-by: Johan Hovold <jo...@kernel.org>
> ---
>  drivers/usb/serial/ftdi_sio.c | 50 +--
>  1 file changed, 25 insertions(+), 25 deletions(-)

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

2018-05-18 Thread Greg Kroah-Hartman
On Thu, May 17, 2018 at 03:16:28PM -0500, Gustavo A. R. Silva wrote:
> pdev_nr and rhport can be controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
> 
> This issue was detected with the help of Smatch:
> drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre 
> issue 'vhcis'
> drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre 
> issue 'vhcis'
> drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre 
> issue 'vhci->vhci_hcd_ss->vdev'
> drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre 
> issue 'vhci->vhci_hcd_hs->vdev'
> 
> Fix this by sanitizing pdev_nr and rhport before using them to index
> vhcis and vhci->vhci_hcd_ss->vdev respectively.
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  - Place the barriers into valid_port.

Thanks for the change.  I'll wait for Shuah's ack/review before queueing
this up just as she knows that codebase much better than anyone else.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] NFC: pn533: don't send USB data off of the stack

2018-05-18 Thread Greg Kroah-Hartman
It's amazing that this driver ever worked, but now that x86 doesn't
allow USB data to be sent off of the stack, it really does not work at
all.  Fix this up by properly allocating the data for the small
"commands" that get sent to the device.

The USB stack will free the buffer when the data has been transmitted,
that is why there is no kfree() to mirror the call to kmalloc().

Reported-by: Carlos Manuel Santos <cmmpsan...@gmail.com>
Cc: Samuel Ortiz <sa...@linux.intel.com>
Cc: Stephen Hemminger <step...@networkplumber.org>
Cc: stable <sta...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
v3: actually use the correct buffer (thanks to Arend van Spriel)
use kmemdup (thanks to Johannes Berg and Julia Lawall)
v2: set the urb flags correctly

 drivers/nfc/pn533/usb.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -150,10 +150,16 @@ static int pn533_usb_send_ack(struct pn5
struct pn533_usb_phy *phy = dev->phy;
static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
/* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
+   char *buffer;
int rc;
 
-   phy->out_urb->transfer_buffer = (u8 *)ack;
+   buffer = kmemdup(ack, sizeof(ack), GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
+   phy->out_urb->transfer_buffer = buffer;
phy->out_urb->transfer_buffer_length = sizeof(ack);
+   phy->out_urb->transfer_flags |= URB_FREE_BUFFER;
rc = usb_submit_urb(phy->out_urb, flags);
 
return rc;
@@ -170,6 +176,7 @@ static int pn533_usb_send_frame(struct p
 
phy->out_urb->transfer_buffer = out->data;
phy->out_urb->transfer_buffer_length = out->len;
+   phy->out_urb->transfer_flags &= ~URB_FREE_BUFFER;
 
print_hex_dump_debug("PN533 TX: ", DUMP_PREFIX_NONE, 16, 1,
 out->data, out->len, false);
@@ -375,20 +382,26 @@ static int pn533_acr122_poweron_rdr(stru
/* Power on th reader (CCID cmd) */
u8 cmd[10] = {PN533_ACR122_PC_TO_RDR_ICCPOWERON,
  0, 0, 0, 0, 0, 0, 3, 0, 0};
+   char *buffer;
int rc;
void *cntx;
struct pn533_acr122_poweron_rdr_arg arg;
 
dev_dbg(>udev->dev, "%s\n", __func__);
 
+   buffer = kmemdup(cmd, sizeof(cmd), GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
init_completion();
cntx = phy->in_urb->context;  /* backup context */
 
phy->in_urb->complete = pn533_acr122_poweron_rdr_resp;
phy->in_urb->context = 
 
-   phy->out_urb->transfer_buffer = cmd;
+   phy->out_urb->transfer_buffer = buffer;
phy->out_urb->transfer_buffer_length = sizeof(cmd);
+   phy->out_urb->transfer_flags |= URB_FREE_BUFFER;
 
print_hex_dump_debug("ACR122 TX: ", DUMP_PREFIX_NONE, 16, 1,
   cmd, sizeof(cmd), false);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1

2018-05-17 Thread Greg Kroah-Hartman
On Thu, May 17, 2018 at 12:57:49PM -0500, Gustavo A. R. Silva wrote:
> Hi Greg,
> 
> On 05/17/2018 01:51 AM, Greg Kroah-Hartman wrote:
> > On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote:
> > > pdev_nr and rhport can be controlled by user-space, hence leading to
> > > a potential exploitation of the Spectre variant 1 vulnerability.
> > > 
> > > This issue was detected with the help of Smatch:
> > > drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential
> > > spectre issue 'vhcis'
> > > drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential
> > > spectre issue 'vhcis'
> > > drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential
> > > spectre issue 'vhci->vhci_hcd_ss->vdev'
> > > drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential
> > > spectre issue 'vhci->vhci_hcd_hs->vdev'
> > 
> > Nit, no need to line-wrap long error messages from tools :)
> > 
> 
> Got it.
> 
> > > Fix this by sanitizing pdev_nr and rhport before using them to index
> > > vhcis and vhci->vhci_hcd_ss->vdev respectively.
> > > 
> > > Notice that given that speculation windows are large, the policy is
> > > to kill the speculation on the first load and not worry if it can be
> > > completed with a dependent load/store [1].
> > > 
> > > [1] https://marc.info/?l=linux-kernel=152449131114778=2
> > > 
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com>
> > > ---
> > >   drivers/usb/usbip/vhci_sysfs.c | 6 ++
> > >   1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/usb/usbip/vhci_sysfs.c 
> > > b/drivers/usb/usbip/vhci_sysfs.c
> > > index 4880838..9045888 100644
> > > --- a/drivers/usb/usbip/vhci_sysfs.c
> > > +++ b/drivers/usb/usbip/vhci_sysfs.c
> > > @@ -10,6 +10,8 @@
> > >   #include 
> > >   #include 
> > > +#include 
> > > +
> > >   #include "usbip_common.h"
> > >   #include "vhci.h"
> > > @@ -235,6 +237,8 @@ static ssize_t detach_store(struct device *dev, 
> > > struct device_attribute *attr,
> > >   if (!valid_port(pdev_nr, rhport))
> > >   return -EINVAL;
> > > + pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers);
> > > + rhport = array_index_nospec(rhport, VHCI_HC_PORTS);
> > 
> > Shouldn't we just do this in one place, in the valid_port() function?
> > 
> > That way it keeps the range checking logic in one place (now it is in 3
> > places in the function), which should make maintenance much simpler.
> > 
> 
> Yep, I thought about that, the thing is: what happens if the hardware is
> "trained" to predict that valid_port always evaluates to false, and then
> malicious values are stored in pdev_nr and nhport?
> 
> It seems to me that under this scenario we need to serialize instructions in
> this place.
> 
> What do you think?

I don't understand, it should not matter where you put the barrier.  Be
it a function call back or right after it, it does the same thing, it
stops speculation from crossing that barrier.

So it _should_ work either way, if I understand the issue correctly.

If not, what am I missing?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usbip: vhci_sysfs: fix potential Spectre v1

2018-05-17 Thread Greg Kroah-Hartman
On Wed, May 16, 2018 at 05:22:00PM -0500, Gustavo A. R. Silva wrote:
> pdev_nr and rhport can be controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
> 
> This issue was detected with the help of Smatch:
> drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential
> spectre issue 'vhcis'
> drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential
> spectre issue 'vhcis'
> drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential
> spectre issue 'vhci->vhci_hcd_ss->vdev'
> drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential
> spectre issue 'vhci->vhci_hcd_hs->vdev'

Nit, no need to line-wrap long error messages from tools :)

> Fix this by sanitizing pdev_nr and rhport before using them to index
> vhcis and vhci->vhci_hcd_ss->vdev respectively.
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/usb/usbip/vhci_sysfs.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
> index 4880838..9045888 100644
> --- a/drivers/usb/usbip/vhci_sysfs.c
> +++ b/drivers/usb/usbip/vhci_sysfs.c
> @@ -10,6 +10,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "usbip_common.h"
>  #include "vhci.h"
>  
> @@ -235,6 +237,8 @@ static ssize_t detach_store(struct device *dev, struct 
> device_attribute *attr,
>   if (!valid_port(pdev_nr, rhport))
>   return -EINVAL;
>  
> + pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers);
> + rhport = array_index_nospec(rhport, VHCI_HC_PORTS);

Shouldn't we just do this in one place, in the valid_port() function?

That way it keeps the range checking logic in one place (now it is in 3
places in the function), which should make maintenance much simpler.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] USB: serial: use tty_port_register_device()

2018-05-16 Thread Greg Kroah-Hartman
On Wed, May 16, 2018 at 11:42:07AM +0200, Johan Hovold wrote:
> We already have the tty port when probing a usb-serial port so use
> tty_port_register_device() directly instead of tty_port_install() later
> to set up the port link.
> 
> This is a step towards enabling serdev for usb-serial (but we need to
> determine how to handle hotplugging first).
> 
> Signed-off-by: Johan Hovold <jo...@kernel.org>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   3   4   5   6   7   8   9   10   >