Re: usb media detection issue on USB_MUSB_HDRC on kernel 3.17
Had some progresses: on kernel 3.17, musb controller driver is set to start as OTG mode as default. So as first thing, since my board has ID pin shorted to ground, i changed the default mode to MUSB_HOST., as it was on kernel 3.5.1 So with same settings of 3.5.1 now key is detected correctly at first insertion, but after a removal, the stick is not detected anymore. Issue seems visible in drivers/usb/musb/da8xx.c, inside irqreturn_t da8xx_musb_interrupt() routine. looking the /sys fs, i see that the mode moves in time order as: |boot: vbus off b_idle|| boot: vbus off a_wait_vrise|| insertion: vbus off a_host| removal:vbus off b_idle After last b_host, the state never moves back to a_wait_vrise. After the removal, the interrupt call irqreturn_t da8xx_musb_interrupt() seems broken and seems never called anymore. Regards. || -- 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 0/1] usb: chipidea fixes for v3.18-rc2
Hi Greg, It is a great bug-fix, it fixed the chipidea loadable module issue from v3.14, thanks Torsten's patch. Torsten Fleischer (1): usb: chipidea: Fix oops when removing the ci_hdrc module drivers/usb/chipidea/core.c |1 - 1 file changed, 1 deletion(-) -- 1.7.9.5 -- 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 1/1] usb: chipidea: Fix oops when removing the ci_hdrc module
From: Torsten Fleischer The call of 'kfree(ci->hw_bank.regmap)' in ci_hdrc_remove() sometimes causes a kernel oops when removing the ci_hdrc module. Since there is no separate memory allocated for the ci->hw_bank.regmap array, there is no need to free it. Cc: v3.14+ Signed-off-by: Torsten Fleischer Signed-off-by: Peter Chen --- drivers/usb/chipidea/core.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 3df5005..9bdc6bd 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -742,7 +742,6 @@ static int ci_hdrc_remove(struct platform_device *pdev) ci_role_destroy(ci); ci_hdrc_enter_lpm(ci, true); usb_phy_shutdown(ci->transceiver); - kfree(ci->hw_bank.regmap); return 0; } -- 1.7.9.5 -- 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 v7 0/3] pxa27x remaing usb serie
Robert Jarzmik writes: > These are the remaining patches from the initial serie. Ping ? Cheers. -- Robert -- 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
usb: gadget: Fixes to receive from USB EHCI Debug
USB gadget driver dbgp can be used as an EHCI debug dongle in replacement for product like Net20DC. With it one can receive early kernel messages from remote targets over USB. See parameter earlyprintk=dbgp for target kernel requirements and configuration. The two patches are required for dbgp gadget driver to work. Longterm plan: I think G_DBGP_PRINTK is an odd hack and could be removed. Exposing the debug descriptor can be implemented in cdc_acm so that we could seemlessly reconfigure endpoint from the 8 byte payload limitation EHCI Debug Port has, to 512 bytes, once ehci-hcd with DMA is available. Handling of the termios CLOCAL flag calls for some discussion and I am not that familiar with the tty infra u_serial uses. See the previous change around gserial_disconnect(): http://permalink.gmane.org/gmane.linux.usb.general/4260 Regards, Kyösti -- 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 2/2] usb: gadget serial: Honour termios CLOCAL on disconnect
There are applications where it is desirable to not hangup ttyGS* when
USB disconnect is detected. USB host side of communication may
power-cycle periodically or there may be the actual need to physically
disconnect and reconnect USB cable temporarily.
USB disconnects on serial gadget are comparable to loss of Carrier Detect
of conventional UARTs. With the change, if ttyGS* has termios CLOCAL flag
set, disconnect on USB does not hangup the TTY.
Signed-off-by: Kyösti Mälkki
---
drivers/usb/gadget/function/u_serial.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index 491082a..e68ffd7 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1254,8 +1254,13 @@ void gserial_disconnect(struct gserial *gser)
gser->ioport = NULL;
if (port->port.count > 0 || port->openclose) {
wake_up_interruptible(&port->drain_wait);
- if (port->port.tty)
- tty_hangup(port->port.tty);
+ struct tty_struct *tty = port->port.tty;
+ if (tty) {
+ if (tty->termios.c_cflag & CLOCAL)
+ stop_tty(tty);
+ else
+ tty_hangup(tty);
+ }
}
spin_unlock_irqrestore(&port->port_lock, flags);
--
1.8.1.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
[PATCH 1/2] usb: gadget dbgp: Fix endpoint config after USB disconnect
SET_FEATURE request for DEBUG_MODE only worked the first time after module
initialisation. On USB host reset or cable disconnect gserial_disconnect()
clears the associations dbgp.serial->in->desc and dbgp_serial->out->desc.
Per the USB 2.0 debug device specification, SET_FEATURE with DEBUG_MODE
is to be treated as if it were a SET_CONFIGURATION request. Redo endpoint
configuration on this request.
Code has assumption that endpoint mapping remains unchanged from what was
previously returned as a GET_DESCRIPTOR DT_DEBUG response.
Signed-off-by: Kyösti Mälkki
---
drivers/usb/gadget/legacy/dbgp.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/legacy/dbgp.c b/drivers/usb/gadget/legacy/dbgp.c
index 1b07513..afb49ef 100644
--- a/drivers/usb/gadget/legacy/dbgp.c
+++ b/drivers/usb/gadget/legacy/dbgp.c
@@ -214,6 +214,7 @@ static void dbgp_disconnect(struct usb_gadget *gadget)
#ifdef CONFIG_USB_G_DBGP_PRINTK
dbgp_disable_ep();
#else
+ dev_dbg(&dbgp.gadget->dev, "disconnected\n");
gserial_disconnect(dbgp.serial);
#endif
}
@@ -237,7 +238,7 @@ static void dbgp_unbind(struct usb_gadget *gadget)
static unsigned char tty_line;
#endif
-static int __init dbgp_configure_endpoints(struct usb_gadget *gadget)
+static int dbgp_configure_endpoints(struct usb_gadget *gadget)
{
int stp;
@@ -273,19 +274,10 @@ static int __init dbgp_configure_endpoints(struct
usb_gadget *gadget)
dbgp.serial->in->desc = &i_desc;
dbgp.serial->out->desc = &o_desc;
-
- if (gserial_alloc_line(&tty_line)) {
- stp = 3;
- goto fail_3;
- }
+#endif
return 0;
-fail_3:
- dbgp.o_ep->driver_data = NULL;
-#else
- return 0;
-#endif
fail_2:
dbgp.i_ep->driver_data = NULL;
fail_1:
@@ -324,10 +316,17 @@ static int __init dbgp_bind(struct usb_gadget *gadget,
err = -ENOMEM;
goto fail;
}
+
+ if (gserial_alloc_line(&tty_line)) {
+ stp = 4;
+ err = -ENODEV;
+ goto fail;
+ }
#endif
+
err = dbgp_configure_endpoints(gadget);
if (err < 0) {
- stp = 4;
+ stp = 5;
goto fail;
}
@@ -379,12 +378,26 @@ static int dbgp_setup(struct usb_gadget *gadget,
err = 0;
} else if (request == USB_REQ_SET_FEATURE &&
value == USB_DEVICE_DEBUG_MODE) {
- dev_dbg(&dbgp.gadget->dev, "setup: feat debug\n");
#ifdef CONFIG_USB_G_DBGP_PRINTK
err = dbgp_enable_ep();
#else
+ if (!(dbgp.serial->in && dbgp.serial->in->desc &&
+ dbgp.serial->out && dbgp.serial->out->desc)) {
+ dev_dbg(&dbgp.gadget->dev, "needs reconfiguration\n");
+ err = dbgp_configure_endpoints(gadget);
+ if (err < 0) {
+ goto fail;
+ }
+ }
+ if (dbgp.serial->in && dbgp.serial->in->desc &&
+ dbgp.serial->out && dbgp.serial->out->desc) {
+ dev_dbg(&dbgp.gadget->dev, "epIn %02x, epOut %02x\n",
+ dbgp.serial->in->desc->bEndpointAddress,
+ dbgp.serial->out->desc->bEndpointAddress);
+ }
err = gserial_connect(dbgp.serial, tty_line);
#endif
+ dev_dbg(&dbgp.gadget->dev, "setup: feat debug (%d)\n", err);
if (err < 0)
goto fail;
} else
--
1.8.1.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
gadgetfs: fops change not preserved on return from dev_config()
Hi Felipe, I'm noticing some strange behaviour in the gadgetfs driver when running gadgetfs-test; the program fails with the error "ep0 read after poll: Invalid argument". As far as I understand, an inode is created upon an open() call in gadgetfs-test and an initial fops is assigned to the struct file that doesn't contain a .read member. The .write member of this first fops points to dev_config() in usb/gadget/legacy/inode.c. When user-space write is called for the first time, dev_config() performs a bunch of configuration stuff before doing "fd->f_op = &ep0_io_operations;". This new file_operations struct does contain a .read member, which points to ep0_read(). I'm confused as to why when an error occurs when a subsequent read() is called in gadgetfs-test. I thought that changes to an fops pointer is preserved upon returning to the user-space caller. How can it be that "fd->f_op = &ep0_io_operations;" clearly changes the fops pointer, yet these changes aren't reflected when returning to user-space? Regards, Andre. -- 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 00/17] usb: gadget: convert udc driver to use udc-core's reset notifier
On Tue, Sep 16, 2014 at 09:26:35PM -0500, Felipe Balbi wrote: > Hi, > > On Wed, Sep 17, 2014 at 09:13:53AM +0800, Peter Chen wrote: > > Hi Felipe, > > > > In this series, I convert udc driver to use udc-core's reset notifier > > which has added recently, I only change the drivers which has > > bus reset handler and call usb_gadget_driver's ->disconnect in it. > > > > For five you and Alan's patches, I cherry-pick them from your > > gadget-add-reset-method branch and change some code and comments > > for using udc-core's reset notifier. > > > > This series is based on yours next tree, and pass the compile test > > and checkpatch.pl. > > > > Alan Stern (3): > > usb: gadget: dummy-hcd: use udc-core's reset notifier > > usb: gadget: net2280: use udc-core's reset notifier > > usb: gadget: net2272: use udc-core's reset notifier > > > > Felipe Balbi (2): > > usb: dwc3: gadget: use udc-core's reset notifier > > usb: musb: gadget: use udc-core's reset notifier > > > > Peter Chen (12): > > usb: chipidea: gadget: use udc-core's reset notifier > > usb: gadget: pxa25x_udc: use udc-core's reset notifier > > usb: gadget: m66592-udc: use udc-core's reset notifier > > usb: gadget: fsl_udc_core: use udc-core's reset notifier > > usb: gadget: at91_udc: use udc-core's reset notifier > > usb: gadget: mv_udc_core: use udc-core's reset notifier > > usb: gadget: fsl_qe_udc: use udc-core's reset notifier > > usb: gadget: pch_udc: use udc-core's reset notifier > > usb: gadget: amd5536udc: use udc-core's reset notifier > > usb: gadget: r8a66597-udc: use udc-core's reset notifier > > usb: gadget: bcm63xx_udc: use udc-core's reset notifier > > usb: gadget: atmel_usba_udc: use udc-core's reset notifier > > thanks, but I'll have to defer this one for v3.19. I already closed my > tree. I'll ask you to resend these once v3.18-rc1 is tagged, until them > I'm dropping them from my queue otherwise I'll go a little nuts. In any > case, this gives people some time to review and ack your patches. > Felipe, is it ok I recend them now? -- Best Regards, Peter Chen -- 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 0/2] ARM: shmobile: add USB3.0 device node on r8a7790
On Fri, Oct 24, 2014 at 07:41:45PM +0900, Yoshihiro Shimoda wrote: > This series is based on Simon's renesas.git branch and > renesas-devel-20141024-v3.18-rc1 tag. If we use the generic phy > driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use > the USB3.0 on lager. Thanks, I have queued these up. > > Changes from v1: > - rebase the repository. > > Yoshihiro Shimoda (2): > ARM: shmobile: r8a7790: add USB3.0 device node > ARM: shmobile: lager: enable USB3.0 > > arch/arm/boot/dts/r8a7790-lager.dts |6 ++ > arch/arm/boot/dts/r8a7790.dtsi | 10 ++ > 2 files changed, 16 insertions(+) > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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 v5 0/2] Add HS-USB device tree support for R8A7790/Lager board
On Fri, Oct 24, 2014 at 07:44:32PM +0900, Yoshihiro Shimoda wrote: > Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, > 'renesas-devel-20141024-v3.18-rc1' tag. Here we add the HS-USB device tree > support on the R8A7790/Lager reference board. The patchset requires the USB > PHY > driver (already merged by Kishon and Greg) and the generic PHY support patches > for the HS-USB driver posted by Yoshihiro Shimoda in order to work... Thanks, I have queued these up. > > Changes from v4: > - rebase the repository. > > Yoshihiro Shimoda (2): > ARM: shmobile: r8a7790: add HS-USB device node > ARM: shmobile: lager: enable HS-USB > > arch/arm/boot/dts/r8a7790-lager.dts | 12 > arch/arm/boot/dts/r8a7790.dtsi | 11 +++ > 2 files changed, 23 insertions(+) > > -- > 1.7.9.5 > -- 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 0/1] ARM: shmobile: add USB3.0 device node on r8a7791
On Fri, Oct 24, 2014 at 07:43:01PM +0900, Yoshihiro Shimoda wrote: > This patch is based on Simon's renesas.git branch and > renesas-devel-20141024-v3.18-rc1 tag. > Since koelsch and henninger doesn't have a USB3.0 connector, > I submit a patch for r8a7791.dtsi only. Thanks, I have queued this up. > > Changes from v1: > - rebase the repository. > > Yoshihiro Shimoda (1): > ARM: shmobile: r8a7791: add USB3.0 device node > > arch/arm/boot/dts/r8a7791.dtsi | 10 ++ > 1 file changed, 10 insertions(+) > > -- > 1.7.9.5 > -- 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 v4 0/3] HS-USB device tree support for R8A7791/Koelsch/Henninger board
On Fri, Oct 24, 2014 at 07:45:05PM +0900, Yoshihiro Shimoda wrote: >Here's the set of 3 patches against Simon Horman's 'renesas.git' repo, > 'renesas-devel-20141024-v3.18-rc1' tag. Here we add the HS-USB device tree > support on the R8A7791/Koelsch/Henninger reference boards. The patchset > requires the USB PHY driver (already merged by Kishon and Greg) and the > generic PHY support patches for the HS-USB driver posted by Yoshihiro Shimoda > in order to work... > > Changes from v3: > - rebase the repository. Thanks, I have queued these up. > > Yoshihiro Shimoda (3): > ARM: shmobile: r8a7791: add HS-USB device node > ARM: shmobile: koelsch: enable HS-USB > ARM: shmobile: henninger: enable HS-USB > > arch/arm/boot/dts/r8a7791-henninger.dts |7 +++ > arch/arm/boot/dts/r8a7791-koelsch.dts |7 +++ > arch/arm/boot/dts/r8a7791.dtsi | 11 +++ > 3 files changed, 25 insertions(+) > > -- > 1.7.9.5 > -- 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 02/16] pci: quirks: add quirk to avoid AMD NL to bind with xhci
On Fri, Oct 24, 2014 at 10:35:29AM -0600, Bjorn Helgaas wrote:
> On Fri, Oct 17, 2014 at 04:53:27PM +0800, Huang Rui wrote:
> > The dwc3 controller is the PCI-E device in AMD NL platform, but the class
> > code
> > of PCI header is 0x0c0330, the same with xHC. That's because it needs to
> > meet
> > the windows enviroment. The dwc3 controller acted as only host mode to bind
> > with
> > windows xhci driver.
> > But on linux, sometimes, it would auto-bind with xhci driver as well (class
> > code
> > 0x0c0330) despite it uses Pid/Vid on dwc3 driver.
>
> This changelog really doesn't make any sense unless the reader already
> knows everything. I think you mean something like this:
>
> The AMD NL (please explain what "NL" is; Google has no clue) SoC contains
> a DesignWare USB3 Dual-Role Device that can be operated either as a USB
> Host or a USB Device. In the AMD NL platform, this device ([1022:7912])
> has a class code of PCI_CLASS_SERIAL_USB_XHCI (0x0c0330), which means the
> xhci driver will claim it.
>
> But the dwc3 driver is a more specific driver for this device, and we'd
> prefer to use it instead of xhci. To prevent xhci from claiming the
> device, change the class code to 0x0c03fe, which the PCI r3.0 spec
> defines as "USB device (not host controller)". The dwc3 driver can then
> claim it based on its Vendor and Device ID.
>
> Obviously, this means the device won't work at all unless dwc3 is enabled.
> Previously, it probably would work as a host controller with the xhci
> driver. I assume this change is what you want.
>
OK, I will update to this changelog in V3.
> > Heikki suggested to use the quirk to fix this issue, and the detailed
> > discussion
> > is at below thread:
> > http://marc.info/?l=linux-usb&m=141197934712824&w=2
>
> This changelog needs to be wrapped so no line is longer than 75 characters.
>
> Please run "git log --oneline --no-merges drivers/pci/quirks.c" and make
> your subject line match the rest. In particular, "PCI" (not "pci"), drop
> the "quirks:" part, and capitalize "Add".
>
I got it, will update subject.
> > Suggested-by: Heikki Krogerus
> > Cc: Bjorn Helgaas
> > Signed-off-by: Huang Rui
> > ---
> > drivers/pci/quirks.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 90acb32..3c911b7 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -378,6 +378,26 @@ static void quirk_ati_exploding_mce(struct pci_dev
> > *dev)
> > }
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_RS100,
> > quirk_ati_exploding_mce);
> >
> > +/* FIXME should define in */
> > +#define PCI_DEVICE_ID_AMD_NL 0x7912
>
> If you KNOW this should be in linux/pci_ids.h (and it looks like it COULD
> go there, since you do use the same definition in patch [01/16]), why don't
> you just do it? Why are you wasting our time reviewing trivial stuff like
> this?
>
Apology, I was told that it could not add device id into pci_ids.h
from my buddy with below thread discussion last year, but I don't
confirm at current. I check the git log at pci_ids.h, it looks like
it's able to add device id marco again, is that right?
http://marc.info/?l=linux-pci&m=137028614924258&w=2
If I misunderstand your meaning, please correct me.
> > +
> > +/*
> > + * AMD NL SoC 7912 PCI device is dwc3 controller, but the class code of PCI
> > + * header is 0x0c0330, the same with xHC. That's because it need to meet
> > the
> > + * windows enviroment. The dwc3 controller acted as only host mode to bind
> > with
> > + * windows xhci driver. But on linux, sometimes, we auto-bind with xhci
> > driver
> > + * as well (class code 0x0c0330) despite we use Pid/Vid on dwc3 driver. So
> > this
> > + * quirk used a dummy class code to avoid to bind with xhci driver at
> > booting
> > + * phase.
> > + */
> > +static void quirk_amd_nl_class(struct pci_dev *pdev)
> > +{
> > + /* Use a dummy class value instead of PCI header provided */
>
> When you say "dummy class value," that makes it sound like you just chose
> a random invalid value. But this value is actually defined by the spec, so
> you should use the description from the spec, namely, "USB device (not host
> controller)".
>
Yes, you're right. Will change this description.
Thanks,
Rui
--
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/11] hwa-hc: Fix probable mask then right shift defect
Precedence of & and >> is not the same and is not left to right. shift has higher precedence and should be done after the mask. Add parentheses around the mask. Signed-off-by: Joe Perches --- drivers/usb/host/hwa-hc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/hwa-hc.c b/drivers/usb/host/hwa-hc.c index d0d8fad..1db0626 100644 --- a/drivers/usb/host/hwa-hc.c +++ b/drivers/usb/host/hwa-hc.c @@ -607,7 +607,7 @@ found: wa->wa_descr = wa_descr = (struct usb_wa_descriptor *) hdr; if (le16_to_cpu(wa_descr->bcdWAVersion) > 0x0100) dev_warn(dev, "Wire Adapter v%d.%d newer than groked v1.0\n", -le16_to_cpu(wa_descr->bcdWAVersion) & 0xff00 >> 8, +(le16_to_cpu(wa_descr->bcdWAVersion) & 0xff00) >> 8, le16_to_cpu(wa_descr->bcdWAVersion) & 0x00ff); result = 0; error: -- 2.1.2 -- 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 00/11] treewide: mask then shift defects and style updates
logical mask has lower precedence than shift but should be done before the shift so parentheses are generally required. And when masking with a fixed value after a shift, normal kernel style has the shift on the left, then the shift on the right so convert a few non-conforming uses. Joe Perches (11): block: nvme-scsi: Fix probable mask then right shift defects radeon: evergreen: Fix probable mask then right shift defects aiptek: Fix probable mask then right shift defects dvb-net: Fix probable mask then right shift defects cx25840/cx18: Use standard ordering of mask and shift wm8350-core: Fix probable mask then right shift defect iwlwifi: dvm: Fix probable mask then right shift defect ssb: driver_chip_comon_pmu: Fix probable mask then right shift defect tty: ipwireless: Fix probable mask then right shift defects hwa-hc: Fix probable mask then right shift defect sound: ad1889: Fix probable mask then right shift defects drivers/block/nvme-scsi.c| 12 ++-- drivers/gpu/drm/radeon/evergreen.c | 3 ++- drivers/input/tablet/aiptek.c| 6 +++--- drivers/media/dvb-core/dvb_net.c | 4 +++- drivers/media/i2c/cx25840/cx25840-core.c | 12 ++-- drivers/media/pci/cx18/cx18-av-core.c| 16 drivers/mfd/wm8350-core.c| 2 +- drivers/net/wireless/iwlwifi/dvm/lib.c | 4 ++-- drivers/ssb/driver_chipcommon_pmu.c | 4 ++-- drivers/tty/ipwireless/hardware.c| 12 ++-- drivers/usb/host/hwa-hc.c| 2 +- sound/pci/ad1889.c | 8 12 files changed, 44 insertions(+), 41 deletions(-) -- 2.1.2 -- 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: function: Fixed the return value on error path
Sebastian, Will push the patch today for the second issue today. Was on Diwali holidays .. :) Cherrs,, Pavitra On Thu, Oct 23, 2014 at 3:48 PM, Sebastian Andrzej Siewior wrote: > On 10/22/2014 04:03 PM, Pavitrakumar Managutte wrote: >> Fixed the return value on failure. status variable >> is set to 0 at usb_assign_descriptors call and the same is >> returned on error which is incorrect. >> >> Signed-off-by: Pavitrakumar Managutte > Acked-by: Sebastian Andrzej Siewior > > I spotted two wrong error paths, this one. Do you look after the second > one? > > Sebastian -- 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
