Re: [GIT PULL] USB-serial fix for v4.20-rc6
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
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
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
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()
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()
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()
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
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
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
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
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
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()
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
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()
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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()
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
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
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
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
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
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
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
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
On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote: > Signed-off-by: Marcus FolkessonI 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
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
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
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
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
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
On Tue, May 22, 2018 at 01:20:01AM +0300, Andy Shevchenko wrote: > On Mon, May 21, 2018 at 2:57 PM, Yisheng Xiewrote: > > 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
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
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
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
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
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
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
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
, > - 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
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
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
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
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
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
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
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()
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