Re: [PATCH v3 05/19] usb: dwc3: add lpm erratum support
On Tue, Oct 28, 2014 at 10:30:50AM -0600, Bjorn Helgaas wrote: > On Tue, Oct 28, 2014 at 5:54 AM, Huang Rui wrote: > > When parameter DWC_USB3_LPM_ERRATA_ENABLE is enabled in Andvanced > > "Advanced" > > > Configuration of coreConsultant, it supports of xHCI BESL Errata Dated > > I can't parse "is supports of" and I don't know enough to suggest an > alternate wording. > > > 10/19/2011 is enabled in host mode. In device mode it adds the capability > > to send NYET response threshold based on the BESL value received in the LPM > > token, and the threhold is configurable for each soc platform. > > "threshold" > Thanks to reminder. It should be: When parameter DWC_USB3_LPM_ERRATA_ENABLE is enabled in Advanced Configuration of coreConsultant, support of xHCI BESL Errata Dated 10/19/2011 is enabled in host mode. In device mode it adds the capability to send NYET response threshold based on the BESL value received in the LPM token, and the threshold is configurable for each SoC platform. 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
Re: [PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Wed, 29 Oct 2014, Michael Ellerman wrote: > On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote: >> On 10/27/14 06:13, Tomi Valkeinen wrote: >> > I also think the 'depends on BACKLIGHT_CLASS_DEVICE || >> > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds >> > like a hack to me =). >> >> It does exactly what is needed and it is used in many places in kernel >> Kconfig files. > > Is there any reason you can't do: > > depends on BACKLIGHT_CLASS_DEVICE != m That's not the same thing. The FOO || FOO=n allows for all options, but forbids it being a module when the option depending on it is built-in. Obviously something that's built-in can't depend on something built as a module. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- 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
usbserial / ftdi_sio (+ others) bug?
I own a device that implements a data logging interface using the FT232 USB-serial -chip. Very often it happens that connecting the associated software with the device requires multiple attempts. There seems to be two kinds of issues; either the program reports that it did not receive any data or it reports reading lots of data, but it was all invalid. I haven't yet looked at the former, but I did spend some time investigating the latter. Simple strace of the program startup showed that when connecting fails, the program gets a lot (hundreds) of binary zeros while reading the device. I used usbmon to capture the traffic between the host and the device and the zeros are not strictly speaking coming from the device. However when this problem happens the device seems to report quite lot of overruns for a while, which was a clue. After a somewhat successful attempt to understand the operation of the tty code in Linux, I have a theory. The usbserial driver sets the TTY_DRIVER_REAL_RAW flag. Based on the comment in tty_driver.h this implies that the driver is not supposed to report any statuses (including overruns) to ldisc if they are ignored by the application (like they are in this case). It's just that AFAICS the ftdi_sio subdriver (and many others) doesn't seem quite honor this, but seems to report any status unconditionally. Also AFAICS this then means that every overrun will get converted into single binary zero delivered to the application(?). If so, this probably isn't what is supposed to happen and would explain the flood of extraneous zeros the application was seeing when the connecting failed. I haven't had yet the time to test this theory, but at least it seems plausible to me. Any thoughts, anybody? -- 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 3/5] USB: kobil_sct: replace unnecessary atomic allocation
Use GFP_KERNEL instead of GFP_ATOMIC for allocation in open(), which may sleep. Signed-off-by: Johan Hovold --- drivers/usb/serial/kobil_sct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c index 02c420af251e..2363654cafc9 100644 --- a/drivers/usb/serial/kobil_sct.c +++ b/drivers/usb/serial/kobil_sct.c @@ -244,7 +244,7 @@ static int kobil_open(struct tty_struct *tty, struct usb_serial_port *port) priv->device_type == KOBIL_ADAPTER_B_PRODUCT_ID || priv->device_type == KOBIL_KAAN_SIM_PRODUCT_ID) { /* start reading (Adapter B 'cause PNP string) */ - result = usb_submit_urb(port->interrupt_in_urb, GFP_ATOMIC); + result = usb_submit_urb(port->interrupt_in_urb, GFP_KERNEL); dev_dbg(dev, "%s - Send read URB returns: %i\n", __func__, result); } -- 2.0.4 -- 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/5] USB: opticon: fix non-atomic allocation in write path
Write may be called from interrupt context so make sure to use GFP_ATOMIC for all allocations in write. Fixes: 0d930e51cfe6 ("USB: opticon: Add Opticon OPN2001 write support") Cc: stable Signed-off-by: Johan Hovold --- drivers/usb/serial/opticon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c index 4856fb7e637e..4b7bfb394a32 100644 --- a/drivers/usb/serial/opticon.c +++ b/drivers/usb/serial/opticon.c @@ -215,7 +215,7 @@ static int opticon_write(struct tty_struct *tty, struct usb_serial_port *port, /* The connected devices do not have a bulk write endpoint, * to transmit data to de barcode device the control endpoint is used */ - dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_NOIO); + dr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_ATOMIC); if (!dr) { count = -ENOMEM; goto error_no_dr; -- 2.0.4 -- 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/5] USB: kobil_sct: fix non-atomic allocation in write path
Write may be called from interrupt context so make sure to use GFP_ATOMIC for all allocations in write. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold --- drivers/usb/serial/kobil_sct.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c index 3d2bd65df0fc..02c420af251e 100644 --- a/drivers/usb/serial/kobil_sct.c +++ b/drivers/usb/serial/kobil_sct.c @@ -335,7 +335,8 @@ static int kobil_write(struct tty_struct *tty, struct usb_serial_port *port, port->interrupt_out_urb->transfer_buffer_length = length; priv->cur_pos = priv->cur_pos + length; - result = usb_submit_urb(port->interrupt_out_urb, GFP_NOIO); + result = usb_submit_urb(port->interrupt_out_urb, + GFP_ATOMIC); dev_dbg(&port->dev, "%s - Send write URB returns: %i\n", __func__, result); todo = priv->filled - priv->cur_pos; @@ -350,7 +351,7 @@ static int kobil_write(struct tty_struct *tty, struct usb_serial_port *port, if (priv->device_type == KOBIL_ADAPTER_B_PRODUCT_ID || priv->device_type == KOBIL_ADAPTER_K_PRODUCT_ID) { result = usb_submit_urb(port->interrupt_in_urb, - GFP_NOIO); + GFP_ATOMIC); dev_dbg(&port->dev, "%s - Send read URB returns: %i\n", __func__, result); } } -- 2.0.4 -- 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 4/5] USB: mos7720: replace unnecessary atomic allocations
Use GFP_KERNEL instead of GFP_ATOMIC for allocations in set_termios and port-setting helper which both may and do sleep. Signed-off-by: Johan Hovold --- drivers/usb/serial/mos7720.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c index dfd728a263d2..312b0fee8d54 100644 --- a/drivers/usb/serial/mos7720.c +++ b/drivers/usb/serial/mos7720.c @@ -1657,7 +1657,7 @@ static void change_port_settings(struct tty_struct *tty, write_mos_reg(serial, port_number, IER, 0x0c); if (port->read_urb->status != -EINPROGRESS) { - status = usb_submit_urb(port->read_urb, GFP_ATOMIC); + status = usb_submit_urb(port->read_urb, GFP_KERNEL); if (status) dev_dbg(&port->dev, "usb_submit_urb(read bulk) failed, status = %d\n", status); } @@ -1702,7 +1702,7 @@ static void mos7720_set_termios(struct tty_struct *tty, change_port_settings(tty, mos7720_port, old_termios); if (port->read_urb->status != -EINPROGRESS) { - status = usb_submit_urb(port->read_urb, GFP_ATOMIC); + status = usb_submit_urb(port->read_urb, GFP_KERNEL); if (status) dev_dbg(&port->dev, "usb_submit_urb(read bulk) failed, status = %d\n", status); } -- 2.0.4 -- 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 5/5] USB: mos7840: replace unnecessary atomic allocations
Use GFP_KERNEL instead of GFP_ATOMIC for allocations in set_termios and port-setting helper which both may and do sleep. Signed-off-by: Johan Hovold --- drivers/usb/serial/mos7840.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c index 3d88eefdf1d1..220b4be89641 100644 --- a/drivers/usb/serial/mos7840.c +++ b/drivers/usb/serial/mos7840.c @@ -1904,7 +1904,7 @@ static void mos7840_change_port_settings(struct tty_struct *tty, if (mos7840_port->read_urb_busy == false) { mos7840_port->read_urb_busy = true; - status = usb_submit_urb(mos7840_port->read_urb, GFP_ATOMIC); + status = usb_submit_urb(mos7840_port->read_urb, GFP_KERNEL); if (status) { dev_dbg(&port->dev, "usb_submit_urb(read bulk) failed, status = %d\n", status); @@ -1968,7 +1968,7 @@ static void mos7840_set_termios(struct tty_struct *tty, if (mos7840_port->read_urb_busy == false) { mos7840_port->read_urb_busy = true; - status = usb_submit_urb(mos7840_port->read_urb, GFP_ATOMIC); + status = usb_submit_urb(mos7840_port->read_urb, GFP_KERNEL); if (status) { dev_dbg(&port->dev, "usb_submit_urb(read bulk) failed, status = %d\n", status); -- 2.0.4 -- 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 v3 13/19] usb: dwc3: add tx demphasis quirk
On Tue, Oct 28, 2014 at 01:43:03PM -0500, Felipe Balbi wrote: > On Tue, Oct 28, 2014 at 10:27:27AM -0600, Bjorn Helgaas wrote: > > On Tue, Oct 28, 2014 at 5:54 AM, Huang Rui wrote: > > > This patch adds Tx demphasis quirk, and the Tx demphasis value is > > > > "demphasis" (above and in subject) should be "de-emphasis" as used in > > the code and comments below. > > +1 > OK, will update -- 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] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Wed, 2014-10-29 at 09:54 +0200, Jani Nikula wrote: > On Wed, 29 Oct 2014, Michael Ellerman wrote: > > On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote: > >> On 10/27/14 06:13, Tomi Valkeinen wrote: > >> > I also think the 'depends on BACKLIGHT_CLASS_DEVICE || > >> > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds > >> > like a hack to me =). > >> > >> It does exactly what is needed and it is used in many places in kernel > >> Kconfig files. > > > > Is there any reason you can't do: > > > > depends on BACKLIGHT_CLASS_DEVICE != m > > That's not the same thing. The FOO || FOO=n allows for all options, but > forbids it being a module when the option depending on it is > built-in. OK right. Because "BAR depends on FOO" is short for "depends on FOO=y || FOO=m", but also adds the implicit condition that if FOO=m then BAR must also be m. Thanks for clueing me in. cheers -- 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] USB: HWA: fix a warning message
We wanted to print the version as (major).(minor) but because the shift operation is higher precedence than the mask then we print (minor).(minor). Signed-off-by: Dan Carpenter 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: -- 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: usbserial / ftdi_sio (+ others) bug?
[ +CC: Peter, linux-serial ] On Wed, Oct 29, 2014 at 10:07:26AM +0200, Janne Huttunen wrote: > I own a device that implements a data logging interface using the > FT232 USB-serial -chip. Very often it happens that connecting the > associated software with the device requires multiple attempts. > There seems to be two kinds of issues; either the program reports > that it did not receive any data or it reports reading lots of > data, but it was all invalid. I haven't yet looked at the former, > but I did spend some time investigating the latter. > > Simple strace of the program startup showed that when connecting > fails, the program gets a lot (hundreds) of binary zeros while > reading the device. I used usbmon to capture the traffic between > the host and the device and the zeros are not strictly speaking > coming from the device. However when this problem happens the > device seems to report quite lot of overruns for a while, which > was a clue. After a somewhat successful attempt to understand > the operation of the tty code in Linux, I have a theory. > > The usbserial driver sets the TTY_DRIVER_REAL_RAW flag. Based on > the comment in tty_driver.h this implies that the driver is not > supposed to report any statuses (including overruns) to ldisc > if they are ignored by the application (like they are in this > case). It's just that AFAICS the ftdi_sio subdriver (and many > others) doesn't seem quite honor this, but seems to report any > status unconditionally. Also AFAICS this then means that every > overrun will get converted into single binary zero delivered to > the application(?). If so, this probably isn't what is supposed > to happen and would explain the flood of extraneous zeros the > application was seeing when the connecting failed. > > I haven't had yet the time to test this theory, but at least it > seems plausible to me. Any thoughts, anybody? You are correct. The usb-serial drivers, and at least some serial drivers, fail to implement TTY_DRIVER_REAL_RAW correctly in that they do not honour ((IGNBRK || (!BRKINT && !PARMRK)) && (IGNPAR || !INPCK)). I'll take a look at the usb-serial drivers. Having the driver not reporting overrun (and other) errors will obviously not fix the underlying issue with your device, which is generating all these errors in the first place. Thanks, Johan -- 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
[GIT PULL] USB-serial fixes for v3.18-rc3
Hi Greg, Here's a bunch of new device ids and one unused-allocation removal for 3.18. Thanks, Johan The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.18-rc3 for you to fetch changes up to 7f2719f0003da1ad13124ef00f48d7514c79e30d: usb: serial: ftdi_sio: add "bricked" FTDI device PID (2014-10-23 09:52:57 +0200) USB-serial fixes for v3.18-rc3 These updates remove two allocations of unused buffers from kobil_sct and add some new device ids. Signed-off-by: Johan Hovold Dan Williams (1): USB: option: add Haier CE81B CDMA modem Daniele Palmas (1): usb: option: add support for Telit LE910 Frans Klaver (1): usb: serial: ftdi_sio: add Awinda Station and Dongle products Nathaniel Ting (1): USB: serial: cp210x: add Silicon Labs 358x VID and PID Perry Hung (1): usb: serial: ftdi_sio: add "bricked" FTDI device PID Peter Hurley (1): USB: kobil_sct: Remove unused transfer buffer allocs drivers/usb/serial/cp210x.c | 1 + drivers/usb/serial/ftdi_sio.c | 3 +++ drivers/usb/serial/ftdi_sio_ids.h | 12 +++- drivers/usb/serial/kobil_sct.c| 15 --- drivers/usb/serial/option.c | 10 ++ 5 files changed, 25 insertions(+), 16 deletions(-) -- 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 v3 19/19] usb: dwc3: add support for AMD NL platform
Hi Felipe, Paul, On Tue, Oct 28, 2014 at 10:35:37PM +0800, Huang Rui wrote: > On Tue, Oct 28, 2014 at 08:38:56AM -0500, Felipe Balbi wrote: > > > > however, as I mentioned before, the core shouldn't have to know that > > it's running on an AMD platform. We already support several different > > platforms (OMAP5, AM437x, DRA7xx, Exynos5, Exynos7, Qcom, Merrifield, > > Baytrail, Braswell, HAPS PCIe, and STiH407) and none of them get their > > $my_awesome_platform flag in dwc3, why should AMD be any different ? > > > > This is the only part of $subject that I cannot accept because it would > > mean we would be giving AMD a special treatment when there shouldn't be > > any, for anybody. > > > > That's because I used this flag to enable below quirks on AMD NL FPGA > board, and FPGA flag only can be detected on core. Can I set > disable_scramble_quirk, dis_u3_susphy_quirk, and dis_u2_susphy_quirk > for all the FPGA platforms? > > if (dwc->amd_nl_plat && dwc->is_fpga) { > dwc->disable_scramble_quirk = true; > dwc->dis_u3_susphy_quirk = true; > dwc->dis_u2_susphy_quirk = true; > } > I confirmed with HW designer, these three quirks only will be needed on FPGA board. And these should *not* be used on non-FPGA board, as you known. So I would like to use below conditions on dwc3 core. When I set these quirk flags in pci glue layer, then core can filter them by is_fpga flag to support both on FPGA and SoC. Is there any concern? If that, I should remove WARN_ONCE at disable_scramble flag. if (dwc->disable_scramble_quirk && dwc->is_fpga) {..} if (dwc->dis_u2_susphy_quirk && dwc->is_fpga) {..} if (dwc->dis_u3_susphy_quirk && dwc->is_fpga) {..} 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
Re: usbserial / ftdi_sio (+ others) bug?
On Wed, Oct 29, 2014 at 10:51 AM, Johan Hovold wrote: > Having the driver not reporting overrun (and other) errors will > obviously not fix the underlying issue with your device, which is > generating all these errors in the first place. Yes, although that might be related to the other fault I have been seeing where the program reports receiving no data whatsoever. I'll have to take a look at that too when I have the time. -- 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 RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote: [...] > diff --git > a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt > b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt [...] > +Optional properties: > +--- > +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI pad. > +- vddio-hsic-supply: VDDIO regulator for the HSIC pads. > +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the corresponding USB3 > + port is mapped. See for the > list > + of valid values. I dislike how we now need to provide a list of all pins in the header file, where previously we used strings for this. This could become very ugly if the set of pins changes in future generations of this IP block. Could we instead derive this from the pinmux nodes? For example you have this in the example below: usb3p0 { nvidia,lanes = "pcie-0"; ... }; Perhaps what we need is to either key off the node name or add another property, such as: nvidia,usb3-port = <0>; This would match the nvidia,usb2-port property that you've added below. > Lane muxing: > > @@ -50,6 +62,17 @@ Optional properties: >pin or group should be assigned to. Valid values for function names are >listed below. > - nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes) > +- nvidia,usb2-port-num: USB2 port (0, 1, or 2) to which the lane is mapped. I'd leave away the -num suffix since it is implied that it's a number. > +- nvidia,hsic-strobe-trim: HSIC strobe trimmer value. > +- nvidia,hsic-rx-strobe-trim: HSIC RX strobe trimmer value. > +- nvidia,hsic-rx-data-trim: HSIC RX data trimmer value. > +- nvidia,hsic-tx-rtune-n: HSIC TX RTUNEN value. > +- nvidia,hsic-tx-rtune-p: HSIC TX RTUNEP value. > +- nvidia,hsic-tx-slew-n: HSIC TX SLEWN value. > +- nvidia,hsic-tx-slew-p: HSIC TX SLEWP value. It would be useful for these to provide a range of valid values. I also see that there are other registers that contain values for tuning. I take it that the ones you've included here are the only ones that need to be overridden on hardware you've tested this on? That should be fine, we can always add new ones if necessary. > +- nvidia,hsic-auto-term: Enables HSIC AUTO_TERM. (0: no, 1: yes) > +- nvidia,otg-hs-curr-level-offset: Offset to be applied to the pad's fused > + HS_CURR_LEVEL value. > > Note that not all of these properties are valid for all lanes. Lanes can be > divided into three groups: > @@ -58,18 +81,21 @@ divided into three groups: > > Valid functions for this group are: "snps", "xusb", "uart", "rsvd". > > -The nvidia,iddq property does not apply to this group. > +The nvidia,otg-hs-curr-level-offset property only applies. The wording is confusing here in my opinion. Maybe better: "Only the ... property applies."? >- ulpi-0, hsic-0, hsic-1: > > Valid functions for this group are: "snps", "xusb". > > -The nvidia,iddq property does not apply to this group. > +The nvidia,hsic-* properties apply only to the pins hsic-{0,1} when > +the function is xusb. I assume that hsic-* properties also only apply to the hsic-* pins? That's not clear from the above sentence. Thierry pgpPTrR5fvHhp.pgp Description: PGP signature
Re: [PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
On Tue, Oct 28, 2014 at 03:27:52PM -0700, Andrew Bresticker wrote: [...] > diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt > b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt [...] > +- pll_u_480m > +- clk_m > +- pll_e What are these used for? I guess I'll see when I get to the driver patch. > +Optional properties: > + > + - phys: Must contain an entry for each entry in phy-names. > + See ../phy/phy-bindings.txt for details. > + - phy-names: Should include an entry for each PHY used by the controller. > + May be a subset of the following: > +- utmi-{0,1,2} > +- hsic-{0,1} > +- usb3-{0,1} > + - avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply > 1.05V. > + - dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply > 1.05V. > + - avdd-usb-supply: USB controller power supply. Must supply 3.3V. > + - avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8V. > + - avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply > 1.05V. > + - avdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05V. > + - hvdd-pex-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3V. > + - hvdd-pex-plle-supply: High-voltage PLLE power supply. Must supply 3.3V. I think the name for this in the documentation is HVDD_PEX_PLL_E, which would translate to hvdd-pex-pll-e. At least that's how we named this supply for PCIe. Alternatively it seems like there are aliases for the USB 3.0 related supplies: avdd-pex-pll -> avdd-usb-ss-pll hvdd-pex -> hvdd-usb-ss hvdd-pex-pll-e -> hvdd-usb-ss-pll-e So perhaps these could be used for the XHCI driver instead? Also, should these supplies not be mandatory? Thierry pgpKn2YFEiVc5.pgp Description: PGP signature
Re: [PATCH RESEND V4 6/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
On Tue, Oct 28, 2014 at 03:27:53PM -0700, Andrew Bresticker wrote: [...] > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c [...] > +#define TEGRA_XHCI_NUM_SUPPLIES 8 > +static const char *tegra_xhci_supply_names[TEGRA_XHCI_NUM_SUPPLIES] = { > + "avddio-pex", > + "dvddio-pex", > + "avdd-usb", > + "avdd-pll-utmip", > + "avdd-pll-erefe", > + "avdd-pex-pll", > + "hvdd-pex", > + "hvdd-pex-plle", > +}; This could be in a per-SoC structure since it's likely to change in a future SoC. That could be done later on when it really becomes relevant, though. > + > +static const struct { > + const char *name; > + int num; unsigned? > +} tegra_xhci_phy_types[] = { > + { > + .name = "usb3", > + .num = TEGRA_XUSB_USB3_PHYS, > + }, { > + .name = "utmi", > + .num = TEGRA_XUSB_UTMI_PHYS, > + }, { > + .name = "hsic", > + .num = TEGRA_XUSB_HSIC_PHYS, > + }, > +}; Should these constants perhaps be in a per-SoC structure like tegra_xhci_soc_config rather than defined in a global header? > +static int tegra_xhci_load_firmware(struct tegra_xhci_hcd *tegra) > +{ [...] > + /* Start Falcon CPU. */ > + csb_writel(tegra, CPUCTL_STARTCPU, XUSB_FALC_CPUCTL); > + usleep_range(1000, 2000); > + > + fw_time = le32_to_cpu(cfg_tbl->fwimg_created_time); > + time_to_tm(fw_time, 0, &fw_tm); > + dev_info(dev, > + "Firmware timestamp: %ld-%02d-%02d %02d:%02d:%02d UTC, " > + "Falcon state 0x%x\n", fw_tm.tm_year + 1900, > + fw_tm.tm_mon + 1, fw_tm.tm_mday, fw_tm.tm_hour, > + fw_tm.tm_min, fw_tm.tm_sec, > + csb_readl(tegra, XUSB_FALC_CPUCTL)); > + > + /* Make sure Falcon CPU is now running. */ > + if (csb_readl(tegra, XUSB_FALC_CPUCTL) == CPUCTL_STATE_HALTED) > + return -EIO; It seems somewhat strange to output the dev_info() message when in fact it could be that the Falcon wasn't successfully booted. Also is it guaranteed that the Falcon will always be up after 1 ms? Perhaps better would be to use a timed loop? > +static int tegra_xhci_set_ss_clk(struct tegra_xhci_hcd *tegra, > + unsigned long rate) > +{ > + unsigned long new_parent_rate, old_parent_rate; > + int ret, div; > + struct clk *clk = tegra->ss_src_clk; > + > + if (clk_get_rate(clk) == rate) > + return 0; > + > + switch (rate) { > + case TEGRA_XHCI_SS_CLK_HIGH_SPEED: > + /* > + * Reparent to PLLU_480M. Set divider first to avoid > + * overclocking. > + */ > + old_parent_rate = clk_get_rate(clk_get_parent(clk)); > + new_parent_rate = clk_get_rate(tegra->pll_u_480m); > + div = new_parent_rate / rate; > + ret = clk_set_rate(clk, old_parent_rate / div); > + if (ret) > + return ret; > + ret = clk_set_parent(clk, tegra->pll_u_480m); > + if (ret) > + return ret; > + /* > + * The rate should already be correct, but set it again just > + * to be sure. > + */ > + ret = clk_set_rate(clk, rate); > + if (ret) > + return ret; > + break; > + case TEGRA_XHCI_SS_CLK_LOW_SPEED: > + /* Reparent to CLK_M */ > + ret = clk_set_parent(clk, tegra->clk_m); > + if (ret) > + return ret; > + ret = clk_set_rate(clk, rate); > + if (ret) > + return ret; > + break; > + default: > + dev_err(tegra->dev, "Invalid SS rate: %lu\n", rate); > + return -EINVAL; > + } > + > + if (clk_get_rate(clk) != rate) { > + dev_err(tegra->dev, "SS clock doesn't match requested rate\n"); > + return -EINVAL; > + } > + > + return 0; > +} So this is why you need pllu_480m and clk_m clocks. I would've thought it nice to use something like the assigned-clocks properties to take care of this, but it seems like this may actually be required to be updated dynamically at runtime, so a fixed property is not going to be an option. > +static int tegra_xhci_clk_enable(struct tegra_xhci_hcd *tegra) > +{ > + clk_prepare_enable(tegra->pll_e); > + clk_prepare_enable(tegra->host_clk); > + clk_prepare_enable(tegra->ss_clk); > + clk_prepare_enable(tegra->falc_clk); > + clk_prepare_enable(tegra->fs_src_clk); > + clk_prepare_enable(tegra->hs_src_clk); You should error-check these. > +static int tegra_xhci_phy_enable(struct tegra_xhci_hcd *tegra) > +{ > + int ret; > + int i; I prefer unsigned when the value can't be negative as in this case. > + > + for (i = 0; i < ARRAY_SIZE(tegra->phys); i++) { > + ret = phy_init(tegra->phys[
Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0
Hi Magnus-san, (2014/10/29 15:53), Magnus Damm wrote: > On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda > wrote: >> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 >> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: >> >> phy phy-e6590100.usb-phy.3: phy init failed --> -16 >> xhci-hcd: probe of ee00.usb failed with error -16 >> >> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind >> the USB3.0 driver as the following: >> >> echo :02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind >> echo :02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind >> echo ee00.usb > /sys/bus/platform/drivers/xhci-hcd/bind >> >> Note that there will be pinctrl-related error messages if both >> internal PCI and USB3.0 are enabled but they should be just ignored: >> >> sh-pfc e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot >> claim for ee00.usb >> sh-pfc e606.pfc: pin-182 (ee00.usb) status -22 >> ata1: SATA link down (SStatus 0 SControl 300) >> sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2 on >> device sh-pfc >> >> Signed-off-by: Yoshihiro Shimoda >> --- >> arch/arm/boot/dts/r8a7790-lager.dts |6 ++ >> 1 file changed, 6 insertions(+) > > Hi Shimoda-san, > > Thanks for your patch. I'm fine with this patch as a first step, but > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? I investigated this reason today, and I found the reason is request_firmware(). I checked the following environments: Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled The results are: - In "Case 1", EHCI and OHCI are probed first because xHCI didn't find the firmware. - In "Case 2" and "Case 3", xHCI is probed first. > Is the current order just based on device init order? In my mind the > expected behavior would be to always use USB 3.0 if it happens to be > available in the hardware, specified in the DTS, enabled by the kernel > configuration and firmware is loadable. Or does some case exist where > it is better to use USB 2.0? I suspect no. I agree with you. > So I wonder if you have any plans how to make USB 3.0 enabled by > default on Lager? It depends on a kernel config. I'm not sure of the shmobile_defconfig strategy. But, in my opinion, one of a solution is kernel modules (this means the "Case 2".) Best regards, Yoshihiro Shimoda > Thanks, > > / magnus > -- 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 RESEND V4 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Tue, Oct 28, 2014 at 03:27:49PM -0700, Andrew Bresticker wrote: [...] > diff --git a/drivers/mailbox/tegra-xusb-mailbox.c > b/drivers/mailbox/tegra-xusb-mailbox.c [...] > +struct tegra_xusb_mbox { > + struct mbox_controller mbox; > + int irq; It seems like this is unused outside of tegra_xusb_mbox_probe() > +static int tegra_xusb_mbox_send_data(struct mbox_chan *chan, void *data) > +{ > + struct tegra_xusb_mbox *mbox = dev_get_drvdata(chan->mbox->dev); In my opinion, container_of(chan->mbox, struct tegra_xusb_mbox, mbox) would be a slightly more idiomatic way to do this. > + struct tegra_xusb_mbox_msg *msg = data; > + unsigned long flags; > + u32 reg, owner; > + > + dev_dbg(mbox->mbox.dev, "TX message 0x%x:0x%x\n", msg->cmd, msg->data); %#x saves you a character in the format string above. > +static int tegra_xusb_mbox_startup(struct mbox_chan *chan) > +{ > + struct tegra_xusb_mbox *mbox = dev_get_drvdata(chan->mbox->dev); > + int idx = chan - mbox->mbox.chans; unsigned? > + unsigned long flags; > + > + spin_lock_irqsave(&mbox->lock, flags); > + mbox->vchan_allocated[idx] = true; > + spin_unlock_irqrestore(&mbox->lock, flags); The struct mbox_chan has a con_priv field, perhaps that can be used to store virtual channel private data instead of keeping the extra vchan_allocated field in the controller private context? That way you don't wouldn't have to compute an index and use it to index the field in the controller private context. In this particular case I don't think you even need that field, since a channel is requested when the mbox_chan.cl field in non-NULL. > +static struct mbox_chan_ops tegra_xusb_mbox_chan_ops = { I think this really ought to be static const. That would currently still throw a warning because the core doesn't mark the mbox_controller.ops field const, but I think it really should. Now also seems like a good time to make that change because there don't seem to be any users yet. > +static irqreturn_t tegra_xusb_mbox_irq(int irq, void *p) > +{ > + struct tegra_xusb_mbox *mbox = (struct tegra_xusb_mbox *)p; There's no need for the explicit cast here. > + struct tegra_xusb_mbox_msg msg; > + int i; unsigned? > + u32 reg; > + > + spin_lock(&mbox->lock); > + > + /* Clear mbox interrupts */ > + reg = mbox_readl(mbox, XUSB_CFG_ARU_SMI_INTR); > + if (reg & MBOX_SMI_INTR_FW_HANG) > + dev_err(mbox->mbox.dev, "Controller firmware hang\n"); > + mbox_writel(mbox, reg, XUSB_CFG_ARU_SMI_INTR); > + > + reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_DATA_OUT); > + mbox_unpack_msg(reg, &msg); > + > + /* > + * Set the mailbox back to idle. The recipient of the message is > + * responsible for sending an ACK/NAK, if necessary. > + */ > + reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD); > + reg &= ~MBOX_DEST_SMI; > + mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD); > + mbox_writel(mbox, MBOX_OWNER_NONE, XUSB_CFG_ARU_MBOX_OWNER); > + > + dev_dbg(mbox->mbox.dev, "RX message 0x%x:0x%x\n", msg.cmd, msg.data); Again 0x%x -> %#x to save characters. > + for (i = 0; i < ARRAY_SIZE(mbox->vchan_allocated); i++) { > + if (mbox->vchan_allocated[i]) > + mbox_chan_received_data(&mbox->mbox.chans[i], &msg); > + } It seems like the only reason why you need to explicitly check for an allocated channel is that mbox_chan_received_data() would otherwise crash. Are mailbox drivers really supposed to keep track of whether a channel has been requested by a client? Isn't that something that should be done in the core? > +static struct mbox_chan *tegra_xusb_mbox_of_xlate(struct mbox_controller > *ctlr, > + const struct of_phandle_args *sp) > +{ > + struct tegra_xusb_mbox *mbox = dev_get_drvdata(ctlr->dev); container_of()? > + struct mbox_chan *chan = NULL; > + unsigned long flags; > + int i; unsigned? > +static struct of_device_id tegra_xusb_mbox_of_match[] = { static const, please. > +static int tegra_xusb_mbox_probe(struct platform_device *pdev) > +{ > + struct tegra_xusb_mbox *mbox; > + struct resource *res; > + int ret; > + > + mbox = devm_kzalloc(&pdev->dev, sizeof(*mbox), GFP_KERNEL); > + if (!mbox) > + return -ENOMEM; > + platform_set_drvdata(pdev, mbox); > + spin_lock_init(&mbox->lock); > + > + mbox->mbox.dev = &pdev->dev; > + mbox->mbox.chans = devm_kcalloc(&pdev->dev, TEGRA_XUSB_MBOX_NUM_CHANS, > + sizeof(*mbox->mbox.chans), GFP_KERNEL); > + if (!mbox->mbox.chans) > + return -ENOMEM; > + mbox->mbox.num_chans = TEGRA_XUSB_MBOX_NUM_CHANS; > + mbox->mbox.ops = &tegra_xusb_mbox_chan_ops; > + mbox->mbox.txdone_poll = true; > + mbox->mbox.txpoll_period = 0; /* no need to actually poll */ Does the core perhaps need special handling for this? It seems like p
Re: usb media detection issue on USB_MUSB_HDRC on kernel 3.17
Hi all, 2014-10-26 10:10 GMT+01:00 Angelo Dureghello : > 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. > I'll add more information to this thread. Seems MUSB is also broken on OMAP3 boards, booting in OTG mode I'm not able to make it work when a pendrive is connected to the port. Forcing HOST mode I get following messages: [ 13.244567] usb 2-1: new high-speed USB device number 2 using musb-hdrc [ 13.503234] usb 2-1: device v058f p6387 is not supported [ 13.592346] usb usb2-port1: unable to enumerate USB device OTOH the OTG port as gadget works. Regards, Enric -- 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: usbserial / ftdi_sio (+ others) bug?
On 10/29/2014 04:51 AM, Johan Hovold wrote: > [ +CC: Peter, linux-serial ] > > On Wed, Oct 29, 2014 at 10:07:26AM +0200, Janne Huttunen wrote: >> I own a device that implements a data logging interface using the >> FT232 USB-serial -chip. Very often it happens that connecting the >> associated software with the device requires multiple attempts. >> There seems to be two kinds of issues; either the program reports >> that it did not receive any data or it reports reading lots of >> data, but it was all invalid. I haven't yet looked at the former, >> but I did spend some time investigating the latter. >> >> Simple strace of the program startup showed that when connecting >> fails, the program gets a lot (hundreds) of binary zeros while >> reading the device. So you're only getting status and not data. > I used usbmon to capture the traffic between >> the host and the device and the zeros are not strictly speaking >> coming from the device. However when this problem happens the >> device seems to report quite lot of overruns for a while, which >> was a clue. After a somewhat successful attempt to understand >> the operation of the tty code in Linux, I have a theory. >> >> The usbserial driver sets the TTY_DRIVER_REAL_RAW flag. Based on >> the comment in tty_driver.h this implies that the driver is not >> supposed to report any statuses (including overruns) to ldisc >> if they are ignored by the application (like they are in this >> case). It's just that AFAICS the ftdi_sio subdriver (and many >> others) doesn't seem quite honor this, but seems to report any >> status unconditionally. Also AFAICS this then means that every >> overrun will get converted into single binary zero delivered to >> the application(?). If so, this probably isn't what is supposed >> to happen and would explain the flood of extraneous zeros the >> application was seeing when the connecting failed. >> >> I haven't had yet the time to test this theory, but at least it >> seems plausible to me. Any thoughts, anybody? > > You are correct. The usb-serial drivers, and at least some serial > drivers, fail to implement TTY_DRIVER_REAL_RAW correctly in that they > do not honour ((IGNBRK || (!BRKINT && !PARMRK)) && (IGNPAR || !INPCK)). These settings are a constant source of bugs in serial drivers. We really need to abstract the way these settings are processed; even the 8250 driver is getting this wrong. Regards, Peter Hurley -- 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 RESEND V4 4/9] pinctrl: tegra-xusb: Add USB PHY support
On Tue, Oct 28, 2014 at 03:27:51PM -0700, Andrew Bresticker wrote: [...] > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig > index c6a66de..0f4cdef 100644 > --- a/drivers/pinctrl/Kconfig > +++ b/drivers/pinctrl/Kconfig > @@ -163,6 +163,7 @@ config PINCTRL_TEGRA_XUSB > select GENERIC_PHY > select PINCONF > select PINMUX > + select MAILBOX I think this should be a "depends on" because we use the mailbox API as a client rather than a provider. > diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c > b/drivers/pinctrl/pinctrl-tegra-xusb.c [...] > struct tegra_xusb_padctl_function { > const char *name; > const char * const *groups; > @@ -72,6 +222,16 @@ struct tegra_xusb_padctl_soc { > > const struct tegra_xusb_padctl_lane *lanes; > unsigned int num_lanes; > + > + u32 rx_wander; > + u32 rx_eq; > + u32 cdr_cntl; > + u32 dfe_cntl; > + u32 hs_slew; > + u32 ls_rslew[TEGRA_XUSB_UTMI_PHYS]; > + u32 hs_discon_level; > + u32 spare_in; > + int hsic_port_offset; unsigned int? Are these values all SoC-specific or can they vary per board? > +struct tegra_xusb_fuse_calibration { > + u32 hs_curr_level[TEGRA_XUSB_UTMI_PHYS]; > + u32 hs_iref_cap; > + u32 hs_term_range_adj; > + u32 hs_squelch_level; > +}; > + > +struct tegra_xusb_usb3_port { > + int lane; unsigned > + bool context_saved; > + u32 tap1_val; > + u32 amp_val; > + u32 ctle_z_val; > + u32 ctle_g_val; > +}; > + [...] > +static inline bool is_otg_lane(unsigned int lane) > +{ > + return lane >= TEGRA_XUSB_PADCTL_PIN_OTG_0 && > + lane <= TEGRA_XUSB_PADCTL_PIN_OTG_2; > +} > + > +static inline bool is_hsic_lane(unsigned int lane) > +{ > + return lane >= TEGRA_XUSB_PADCTL_PIN_HSIC_0 && > + lane <= TEGRA_XUSB_PADCTL_PIN_HSIC_1; > +} > + > +static inline bool is_pcie_or_sata_lane(unsigned int lane) > +{ > + return lane >= TEGRA_XUSB_PADCTL_PIN_PCIE_0 && > + lane <= TEGRA_XUSB_PADCTL_PIN_SATA_0; > +} > + > +static int lane_to_usb3_port(struct tegra_xusb_padctl *padctl, > + unsigned int lane) > +{ > + int i; unsigned > + > + for (i = 0; i < TEGRA_XUSB_USB3_PHYS; i++) { > + if (padctl->usb3_ports[i].lane == lane) > + return i; > + } > + > + return -1; > +} Why not return a proper error code here that callers can simply propagate? Also, for consistency, I'd prefer the is_*_lane() functions to be renamed to lane_is_*(). > @@ -321,6 +561,7 @@ static int tegra_xusb_padctl_pinconf_group_get(struct > pinctrl_dev *pinctrl, > struct tegra_xusb_padctl *padctl = pinctrl_dev_get_drvdata(pinctrl); > const struct tegra_xusb_padctl_lane *lane; > enum tegra_xusb_padctl_param param; > + int port; > u32 value; The variable here were sorted in inverse christmas tree order, so port should be below value. > +static int usb3_phy_to_port(struct phy *phy) > +{ > + struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy); > + int i; unsigned > + > + for (i = 0; i < TEGRA_XUSB_USB3_PHYS; i++) { > + if (phy == padctl->phys[TEGRA_XUSB_PADCTL_USB3_P0 + i]) > + break; You could simply return i here and then BUG_ON unconditionally. > + } > + BUG_ON(i == TEGRA_XUSB_USB3_PHYS); > + > + return i; > +} Actually, thinking about it some more, perhaps making this a WARN_ON() and returning an error so that we can continue and propagate the error would be more useful. BUG_ON() will completely hang the kernel with no way out but rebooting. WARN_ON() will give a hint about something being wrong and returning an error will allow the kernel to continue to run, which might be the only way to diagnose and fix the problem, even if it means that USB 3.0 support will be disabled. > +static void usb3_phy_save_context(struct tegra_xusb_padctl *padctl, int port) unsigned for port... > +{ > + int lane = padctl->usb3_ports[port].lane; ... and lane. > + u32 value, offset; > + > + padctl->usb3_ports[port].context_saved = true; What's the purpose of saving the context here? This seems to be triggered by a request from XUSB, but it's then restored when the PHY is powered on. How does that even happen? Won't the PHY stay powered all the time? Or shouldn't the context be saved when powering off the PHY? > +static int utmi_phy_to_port(struct phy *phy) > +{ > + struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy); > + int i; > + > + for (i = 0; i < TEGRA_XUSB_UTMI_PHYS; i++) { > + if (phy == padctl->phys[TEGRA_XUSB_PADCTL_UTMI_P0 + i]) > + break; > + } > + BUG_ON(i == TEGRA_XUSB_UTMI_PHYS); > + > + return i; > +} Same comment as before. > +static int utmi_phy_power_on(struct phy *phy) > +{ > + struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy); > + int port = utmi_phy_to_port(phy); > + int
Re: usb media detection issue on USB_MUSB_HDRC on kernel 3.17
Hi Enric On Wed, Oct 29, 2014 at 1:44 PM, Enric Balletbo Serra wrote: > > Hi all, > > 2014-10-26 10:10 GMT+01:00 Angelo Dureghello : > > 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. > > > > I'll add more information to this thread. > > Seems MUSB is also broken on OMAP3 boards, booting in OTG mode I'm not > able to make it work when a pendrive is connected to the port. Forcing > HOST mode I get following messages: > > [ 13.244567] usb 2-1: new high-speed USB device number 2 using musb-hdrc > [ 13.503234] usb 2-1: device v058f p6387 is not supported > [ 13.592346] usb usb2-port1: unable to enumerate USB device > You need to disable CONFIG_USB_OTG_WHITELIST option to avoid this. Or add your device to white list of supported devices. Best regards, Ruslan > OTOH the OTG port as gadget works. > > Regards, >Enric > -- > 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 -- Best regards, Ruslan Bilvol -- 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: [PATCHv6 8/8] usb: dwc2: move usb_disabled() call to host driver only
On 10/28/14, 8:26 PM, Paul Zimmerman wrote: >> From: dingu...@opensource.altera.com [mailto:dingu...@opensource.altera.com] >> Sent: Tuesday, October 28, 2014 4:26 PM >> >> Now that platform.c will get built for both Host and Gadget, if we leave the >> usb_disabled() call in platform.c, it results in the following build error >> when (!USB && USB_GADGET) condition is met. >> >> ERROR: "usb_disabled" [drivers/usb/dwc2/dwc2_platform.ko] undefined! >> >> Since usb_disabled() is mostly used to disable USB host functionality, move >> the call the host portion for the DWC2 driver. >> >> Signed-off-by: Dinh Nguyen >> --- >> drivers/usb/dwc2/hcd.c | 3 +++ >> drivers/usb/dwc2/platform.c | 3 --- >> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c >> index fa49c72..b741997 100644 >> --- a/drivers/usb/dwc2/hcd.c >> +++ b/drivers/usb/dwc2/hcd.c >> @@ -2780,6 +2780,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, >> int i, num_channels; >> int retval; >> >> +if (usb_disabled()) >> +return -ENODEV; >> + >> dev_dbg(hsotg->dev, "DWC OTG HCD INIT\n"); >> >> /* Detect config values from hardware */ >> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c >> index 77c8417..123cf54 100644 >> --- a/drivers/usb/dwc2/platform.c >> +++ b/drivers/usb/dwc2/platform.c >> @@ -157,9 +157,6 @@ static int dwc2_driver_probe(struct platform_device *dev) >> int retval; >> int irq; >> >> -if (usb_disabled()) >> -return -ENODEV; >> - >> match = of_match_device(dwc2_of_match_table, &dev->dev); >> if (match && match->data) { >> params = match->data; > > I'm confused. You are saying the build is broken until patch 8/8 is > applied? As always, that is not acceptable. You need to fix the > breakage at the point where it was introduced, not leave it broken > until the last patch in the series. > The build gets broken when patch 7/8 of is applied. That is the patch that finally allows platform.c to get built for host and gadget. I can fold this patch into patch 7/8. Dinh -- 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 v2] cdc-acm: ensure that termios get set when the port is activated
The driver wasn't properly configuring the hardware for the current termios settings under all conditions. Ensure that termios are written to the device when the port is activated. Signed-off-by: Jim Paris --- Peter Hurley wrote: > Yeah, you're right that the cdc-acm driver isn't properly configuring > the hardware for the current termios settings under all conditions. > > But you don't want to do it for every tty open, only for opens > requiring port initialization, which is what the tty_port->activate() > method is for (ie., acm_port_activate()). I moved it to acm_port_activate(), which works fine. Thanks! acm_tty_set_termios is just moved in this patch, not changed. Jim --- drivers/usb/class/cdc-acm.c | 104 ++-- 1 file changed, 53 insertions(+), 51 deletions(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index e934e19f49f5..24077deb737a 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -504,6 +504,57 @@ static int acm_tty_open(struct tty_struct *tty, struct file *filp) return tty_port_open(&acm->port, tty, filp); } +static void acm_tty_set_termios(struct tty_struct *tty, + struct ktermios *termios_old) +{ + struct acm *acm = tty->driver_data; + struct ktermios *termios = &tty->termios; + struct usb_cdc_line_coding newline; + int newctrl = acm->ctrlout; + + newline.dwDTERate = cpu_to_le32(tty_get_baud_rate(tty)); + newline.bCharFormat = termios->c_cflag & CSTOPB ? 2 : 0; + newline.bParityType = termios->c_cflag & PARENB ? + (termios->c_cflag & PARODD ? 1 : 2) + + (termios->c_cflag & CMSPAR ? 2 : 0) : 0; + switch (termios->c_cflag & CSIZE) { + case CS5: + newline.bDataBits = 5; + break; + case CS6: + newline.bDataBits = 6; + break; + case CS7: + newline.bDataBits = 7; + break; + case CS8: + default: + newline.bDataBits = 8; + break; + } + /* FIXME: Needs to clear unsupported bits in the termios */ + acm->clocal = ((termios->c_cflag & CLOCAL) != 0); + + if (!newline.dwDTERate) { + newline.dwDTERate = acm->line.dwDTERate; + newctrl &= ~ACM_CTRL_DTR; + } else + newctrl |= ACM_CTRL_DTR; + + if (newctrl != acm->ctrlout) + acm_set_control(acm, acm->ctrlout = newctrl); + + if (memcmp(&acm->line, &newline, sizeof newline)) { + memcpy(&acm->line, &newline, sizeof newline); + dev_dbg(&acm->control->dev, "%s - set line: %d %d %d %d\n", + __func__, + le32_to_cpu(newline.dwDTERate), + newline.bCharFormat, newline.bParityType, + newline.bDataBits); + acm_set_line(acm, &acm->line); + } +} + static void acm_port_dtr_rts(struct tty_port *port, int raise) { struct acm *acm = container_of(port, struct acm, port); @@ -554,6 +605,8 @@ static int acm_port_activate(struct tty_port *port, struct tty_struct *tty) goto error_submit_urb; } + acm_tty_set_termios(tty, NULL); + /* * Unthrottle device in case the TTY was closed while throttled. */ @@ -949,57 +1002,6 @@ static int acm_tty_ioctl(struct tty_struct *tty, return rv; } -static void acm_tty_set_termios(struct tty_struct *tty, - struct ktermios *termios_old) -{ - struct acm *acm = tty->driver_data; - struct ktermios *termios = &tty->termios; - struct usb_cdc_line_coding newline; - int newctrl = acm->ctrlout; - - newline.dwDTERate = cpu_to_le32(tty_get_baud_rate(tty)); - newline.bCharFormat = termios->c_cflag & CSTOPB ? 2 : 0; - newline.bParityType = termios->c_cflag & PARENB ? - (termios->c_cflag & PARODD ? 1 : 2) + - (termios->c_cflag & CMSPAR ? 2 : 0) : 0; - switch (termios->c_cflag & CSIZE) { - case CS5: - newline.bDataBits = 5; - break; - case CS6: - newline.bDataBits = 6; - break; - case CS7: - newline.bDataBits = 7; - break; - case CS8: - default: - newline.bDataBits = 8; - break; - } - /* FIXME: Needs to clear unsupported bits in the termios */ - acm->clocal = ((termios->c_cflag & CLOCAL) != 0); - - if (!newline.dwDTERate) { - newline.dwDTERate = acm->line.dwDTERate; - newctrl &= ~ACM_CTRL_DTR; - } else - newctrl |= ACM_CTRL_DTR; - - if (newctrl != acm->ctrlout) - acm_set_
[RFC PATCH v2 0/2] add power manage for dwc2 hcd
This patchset add clock manage and suspend/resume for dwc2. Based on Dinh's patch "usb: dwc2: Add support for dual role". Because the system suspend/resume on my platform still not ready, and the 'suspend' can't be used in power/control node, and the auto suspend seems not work, could anyone told me how to test the usb suspend/resume API easily? Changes in v2: - remove the clock from hcd - adjust the delay time when resume - move all the clock operation into platform Kever Yang (2): usb: dwc2: add bus suspend/resume for dwc2 usb: dwc2: move the clock management from gadget to platform drivers/usb/dwc2/gadget.c | 24 ++- drivers/usb/dwc2/hcd.c | 75 ++--- drivers/usb/dwc2/platform.c | 32 +++ 3 files changed, 86 insertions(+), 45 deletions(-) -- 1.9.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
[RFC PATCH v2 1/2] usb: dwc2: add bus suspend/resume for dwc2
This patch adds suspend/resume for dwc2 hcd controller. Signed-off-by: Kever Yang --- Changes in v2: - remove the clock from hcd - adjust the delay time when resume drivers/usb/dwc2/hcd.c | 75 ++ 1 file changed, 64 insertions(+), 11 deletions(-) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index fa49c72..76984da 100644 --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -1473,6 +1473,30 @@ static void dwc2_port_suspend(struct dwc2_hsotg *hsotg, u16 windex) } } +static void dwc2_port_resume(struct dwc2_hsotg *hsotg) +{ + u32 hprt0; + + /* After clear the Stop PHY clock bit, we should wait for a moment +* for clock stable, but I still didn't know how long it should take. +* I will update it in next version. +*/ + writel(0, hsotg->regs + PCGCTL); + usleep_range(2, 4); + + hprt0 = dwc2_read_hprt0(hsotg); + hprt0 |= HPRT0_RES; + writel(hprt0, hsotg->regs + HPRT0); + hprt0 &= ~HPRT0_SUSP; + /* according to USB2.0 Spec 7.1.7.7, the host most send the resume +* signal for at least 20ms +*/ + usleep_range(2, 25000); + + hprt0 &= ~HPRT0_RES; + writel(hprt0, hsotg->regs + HPRT0); +} + /* Handles hub class-specific requests */ static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq, u16 wvalue, u16 windex, char *buf, u16 wlength) @@ -1518,17 +1542,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq, case USB_PORT_FEAT_SUSPEND: dev_dbg(hsotg->dev, "ClearPortFeature USB_PORT_FEAT_SUSPEND\n"); - writel(0, hsotg->regs + PCGCTL); - usleep_range(2, 4); - - hprt0 = dwc2_read_hprt0(hsotg); - hprt0 |= HPRT0_RES; - writel(hprt0, hsotg->regs + HPRT0); - hprt0 &= ~HPRT0_SUSP; - usleep_range(10, 15); - - hprt0 &= ~HPRT0_RES; - writel(hprt0, hsotg->regs + HPRT0); + dwc2_port_resume(hsotg); break; case USB_PORT_FEAT_POWER: @@ -2301,6 +2315,42 @@ static void _dwc2_hcd_stop(struct usb_hcd *hcd) usleep_range(1000, 3000); } +static int _dwc2_hcd_suspend(struct usb_hcd *hcd) +{ + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd); + u32 hprt0; + + if (hsotg->op_state != OTG_STATE_B_HOST) + return 0; + + if (hsotg->lx_state != DWC2_L0) + return 0; + + hprt0 = dwc2_read_hprt0(hsotg); + if (hprt0 & HPRT0_CONNSTS) + dwc2_port_suspend(hsotg, 1); + + return 0; +} + +static int _dwc2_hcd_resume(struct usb_hcd *hcd) +{ + struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd); + u32 hprt0; + + if (hsotg->op_state != OTG_STATE_B_HOST) + return 0; + + if (hsotg->lx_state != DWC2_L2) + return 0; + + hprt0 = dwc2_read_hprt0(hsotg); + if ((hprt0 | HPRT0_CONNSTS) && (hprt0 | HPRT0_SUSP)) + dwc2_port_resume(hsotg); + + return 0; +} + /* Returns the current frame number */ static int _dwc2_hcd_get_frame_number(struct usb_hcd *hcd) { @@ -2671,6 +2721,9 @@ static struct hc_driver dwc2_hc_driver = { .hub_status_data = _dwc2_hcd_hub_status_data, .hub_control = _dwc2_hcd_hub_control, .clear_tt_buffer_complete = _dwc2_hcd_clear_tt_buffer_complete, + + .bus_suspend = _dwc2_hcd_suspend, + .bus_resume = _dwc2_hcd_resume, }; /* -- 1.9.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
[RFC PATCH v2 2/2] usb: dwc2: move the clock management from gadget to platform
This patch move clock management out of gadget into platform, make both hcd and gadget can use the clock. Signed-off-by: Kever Yang --- Changes in v2: - move all the clock operation into platform drivers/usb/dwc2/gadget.c | 24 ++-- drivers/usb/dwc2/platform.c | 32 2 files changed, 22 insertions(+), 34 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 6ffbfc2..0b108ee 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -2852,8 +2852,6 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget, hsotg->gadget.dev.of_node = hsotg->dev->of_node; hsotg->gadget.speed = USB_SPEED_UNKNOWN; - clk_enable(hsotg->clk); - ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies); if (ret) { @@ -2903,8 +2901,6 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget, regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies); - clk_disable(hsotg->clk); - return 0; } @@ -2936,10 +2932,8 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget, int is_on) spin_lock_irqsave(&hsotg->lock, flags); if (is_on) { s3c_hsotg_phy_enable(hsotg); - clk_enable(hsotg->clk); s3c_hsotg_core_init(hsotg); } else { - clk_disable(hsotg->clk); s3c_hsotg_phy_disable(hsotg); } @@ -3408,20 +3402,12 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq) hsotg->phyif = GUSBCFG_PHYIF8; } - hsotg->clk = devm_clk_get(dev, "otg"); - if (IS_ERR(hsotg->clk)) { - dev_err(dev, "cannot get otg clock\n"); - return PTR_ERR(hsotg->clk); - } - hsotg->gadget.max_speed = USB_SPEED_HIGH; hsotg->gadget.ops = &s3c_hsotg_gadget_ops; hsotg->gadget.name = dev_name(dev); /* reset the system */ - clk_prepare_enable(hsotg->clk); - /* regulators */ for (i = 0; i < ARRAY_SIZE(hsotg->supplies); i++) @@ -3431,7 +3417,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq) hsotg->supplies); if (ret) { dev_err(dev, "failed to request supplies: %d\n", ret); - goto err_clk; + goto out; } ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies), @@ -3510,9 +3496,7 @@ err_ep_mem: kfree(eps); err_supplies: s3c_hsotg_phy_disable(hsotg); -err_clk: - clk_disable_unprepare(hsotg->clk); - +out: return ret; } EXPORT_SYMBOL_GPL(dwc2_gadget_init); @@ -3532,8 +3516,6 @@ int s3c_hsotg_remove(struct dwc2_hsotg *hsotg) usb_gadget_unregister_driver(hsotg->driver); } - clk_disable_unprepare(hsotg->clk); - return 0; } EXPORT_SYMBOL_GPL(s3c_hsotg_remove); @@ -3560,7 +3542,6 @@ int s3c_hsotg_suspend(struct dwc2_hsotg *hsotg) ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies); - clk_disable(hsotg->clk); } return ret; @@ -3576,7 +3557,6 @@ int s3c_hsotg_resume(struct dwc2_hsotg *hsotg) dev_info(hsotg->dev, "resuming usb gadget %s\n", hsotg->driver->driver.name); - clk_enable(hsotg->clk); ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies); } diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c index 77c8417..356e378 100644 --- a/drivers/usb/dwc2/platform.c +++ b/drivers/usb/dwc2/platform.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include @@ -122,6 +123,7 @@ static int dwc2_driver_remove(struct platform_device *dev) dwc2_hcd_remove(hsotg); s3c_hsotg_remove(hsotg); + clk_disable_unprepare(hsotg->clk); return 0; } @@ -216,24 +218,28 @@ static int dwc2_driver_probe(struct platform_device *dev) hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node); spin_lock_init(&hsotg->lock); - retval = dwc2_gadget_init(hsotg, irq); - if (retval) { - /* -* We will not fail the driver initialization for dual-role -* if no clock node is supplied. However, all gadget -* functionality will be disabled if a clock node is not -* provided. Host functionality will continue. -* TO-DO: make clock node a requirement for the HCD. -*/ - if (!IS_ERR(hsotg->clk)) - return retval; + hsotg->clk = devm_clk_get(hsotg->dev, "otg"); + if (IS_ERR(hsotg->clk)) { + dev_err(dev, "cannot
Re: [PATCH v3 19/19] usb: dwc3: add support for AMD NL platform
On Wed, Oct 29, 2014 at 05:13:43PM +0800, Huang Rui wrote: > Hi Felipe, Paul, > > On Tue, Oct 28, 2014 at 10:35:37PM +0800, Huang Rui wrote: > > On Tue, Oct 28, 2014 at 08:38:56AM -0500, Felipe Balbi wrote: > > > > > > > > > however, as I mentioned before, the core shouldn't have to know that > > > it's running on an AMD platform. We already support several different > > > platforms (OMAP5, AM437x, DRA7xx, Exynos5, Exynos7, Qcom, Merrifield, > > > Baytrail, Braswell, HAPS PCIe, and STiH407) and none of them get their > > > $my_awesome_platform flag in dwc3, why should AMD be any different ? > > > > > > This is the only part of $subject that I cannot accept because it would > > > mean we would be giving AMD a special treatment when there shouldn't be > > > any, for anybody. > > > > > > > That's because I used this flag to enable below quirks on AMD NL FPGA > > board, and FPGA flag only can be detected on core. Can I set > > disable_scramble_quirk, dis_u3_susphy_quirk, and dis_u2_susphy_quirk > > for all the FPGA platforms? > > > > if (dwc->amd_nl_plat && dwc->is_fpga) { > > dwc->disable_scramble_quirk = true; > > dwc->dis_u3_susphy_quirk = true; > > dwc->dis_u2_susphy_quirk = true; > > } > > > > I confirmed with HW designer, these three quirks only will be needed > on FPGA board. And these should *not* be used on non-FPGA board, as you > known. > > So I would like to use below conditions on dwc3 core. When I set these > quirk flags in pci glue layer, then core can filter them by is_fpga > flag to support both on FPGA and SoC. Is there any concern? If that, I > should remove WARN_ONCE at disable_scramble flag. > > if (dwc->disable_scramble_quirk && dwc->is_fpga) {..} > > if (dwc->dis_u2_susphy_quirk && dwc->is_fpga) {..} > > if (dwc->dis_u3_susphy_quirk && dwc->is_fpga) {..} the problem is that somebody might need this on non-FPGA. Currently, only AMD needs these and only on FPGA, but you never know. I guess we can add it like this for now and once we have a real AMD product, we drop FPGA support from AMD. cheers -- balbi signature.asc Description: Digital signature
[PATCH v2] usb: dwc3: gadget: WARN() on bogus usb_ep_queue()
Some gadget/function drivers might want to do improper request recycling by allocating a single request from one particular endpoint and queueing it to another completely unrelated endpoint. One such case was found with f_loopback.c. To prevent such cases from happening again, let's WARN() so we get a loud enough failure and persuade users to report errors. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 12f4284..20e4ee9 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1140,8 +1140,14 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request, if (!dep->endpoint.desc) { dev_dbg(dwc->dev, "trying to queue request %p to disabled %s\n", request, ep->name); - spin_unlock_irqrestore(&dwc->lock, flags); - return -ESHUTDOWN; + ret = -ESHUTDOWN; + goto out; + } + + if (WARN(req->dep != dep, "request %p belongs to '%s'\n", + request, req->dep->name)) { + ret = -EINVAL; + goto out; } dev_vdbg(dwc->dev, "queing request %p to %s length %d\n", @@ -1149,6 +1155,8 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request, trace_dwc3_ep_queue(req); ret = __dwc3_gadget_ep_queue(dep, req); + +out: spin_unlock_irqrestore(&dwc->lock, flags); return ret; -- 2.1.0.GIT -- 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] usb: gadget: fix ptr_ret.cocci warnings
drivers/usb/gadget/udc/r8a66597-udc.c:1849:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci Signed-off-by: Fengguang Wu --- r8a66597-udc.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/usb/gadget/udc/r8a66597-udc.c +++ b/drivers/usb/gadget/udc/r8a66597-udc.c @@ -1846,10 +1846,7 @@ static int r8a66597_sudmac_ioremap(struc res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "sudmac"); r8a66597->sudmac_reg = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(r8a66597->sudmac_reg)) - return PTR_ERR(r8a66597->sudmac_reg); - - return 0; + return PTR_ERR_OR_ZERO(r8a66597->sudmac_reg); } static int r8a66597_probe(struct platform_device *pdev) -- 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 v3 19/19] usb: dwc3: add support for AMD NL platform
On Wed, Oct 29, 2014 at 09:11:46AM -0500, Felipe Balbi wrote: > On Wed, Oct 29, 2014 at 05:13:43PM +0800, Huang Rui wrote: > > Hi Felipe, Paul, > > > > On Tue, Oct 28, 2014 at 10:35:37PM +0800, Huang Rui wrote: > > > On Tue, Oct 28, 2014 at 08:38:56AM -0500, Felipe Balbi wrote: > > > > > > > > > > > > > > however, as I mentioned before, the core shouldn't have to know that > > > > it's running on an AMD platform. We already support several different > > > > platforms (OMAP5, AM437x, DRA7xx, Exynos5, Exynos7, Qcom, Merrifield, > > > > Baytrail, Braswell, HAPS PCIe, and STiH407) and none of them get their > > > > $my_awesome_platform flag in dwc3, why should AMD be any different ? > > > > > > > > This is the only part of $subject that I cannot accept because it would > > > > mean we would be giving AMD a special treatment when there shouldn't be > > > > any, for anybody. > > > > > > > > > > That's because I used this flag to enable below quirks on AMD NL FPGA > > > board, and FPGA flag only can be detected on core. Can I set > > > disable_scramble_quirk, dis_u3_susphy_quirk, and dis_u2_susphy_quirk > > > for all the FPGA platforms? > > > > > > if (dwc->amd_nl_plat && dwc->is_fpga) { > > > dwc->disable_scramble_quirk = true; > > > dwc->dis_u3_susphy_quirk = true; > > > dwc->dis_u2_susphy_quirk = true; > > > } > > > > > > > I confirmed with HW designer, these three quirks only will be needed > > on FPGA board. And these should *not* be used on non-FPGA board, as you > > known. > > > > So I would like to use below conditions on dwc3 core. When I set these > > quirk flags in pci glue layer, then core can filter them by is_fpga > > flag to support both on FPGA and SoC. Is there any concern? If that, I > > should remove WARN_ONCE at disable_scramble flag. > > > > if (dwc->disable_scramble_quirk && dwc->is_fpga) {..} > > > > if (dwc->dis_u2_susphy_quirk && dwc->is_fpga) {..} > > > > if (dwc->dis_u3_susphy_quirk && dwc->is_fpga) {..} > > the problem is that somebody might need this on non-FPGA. Currently, > only AMD needs these and only on FPGA, but you never know. > > I guess we can add it like this for now and once we have a real AMD > product, we drop FPGA support from AMD. > OK, agree. Then I comments below WARN_ONCE, OK? /* FIXME it should be used after AMD NL product taps out */ #if 0 WARN_ONCE(dwc->disable_scramble_quirk && !dwc->is_fpga, "disable_scramble cannot be used on non-FPGA builds\n"); #endif 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
Re: differing sector sizes between USB enclosures.
On Tue, 28 Oct 2014, Alan Stern wrote: > On Tue, 28 Oct 2014, Dave Jones wrote: > > > > I had a USB2 enclosure that I put a disk into and used for a few years. > > It reports my 3TB drive like so.. > > ... > > sd 11:0:0:0: [sdc] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB) > > sd 11:0:0:0: [sdc] Attached SCSI disk > > > > The difference in sector size reporting means it can't read the partition > > table. > > Is this a bug, or a hardware flaw ? > > It's probably neither one, but a difference in the way the two > enclosures buffer their data. It's hard to imagine how an enclosure > could claim to use 512-byte sectors if the drive itself had 4-KB > sectors, but the reverse is entirely possible. I wouldn't say the difference is related to the two enclosures buffer their data as such. For 512-byte-sector drives larger than 2TB, the MBR partitioning scheme can't be used because there are more than 2^32 sectors. That's not a huge problem for recent operating systems which understand GPT, but Windows XP and other older OSes (including Linux kernels I assume) won't be happy with it. The solution that some enclosures use, is to tell the host that the drive sector size is 4096 bytes, and the number of sectors is correspondingly reduced by a factor of 8. Then MBR partitioning works fine, so you can use the drive with older OSes. The SATA<->USB bridge chip firmware handles translating read/write requests. If the host requests, say, ten sectors starting at sector 1234, the enclosure firmware translates that to eighty 512-byte sectors starting at sector 9872 when it talks to the drive. You could investigate whether alternative firmware is available for your new enclosure, which doesn't emulate 4096-byte sectors. Some manufacturers have two versions available, with and without emulation. [A quick Google search suggests there is generic ASMedia firmware and a Windows firmware update tool.] Another advantage of emulating 4096-byte sectors relates to so-called "Advanced Format" drives. Most larger-than-2TB drives are Advanced Format. The drive's physical sector size is 4096 bytes, but for compatibility reasons the drive emulates having 512-byte sectors. If partitions are not aligned to a multiple of 8 (512 byte emulated) sectors, write performance can be badly reduced since for every write the drive has to read-modify-write to update partially-written 4096-byte sectors. With an enclosure that emulates 4096-byte sectors, misaligned accesses never occur; all drive reads and writes are aligned to an exact multiple of eight 512-byte sectors. Mark -- 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 v3 19/19] usb: dwc3: add support for AMD NL platform
On Wed, Oct 29, 2014 at 10:33:19PM +0800, Huang Rui wrote: > On Wed, Oct 29, 2014 at 09:11:46AM -0500, Felipe Balbi wrote: > > On Wed, Oct 29, 2014 at 05:13:43PM +0800, Huang Rui wrote: > > > Hi Felipe, Paul, > > > > > > On Tue, Oct 28, 2014 at 10:35:37PM +0800, Huang Rui wrote: > > > > On Tue, Oct 28, 2014 at 08:38:56AM -0500, Felipe Balbi wrote: > > > > > > > > > > > > > > > > > > > however, as I mentioned before, the core shouldn't have to know that > > > > > it's running on an AMD platform. We already support several different > > > > > platforms (OMAP5, AM437x, DRA7xx, Exynos5, Exynos7, Qcom, Merrifield, > > > > > Baytrail, Braswell, HAPS PCIe, and STiH407) and none of them get their > > > > > $my_awesome_platform flag in dwc3, why should AMD be any different ? > > > > > > > > > > This is the only part of $subject that I cannot accept because it > > > > > would > > > > > mean we would be giving AMD a special treatment when there shouldn't > > > > > be > > > > > any, for anybody. > > > > > > > > > > > > > That's because I used this flag to enable below quirks on AMD NL FPGA > > > > board, and FPGA flag only can be detected on core. Can I set > > > > disable_scramble_quirk, dis_u3_susphy_quirk, and dis_u2_susphy_quirk > > > > for all the FPGA platforms? > > > > > > > > if (dwc->amd_nl_plat && dwc->is_fpga) { > > > > dwc->disable_scramble_quirk = true; > > > > dwc->dis_u3_susphy_quirk = true; > > > > dwc->dis_u2_susphy_quirk = true; > > > > } > > > > > > > > > > I confirmed with HW designer, these three quirks only will be needed > > > on FPGA board. And these should *not* be used on non-FPGA board, as you > > > known. > > > > > > So I would like to use below conditions on dwc3 core. When I set these > > > quirk flags in pci glue layer, then core can filter them by is_fpga > > > flag to support both on FPGA and SoC. Is there any concern? If that, I > > > should remove WARN_ONCE at disable_scramble flag. > > > > > > if (dwc->disable_scramble_quirk && dwc->is_fpga) {..} > > > > > > if (dwc->dis_u2_susphy_quirk && dwc->is_fpga) {..} > > > > > > if (dwc->dis_u3_susphy_quirk && dwc->is_fpga) {..} > > > > the problem is that somebody might need this on non-FPGA. Currently, > > only AMD needs these and only on FPGA, but you never know. > > > > I guess we can add it like this for now and once we have a real AMD > > product, we drop FPGA support from AMD. > > > > OK, agree. > > Then I comments below WARN_ONCE, OK? > > /* FIXME it should be used after AMD NL product taps out */ > #if 0 > WARN_ONCE(dwc->disable_scramble_quirk && !dwc->is_fpga, > "disable_scramble cannot be used on non-FPGA builds\n"); > #endif just remove it, we don't like commented out code. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] cdc-acm: ensure that termios get set when the port is activated
On Wed, Oct 29, 2014 at 09:43:41AM -0400, Jim Paris wrote: > The driver wasn't properly configuring the hardware for the current > termios settings under all conditions. Ensure that termios are > written to the device when the port is activated. > > Signed-off-by: Jim Paris > --- > > Peter Hurley wrote: > > Yeah, you're right that the cdc-acm driver isn't properly configuring > > the hardware for the current termios settings under all conditions. > > > > But you don't want to do it for every tty open, only for opens > > requiring port initialization, which is what the tty_port->activate() > > method is for (ie., acm_port_activate()). > > I moved it to acm_port_activate(), which works fine. Thanks! > acm_tty_set_termios is just moved in this patch, not changed. Don't do that. Use a prototype instead of moving. > Jim > > --- > drivers/usb/class/cdc-acm.c | 104 > ++-- > 1 file changed, 53 insertions(+), 51 deletions(-) > > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c > index e934e19f49f5..24077deb737a 100644 > --- a/drivers/usb/class/cdc-acm.c > +++ b/drivers/usb/class/cdc-acm.c > @@ -504,6 +504,57 @@ static int acm_tty_open(struct tty_struct *tty, struct > file *filp) > return tty_port_open(&acm->port, tty, filp); > } > > +static void acm_tty_set_termios(struct tty_struct *tty, > + struct ktermios *termios_old) > +{ > + struct acm *acm = tty->driver_data; > + struct ktermios *termios = &tty->termios; > + struct usb_cdc_line_coding newline; > + int newctrl = acm->ctrlout; > + > + newline.dwDTERate = cpu_to_le32(tty_get_baud_rate(tty)); > + newline.bCharFormat = termios->c_cflag & CSTOPB ? 2 : 0; > + newline.bParityType = termios->c_cflag & PARENB ? > + (termios->c_cflag & PARODD ? 1 : 2) + > + (termios->c_cflag & CMSPAR ? 2 : 0) : 0; > + switch (termios->c_cflag & CSIZE) { > + case CS5: > + newline.bDataBits = 5; > + break; > + case CS6: > + newline.bDataBits = 6; > + break; > + case CS7: > + newline.bDataBits = 7; > + break; > + case CS8: > + default: > + newline.bDataBits = 8; > + break; > + } > + /* FIXME: Needs to clear unsupported bits in the termios */ > + acm->clocal = ((termios->c_cflag & CLOCAL) != 0); > + > + if (!newline.dwDTERate) { > + newline.dwDTERate = acm->line.dwDTERate; > + newctrl &= ~ACM_CTRL_DTR; > + } else > + newctrl |= ACM_CTRL_DTR; > + > + if (newctrl != acm->ctrlout) > + acm_set_control(acm, acm->ctrlout = newctrl); > + > + if (memcmp(&acm->line, &newline, sizeof newline)) { > + memcpy(&acm->line, &newline, sizeof newline); > + dev_dbg(&acm->control->dev, "%s - set line: %d %d %d %d\n", > + __func__, > + le32_to_cpu(newline.dwDTERate), > + newline.bCharFormat, newline.bParityType, > + newline.bDataBits); > + acm_set_line(acm, &acm->line); > + } > +} > + > static void acm_port_dtr_rts(struct tty_port *port, int raise) > { > struct acm *acm = container_of(port, struct acm, port); > @@ -554,6 +605,8 @@ static int acm_port_activate(struct tty_port *port, > struct tty_struct *tty) > goto error_submit_urb; > } > > + acm_tty_set_termios(tty, NULL); > + Using set_termios this way also has the side-effect of raising DTR (when baudrate != B0). This is currently not done until after the port has been fully opened (by .dtr_rts). This is actually a bug in set_termios which should only raise DTR on transitions from B0. I'll fix this separately. > /* >* Unthrottle device in case the TTY was closed while throttled. >*/ > @@ -949,57 +1002,6 @@ static int acm_tty_ioctl(struct tty_struct *tty, > return rv; > } Johan -- 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] USB: cdc-acm: only raise DTR on transitions from B0
Make sure to only raise DTR on transitions from B0 in set_termios. Also allow set_termios to be called from open with a termios_old of NULL. Note that DTR will not be raised prematurely in this case. Signed-off-by: Johan Hovold --- drivers/usb/class/cdc-acm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index e934e19f49f5..7e58bbfd6319 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -980,11 +980,12 @@ static void acm_tty_set_termios(struct tty_struct *tty, /* FIXME: Needs to clear unsupported bits in the termios */ acm->clocal = ((termios->c_cflag & CLOCAL) != 0); - if (!newline.dwDTERate) { + if (C_BAUD(tty) == B0) { newline.dwDTERate = acm->line.dwDTERate; newctrl &= ~ACM_CTRL_DTR; - } else + } else if (termios_old && (termios_old->c_cflag & CBAUD) == B0) { newctrl |= ACM_CTRL_DTR; + } if (newctrl != acm->ctrlout) acm_set_control(acm, acm->ctrlout = newctrl); -- 2.0.4 -- 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: cdc-acm: only raise DTR on transitions from B0
On Wed, Oct 29, 2014 at 04:30:40PM +0100, Johan Hovold wrote: > Make sure to only raise DTR on transitions from B0 in set_termios. > > Also allow set_termios to be called from open with a termios_old of > NULL. Note that DTR will not be raised prematurely in this case. > > Signed-off-by: Johan Hovold > --- > drivers/usb/class/cdc-acm.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c > index e934e19f49f5..7e58bbfd6319 100644 > --- a/drivers/usb/class/cdc-acm.c > +++ b/drivers/usb/class/cdc-acm.c > @@ -980,11 +980,12 @@ static void acm_tty_set_termios(struct tty_struct *tty, > /* FIXME: Needs to clear unsupported bits in the termios */ > acm->clocal = ((termios->c_cflag & CLOCAL) != 0); > > - if (!newline.dwDTERate) { > + if (C_BAUD(tty) == B0) { > newline.dwDTERate = acm->line.dwDTERate; > newctrl &= ~ACM_CTRL_DTR; > - } else > + } else if (termios_old && (termios_old->c_cflag & CBAUD) == B0) { > newctrl |= ACM_CTRL_DTR; > + } > > if (newctrl != acm->ctrlout) > acm_set_control(acm, acm->ctrlout = newctrl); This should go to older kernels as well, right? -- 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 usb 01/32] host: ehci-atmel: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-atmel.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c index ec9f7b7..56a8850 100644 --- a/drivers/usb/host/ehci-atmel.c +++ b/drivers/usb/host/ehci-atmel.c @@ -107,22 +107,15 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev) } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, - "Found HC with no register addr. Check %s setup!\n", - dev_name(&pdev->dev)); - retval = -ENODEV; - goto fail_request_resource; - } - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto fail_request_resource; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); + iclk = devm_clk_get(&pdev->dev, "ehci_clk"); if (IS_ERR(iclk)) { dev_err(&pdev->dev, "Error getting interface clock\n"); -- 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 usb 00/32] cleanup on resource check
This series removes the duplication of sanity check for platform_get_resource() return resource. It will be checked with devm_ioremap_resource() This series based on usb/master. Varka Bhadram (32): host: ehci-atmel: remove duplicate check on resource host: ehci-exynos: remove duplicate check on resource host: ehci-fsl: remove duplicate check on resource dwc3: core: remove duplicate check on resource dwc3: dwc3-keystone: remove duplicate check on resource renesas_usbhs: common: remove duplicate check on resource phy: phy-rcar-usb: remove duplicate check on resource musb: musb_dsps: remove duplicate check on resource musb: musb_core: remove duplicate check on resource host: xhci-plat: remove duplicate check on resource host: uhci-platform: remove duplicate check on resource host: ohci-st: remove duplicate check on resource host: ohci-spear: remove duplicate check on resource host: ehci-sh: remove duplicate check on resource host: ohci-pxa27x: remove duplicate check on resource host: ohci-platform: remove duplicate check on resource host: ohci-octeon: remove duplicate check on resource host: ohci-jz4740: remove duplicate check on resource host: ohci-exynos: remove duplicate check on resource host: ohci-da8xx: remove duplicate check on resource host: ohci-at91: remove duplicate check on resource host: ehci-w90x900: remove duplicate check on resource host: ehci-tegra: remove duplicate check on resource host: ehci-st: remove duplicate check on resource host: ehci-spear: remove duplicate check on resource host: ehci-sead3: remove duplicate check on resource host: ehci-platform: remove duplicate check on resource host: ehci-orion: remove duplicate check on resource host: ehci-octeon: remove duplicate check on resource host: ehci-mxc: remove duplicate check on resource host: ehci-mv: remove duplicate check on resource host: ehci-msm: remove duplicate check on resource drivers/usb/dwc3/core.c| 19 +++ drivers/usb/dwc3/dwc3-keystone.c |5 - drivers/usb/host/ehci-atmel.c | 13 +++-- drivers/usb/host/ehci-exynos.c | 11 +++ drivers/usb/host/ehci-fsl.c| 12 +++- drivers/usb/host/ehci-msm.c| 10 ++ drivers/usb/host/ehci-mv.c | 12 drivers/usb/host/ehci-mxc.c| 11 ++- drivers/usb/host/ehci-octeon.c | 12 +++- drivers/usb/host/ehci-orion.c | 10 +- drivers/usb/host/ehci-platform.c | 12 drivers/usb/host/ehci-sead3.c |5 ++--- drivers/usb/host/ehci-sh.c | 15 +++ drivers/usb/host/ehci-spear.c |9 ++--- drivers/usb/host/ehci-st.c | 12 drivers/usb/host/ehci-tegra.c | 10 +++--- drivers/usb/host/ehci-w90x900.c| 13 +++-- drivers/usb/host/ohci-at91.c | 11 +++ drivers/usb/host/ohci-da8xx.c |7 ++- drivers/usb/host/ohci-exynos.c | 10 ++ drivers/usb/host/ohci-jz4740.c | 13 +++-- drivers/usb/host/ohci-octeon.c | 12 +++- drivers/usb/host/ohci-platform.c | 13 - drivers/usb/host/ohci-pxa27x.c | 11 ++- drivers/usb/host/ohci-spear.c | 11 +++ drivers/usb/host/ohci-st.c | 13 - drivers/usb/host/uhci-platform.c |7 --- drivers/usb/host/xhci-plat.c | 10 -- drivers/usb/musb/musb_core.c |4 ++-- drivers/usb/musb/musb_dsps.c |3 --- drivers/usb/phy/phy-rcar-usb.c |8 +++- drivers/usb/renesas_usbhs/common.c |3 ++- 32 files changed, 86 insertions(+), 241 deletions(-) -- 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 usb 02/32] host: ehci-exynos: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-exynos.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index 7189f2e..c2777d2 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -188,20 +188,15 @@ skip_phy: goto fail_clk; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, "Failed to get I/O memory\n"); - err = -ENXIO; - goto fail_io; - } - - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto fail_io; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); + irq = platform_get_irq(pdev, 0); if (!irq) { dev_err(&pdev->dev, "Failed to get IRQ\n"); -- 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 usb 05/32] dwc3: dwc3-keystone: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/dwc3/dwc3-keystone.c |5 - 1 file changed, 5 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c index 7ec8495..dd8d2df 100644 --- a/drivers/usb/dwc3/dwc3-keystone.c +++ b/drivers/usb/dwc3/dwc3-keystone.c @@ -104,11 +104,6 @@ static int kdwc3_probe(struct platform_device *pdev) kdwc->dev = dev; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(dev, "missing usbss resource\n"); - return -EINVAL; - } - kdwc->usbss = devm_ioremap_resource(dev, res); if (IS_ERR(kdwc->usbss)) return PTR_ERR(kdwc->usbss); -- 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 usb 03/32] host: ehci-fsl: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-fsl.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index 2d2ae8d..fb7bd0c 100644 --- a/drivers/usb/host/ehci-fsl.c +++ b/drivers/usb/host/ehci-fsl.c @@ -93,21 +93,15 @@ static int usb_hcd_fsl_probe(const struct hc_driver *driver, } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, - "Found HC with no register addr. Check %s setup!\n", - dev_name(&pdev->dev)); - retval = -ENODEV; - goto err2; - } - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto err2; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); + pdata->regs = hcd->regs; if (pdata->power_budget) -- 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 usb 06/32] renesas_usbhs: common: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/renesas_usbhs/common.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index b3b6813..3ffd552 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -497,8 +497,9 @@ static int usbhs_probe(struct platform_device *pdev) /* platform data */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); - if (!res || !irq_res) { + if (!irq_res) { dev_err(&pdev->dev, "Not enough Renesas USB platform resources.\n"); return -ENODEV; } -- 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 usb 11/32] host: uhci-platform: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Also fix in accessing NULL if resource didn't get. Signed-off-by: Varka Bhadram --- drivers/usb/host/uhci-platform.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c index b987f1d..081330c 100644 --- a/drivers/usb/host/uhci-platform.c +++ b/drivers/usb/host/uhci-platform.c @@ -86,14 +86,15 @@ static int uhci_hcd_platform_probe(struct platform_device *pdev) return -ENOMEM; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto err_rmr; } + + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); + uhci = hcd_to_uhci(hcd); uhci->regs = hcd->regs; -- 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 usb 09/32] musb: musb_core: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/musb/musb_core.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index b841ee0..55ebd4b 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2080,10 +2080,10 @@ static int musb_probe(struct platform_device *pdev) struct resource *iomem; void __iomem*base; - iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!iomem || irq <= 0) + if (irq <= 0) return -ENODEV; + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0); base = devm_ioremap_resource(dev, iomem); if (IS_ERR(base)) return PTR_ERR(base); -- 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 usb 10/32] host: xhci-plat: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/xhci-plat.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 3d78b0c..e68b4ec 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -83,9 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev) if (irq < 0) return -ENODEV; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) - return -ENODEV; if (of_device_is_compatible(pdev->dev.of_node, "marvell,armada-375-xhci") || @@ -109,15 +106,16 @@ static int xhci_plat_probe(struct platform_device *pdev) if (!hcd) return -ENOMEM; - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto put_hcd; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); + /* * Not all platforms have a clk so it is not an error if the * clock does not exists. -- 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 usb 04/32] dwc3: core: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/dwc3/core.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index b0f4d52..c9ccac9 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -655,10 +655,13 @@ static int dwc3_probe(struct platform_device *pdev) dwc->xhci_resources[1].name = res->name; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(dev, "missing memory resource\n"); - return -ENODEV; - } + /* +* Request memory region but exclude xHCI regs, +* since it will be requested by the xhci-plat driver. +*/ + regs = devm_ioremap_resource(dev, res); + if (IS_ERR(regs)) + return PTR_ERR(regs); dwc->xhci_resources[0].start = res->start; dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + @@ -668,14 +671,6 @@ static int dwc3_probe(struct platform_device *pdev) res->start += DWC3_GLOBALS_REGS_START; - /* -* Request memory region but exclude xHCI regs, -* since it will be requested by the xhci-plat driver. -*/ - regs = devm_ioremap_resource(dev, res); - if (IS_ERR(regs)) - return PTR_ERR(regs); - dwc->regs = regs; dwc->regs_size = resource_size(res); /* -- 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 usb 07/32] phy: phy-rcar-usb: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/phy/phy-rcar-usb.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/usb/phy/phy-rcar-usb.c b/drivers/usb/phy/phy-rcar-usb.c index 33265a5..e9f3a93 100644 --- a/drivers/usb/phy/phy-rcar-usb.c +++ b/drivers/usb/phy/phy-rcar-usb.c @@ -195,11 +195,9 @@ static int rcar_usb_phy_probe(struct platform_device *pdev) return PTR_ERR(reg0); res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); - if (res1) { - reg1 = devm_ioremap_resource(dev, res1); - if (IS_ERR(reg1)) - return PTR_ERR(reg1); - } + reg1 = devm_ioremap_resource(dev, res1); + if (IS_ERR(reg1)) + return PTR_ERR(reg1); priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) { -- 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 usb 08/32] musb: musb_dsps: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/musb/musb_dsps.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 154bcf1..cce99e1 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -447,9 +447,6 @@ static int dsps_musb_init(struct musb *musb) int ret; r = platform_get_resource_byname(parent, IORESOURCE_MEM, "control"); - if (!r) - return -EINVAL; - reg_base = devm_ioremap_resource(dev, r); if (IS_ERR(reg_base)) return PTR_ERR(reg_base); -- 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 usb 12/32] host: ohci-st: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-st.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ohci-st.c b/drivers/usb/host/ohci-st.c index df9028e..e93a2ae 100644 --- a/drivers/usb/host/ohci-st.c +++ b/drivers/usb/host/ohci-st.c @@ -147,12 +147,6 @@ static int st_ohci_platform_probe(struct platform_device *dev) return irq; } - res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); - if (!res_mem) { - dev_err(&dev->dev, "no memory resource provided"); - return -ENXIO; - } - hcd = usb_create_hcd(&ohci_platform_hc_driver, &dev->dev, dev_name(&dev->dev)); if (!hcd) @@ -206,14 +200,15 @@ static int st_ohci_platform_probe(struct platform_device *dev) goto err_power; } - hcd->rsrc_start = res_mem->start; - hcd->rsrc_len = resource_size(res_mem); - + res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&dev->dev, res_mem); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto err_power; } + hcd->rsrc_start = res_mem->start; + hcd->rsrc_len = resource_size(res_mem); + err = usb_add_hcd(hcd, irq, IRQF_SHARED); if (err) goto err_power; -- 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 usb 22/32] host: ehci-w90x900: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-w90x900.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/usb/host/ehci-w90x900.c b/drivers/usb/host/ehci-w90x900.c index a9303af..4717bf2 100644 --- a/drivers/usb/host/ehci-w90x900.c +++ b/drivers/usb/host/ehci-w90x900.c @@ -42,27 +42,20 @@ static int usb_w90x900_probe(const struct hc_driver *driver, int retval = 0, irq; unsigned long val; - - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - retval = -ENXIO; - goto err1; - } - hcd = usb_create_hcd(driver, &pdev->dev, "w90x900 EHCI"); if (!hcd) { retval = -ENOMEM; goto err1; } - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto err2; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); ehci = hcd_to_ehci(hcd); ehci->caps = hcd->regs; -- 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] USB: cdc-acm: only raise DTR on transitions from B0
On Wed, Oct 29, 2014 at 11:56:02PM +0800, Greg Kroah-Hartman wrote: > On Wed, Oct 29, 2014 at 04:30:40PM +0100, Johan Hovold wrote: > > Make sure to only raise DTR on transitions from B0 in set_termios. > > > > Also allow set_termios to be called from open with a termios_old of > > NULL. Note that DTR will not be raised prematurely in this case. > > > > Signed-off-by: Johan Hovold > > --- > > drivers/usb/class/cdc-acm.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c > > index e934e19f49f5..7e58bbfd6319 100644 > > --- a/drivers/usb/class/cdc-acm.c > > +++ b/drivers/usb/class/cdc-acm.c > > @@ -980,11 +980,12 @@ static void acm_tty_set_termios(struct tty_struct > > *tty, > > /* FIXME: Needs to clear unsupported bits in the termios */ > > acm->clocal = ((termios->c_cflag & CLOCAL) != 0); > > > > - if (!newline.dwDTERate) { > > + if (C_BAUD(tty) == B0) { > > newline.dwDTERate = acm->line.dwDTERate; > > newctrl &= ~ACM_CTRL_DTR; > > - } else > > + } else if (termios_old && (termios_old->c_cflag & CBAUD) == B0) { > > newctrl |= ACM_CTRL_DTR; > > + } > > > > if (newctrl != acm->ctrlout) > > acm_set_control(acm, acm->ctrlout = newctrl); > > This should go to older kernels as well, right? Yes, if you want. It's fixing handling of B0, but I doubt many people care (hence the missing stable tag). Note that set_termios is currently not called during open() (but Jim's patch will be relying on this one). Johan -- 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 usb 17/32] host: ohci-octeon: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-octeon.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ohci-octeon.c b/drivers/usb/host/ohci-octeon.c index 15af895..20d861b 100644 --- a/drivers/usb/host/ohci-octeon.c +++ b/drivers/usb/host/ohci-octeon.c @@ -120,12 +120,6 @@ static int ohci_octeon_drv_probe(struct platform_device *pdev) return -ENODEV; } - res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (res_mem == NULL) { - dev_err(&pdev->dev, "No register space assigned\n"); - return -ENODEV; - } - /* Ohci is a 32-bit device. */ ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); if (ret) @@ -135,14 +129,14 @@ static int ohci_octeon_drv_probe(struct platform_device *pdev) if (!hcd) return -ENOMEM; - hcd->rsrc_start = res_mem->start; - hcd->rsrc_len = resource_size(res_mem); - + res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); reg_base = devm_ioremap_resource(&pdev->dev, res_mem); if (IS_ERR(reg_base)) { ret = PTR_ERR(reg_base); goto err1; } + hcd->rsrc_start = res_mem->start; + hcd->rsrc_len = resource_size(res_mem); ohci_octeon_hw_start(); -- 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 usb 14/32] host: ehci-sh: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-sh.c | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/usb/host/ehci-sh.c b/drivers/usb/host/ehci-sh.c index 9b9b9f5..4b2c3a7 100644 --- a/drivers/usb/host/ehci-sh.c +++ b/drivers/usb/host/ehci-sh.c @@ -86,15 +86,6 @@ static int ehci_hcd_sh_probe(struct platform_device *pdev) if (usb_disabled()) return -ENODEV; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, - "Found HC with no register addr. Check %s setup!\n", - dev_name(&pdev->dev)); - ret = -ENODEV; - goto fail_create_hcd; - } - irq = platform_get_irq(pdev, 0); if (irq <= 0) { dev_err(&pdev->dev, @@ -114,14 +105,14 @@ static int ehci_hcd_sh_probe(struct platform_device *pdev) goto fail_create_hcd; } - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto fail_request_resource; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); priv = devm_kzalloc(&pdev->dev, sizeof(struct ehci_sh_priv), GFP_KERNEL); -- 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 usb 15/32] host: ohci-pxa27x: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-pxa27x.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c index e68f3d0..1339981 100644 --- a/drivers/usb/host/ohci-pxa27x.c +++ b/drivers/usb/host/ohci-pxa27x.c @@ -447,20 +447,13 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver, struct platform_device return -ENOMEM; r = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!r) { - pr_err("no resource of IORESOURCE_MEM"); - retval = -ENXIO; - goto err; - } - - hcd->rsrc_start = r->start; - hcd->rsrc_len = resource_size(r); - hcd->regs = devm_ioremap_resource(&pdev->dev, r); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto err; } + hcd->rsrc_start = r->start; + hcd->rsrc_len = resource_size(r); /* initialize "struct pxa27x_ohci" */ pxa_ohci = to_pxa27x_ohci(hcd); -- 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 usb 20/32] host: ohci-da8xx: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-da8xx.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c index df06be6..1c76999 100644 --- a/drivers/usb/host/ohci-da8xx.c +++ b/drivers/usb/host/ohci-da8xx.c @@ -313,16 +313,13 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver, return -ENOMEM; mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!mem) - return -ENODEV; - hcd->rsrc_start = mem->start; - hcd->rsrc_len = resource_size(mem); - hcd->regs = devm_ioremap_resource(&pdev->dev, mem); if (IS_ERR(hcd->regs)) { error = PTR_ERR(hcd->regs); goto err; } + hcd->rsrc_start = mem->start; + hcd->rsrc_len = resource_size(mem); ohci_hcd_init(hcd_to_ohci(hcd)); -- 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 usb 27/32] host: ehci-platform: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-platform.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index 2f5b9ce..d6cbd61 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -164,11 +164,6 @@ static int ehci_platform_probe(struct platform_device *dev) dev_err(&dev->dev, "no irq provided"); return irq; } - res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); - if (!res_mem) { - dev_err(&dev->dev, "no memory resource provided"); - return -ENXIO; - } hcd = usb_create_hcd(&ehci_platform_hc_driver, &dev->dev, dev_name(&dev->dev)); @@ -250,14 +245,15 @@ static int ehci_platform_probe(struct platform_device *dev) goto err_reset; } - hcd->rsrc_start = res_mem->start; - hcd->rsrc_len = resource_size(res_mem); - + res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&dev->dev, res_mem); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto err_power; } + hcd->rsrc_start = res_mem->start; + hcd->rsrc_len = resource_size(res_mem); + err = usb_add_hcd(hcd, irq, IRQF_SHARED); if (err) goto err_power; -- 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 usb 13/32] host: ohci-spear: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-spear.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c index 8d58766..4a54f9d 100644 --- a/drivers/usb/host/ohci-spear.c +++ b/drivers/usb/host/ohci-spear.c @@ -74,20 +74,15 @@ static int spear_ohci_hcd_drv_probe(struct platform_device *pdev) } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - retval = -ENODEV; - goto err_put_hcd; - } - - hcd->rsrc_start = pdev->resource[0].start; - hcd->rsrc_len = resource_size(res); - hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto err_put_hcd; } + hcd->rsrc_start = pdev->resource[0].start; + hcd->rsrc_len = resource_size(res); + sohci_p = to_spear_ohci(hcd); sohci_p->clk = usbh_clk; -- 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 usb 24/32] host: ehci-st: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-st.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ehci-st.c b/drivers/usb/host/ehci-st.c index 7e4bd39..4c12cd1 100644 --- a/drivers/usb/host/ehci-st.c +++ b/drivers/usb/host/ehci-st.c @@ -170,11 +170,6 @@ static int st_ehci_platform_probe(struct platform_device *dev) dev_err(&dev->dev, "no irq provided"); return irq; } - res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); - if (!res_mem) { - dev_err(&dev->dev, "no memory resource provided"); - return -ENXIO; - } hcd = usb_create_hcd(&ehci_platform_hc_driver, &dev->dev, dev_name(&dev->dev)); @@ -233,15 +228,16 @@ static int st_ehci_platform_probe(struct platform_device *dev) goto err_put_clks; } - hcd->rsrc_start = res_mem->start; - hcd->rsrc_len = resource_size(res_mem); - + res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&dev->dev, res_mem); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto err_put_clks; } + hcd->rsrc_start = res_mem->start; + hcd->rsrc_len = resource_size(res_mem); + err = usb_add_hcd(hcd, irq, IRQF_SHARED); if (err) goto err_put_clks; -- 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 usb 23/32] host: ehci-tegra: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-tegra.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c index aaa0197..eb36b7a 100644 --- a/drivers/usb/host/ehci-tegra.c +++ b/drivers/usb/host/ehci-tegra.c @@ -460,18 +460,14 @@ static int tegra_ehci_probe(struct platform_device *pdev) "nvidia,needs-double-reset"); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, "Failed to get I/O memory\n"); - err = -ENXIO; - goto cleanup_clk_en; - } - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto cleanup_clk_en; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); + ehci->caps = hcd->regs + 0x100; ehci->has_hostpc = soc_config->has_hostpc; -- 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 usb 30/32] host: ehci-mxc: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-mxc.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c index dbe5e4e..c7a9b31 100644 --- a/drivers/usb/host/ehci-mxc.c +++ b/drivers/usb/host/ehci-mxc.c @@ -69,20 +69,13 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev) return -ENOMEM; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(dev, "Found HC with no register addr. Check setup!\n"); - ret = -ENODEV; - goto err_alloc; - } - - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto err_alloc; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); hcd->has_tt = 1; ehci = hcd_to_ehci(hcd); -- 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 usb 32/32] host: ehci-msm: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-msm.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c index 9dc2118..9db74ca 100644 --- a/drivers/usb/host/ehci-msm.c +++ b/drivers/usb/host/ehci-msm.c @@ -88,19 +88,13 @@ static int ehci_msm_probe(struct platform_device *pdev) } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, "Unable to get memory resource\n"); - ret = -ENODEV; - goto put_hcd; - } - - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto put_hcd; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); /* * OTG driver takes care of PHY initialization, clock management, -- 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 usb 25/32] host: ehci-spear: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-spear.c |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c index 1355ff0..34e1474 100644 --- a/drivers/usb/host/ehci-spear.c +++ b/drivers/usb/host/ehci-spear.c @@ -99,18 +99,13 @@ static int spear_ehci_hcd_drv_probe(struct platform_device *pdev) } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - retval = -ENODEV; - goto err_put_hcd; - } - - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto err_put_hcd; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); sehci = to_spear_ehci(hcd); sehci->clk = usbh_clk; -- 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 usb 18/32] host: ohci-jz4740: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-jz4740.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/usb/host/ohci-jz4740.c b/drivers/usb/host/ohci-jz4740.c index c2c221a..8ddd8f5 100644 --- a/drivers/usb/host/ohci-jz4740.c +++ b/drivers/usb/host/ohci-jz4740.c @@ -153,13 +153,6 @@ static int jz4740_ohci_probe(struct platform_device *pdev) struct resource *res; int irq; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - - if (!res) { - dev_err(&pdev->dev, "Failed to get platform resource\n"); - return -ENOENT; - } - irq = platform_get_irq(pdev, 0); if (irq < 0) { dev_err(&pdev->dev, "Failed to get platform irq\n"); @@ -174,14 +167,14 @@ static int jz4740_ohci_probe(struct platform_device *pdev) jz4740_ohci = hcd_to_jz4740_hcd(hcd); - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto err_free; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); jz4740_ohci->clk = devm_clk_get(&pdev->dev, "uhc"); if (IS_ERR(jz4740_ohci->clk)) { -- 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 usb 28/32] host: ehci-orion: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-orion.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c index 22e15ca..36b4657 100644 --- a/drivers/usb/host/ehci-orion.c +++ b/drivers/usb/host/ehci-orion.c @@ -175,15 +175,6 @@ static int ehci_orion_drv_probe(struct platform_device *pdev) goto err; } - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, - "Found HC with no register addr. Check %s setup!\n", - dev_name(&pdev->dev)); - err = -ENODEV; - goto err; - } - /* * Right now device-tree probed devices don't get dma_mask * set. Since shared usb code relies on it, set it here for @@ -193,6 +184,7 @@ static int ehci_orion_drv_probe(struct platform_device *pdev) if (err) goto err; + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(regs)) { err = PTR_ERR(regs); -- 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 usb 26/32] host: ehci-sead3: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-sead3.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-sead3.c b/drivers/usb/host/ehci-sead3.c index cf12676..9b6e8d0 100644 --- a/drivers/usb/host/ehci-sead3.c +++ b/drivers/usb/host/ehci-sead3.c @@ -110,14 +110,13 @@ static int ehci_hcd_sead3_drv_probe(struct platform_device *pdev) return -ENOMEM; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); - hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto err1; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); /* Root hub has integrated TT. */ hcd->has_tt = 1; -- 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 usb 31/32] host: ehci-mv: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-mv.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c index 08147c3..62797eb 100644 --- a/drivers/usb/host/ehci-mv.c +++ b/drivers/usb/host/ehci-mv.c @@ -170,12 +170,6 @@ static int mv_ehci_probe(struct platform_device *pdev) } r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phyregs"); - if (r == NULL) { - dev_err(&pdev->dev, "no phy I/O memory resource defined\n"); - retval = -ENODEV; - goto err_put_hcd; - } - ehci_mv->phy_regs = devm_ioremap_resource(&pdev->dev, r); if (IS_ERR(ehci_mv->phy_regs)) { retval = PTR_ERR(ehci_mv->phy_regs); @@ -183,12 +177,6 @@ static int mv_ehci_probe(struct platform_device *pdev) } r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "capregs"); - if (!r) { - dev_err(&pdev->dev, "no I/O memory resource defined\n"); - retval = -ENODEV; - goto err_put_hcd; - } - ehci_mv->cap_regs = devm_ioremap_resource(&pdev->dev, r); if (IS_ERR(ehci_mv->cap_regs)) { retval = PTR_ERR(ehci_mv->cap_regs); -- 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 usb 29/32] host: ehci-octeon: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ehci-octeon.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ehci-octeon.c b/drivers/usb/host/ehci-octeon.c index 9051439..2d0c4bc 100644 --- a/drivers/usb/host/ehci-octeon.c +++ b/drivers/usb/host/ehci-octeon.c @@ -106,12 +106,6 @@ static int ehci_octeon_drv_probe(struct platform_device *pdev) return -ENODEV; } - res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (res_mem == NULL) { - dev_err(&pdev->dev, "No register space assigned\n"); - return -ENODEV; - } - /* * We can DMA from anywhere. But the descriptors must be in * the lower 4GB. @@ -125,14 +119,14 @@ static int ehci_octeon_drv_probe(struct platform_device *pdev) if (!hcd) return -ENOMEM; - hcd->rsrc_start = res_mem->start; - hcd->rsrc_len = resource_size(res_mem); - + res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&pdev->dev, res_mem); if (IS_ERR(hcd->regs)) { ret = PTR_ERR(hcd->regs); goto err1; } + hcd->rsrc_start = res_mem->start; + hcd->rsrc_len = resource_size(res_mem); ehci_octeon_start(); -- 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 usb 16/32] host: ohci-platform: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-platform.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c index 4369299..6c7f74b 100644 --- a/drivers/usb/host/ohci-platform.c +++ b/drivers/usb/host/ohci-platform.c @@ -149,12 +149,6 @@ static int ohci_platform_probe(struct platform_device *dev) return irq; } - res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); - if (!res_mem) { - dev_err(&dev->dev, "no memory resource provided"); - return -ENXIO; - } - hcd = usb_create_hcd(&ohci_platform_hc_driver, &dev->dev, dev_name(&dev->dev)); if (!hcd) @@ -236,14 +230,15 @@ static int ohci_platform_probe(struct platform_device *dev) goto err_reset; } - hcd->rsrc_start = res_mem->start; - hcd->rsrc_len = resource_size(res_mem); - + res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(&dev->dev, res_mem); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto err_power; } + hcd->rsrc_start = res_mem->start; + hcd->rsrc_len = resource_size(res_mem); + err = usb_add_hcd(hcd, irq, IRQF_SHARED); if (err) goto err_power; -- 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 usb 19/32] host: ohci-exynos: remove duplicate check on resource
From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-exynos.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index d28b658..f601952 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -156,19 +156,13 @@ skip_phy: goto fail_clk; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_err(&pdev->dev, "Failed to get I/O memory\n"); - err = -ENXIO; - goto fail_io; - } - - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); hcd->regs = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(hcd->regs)) { err = PTR_ERR(hcd->regs); goto fail_io; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); irq = platform_get_irq(pdev, 0); if (!irq) { -- 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 usb 21/32] host: ohci-at91: remove duplicate check on resource
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/host/ohci-at91.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index e49eb4f..90666ea 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -137,12 +137,6 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver, struct resource *res; int irq; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) { - dev_dbg(dev, "hcd probe: missing memory resource\n"); - return -ENXIO; - } - irq = platform_get_irq(pdev, 0); if (irq < 0) { dev_dbg(dev, "hcd probe: missing irq resource\n"); @@ -152,14 +146,15 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver, hcd = usb_create_hcd(driver, dev, "at91"); if (!hcd) return -ENOMEM; - hcd->rsrc_start = res->start; - hcd->rsrc_len = resource_size(res); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); hcd->regs = devm_ioremap_resource(dev, res); if (IS_ERR(hcd->regs)) { retval = PTR_ERR(hcd->regs); goto err; } + hcd->rsrc_start = res->start; + hcd->rsrc_len = resource_size(res); iclk = devm_clk_get(dev, "ohci_clk"); if (IS_ERR(iclk)) { -- 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: [GIT PULL] USB-serial fixes for v3.18-rc3
On Wed, Oct 29, 2014 at 10:11:41AM +0100, Johan Hovold wrote: > Hi Greg, > > Here's a bunch of new device ids and one unused-allocation removal for > 3.18. > > Thanks, > Johan > > > The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: > > Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-3.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 RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
On Wed, Oct 29, 2014 at 2:43 AM, Thierry Reding wrote: > On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote: > [...] >> diff --git >> a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt >> b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt > [...] >> +Optional properties: >> +--- >> +- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI pad. >> +- vddio-hsic-supply: VDDIO regulator for the HSIC pads. >> +- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the corresponding >> USB3 >> + port is mapped. See for the >> list >> + of valid values. > > I dislike how we now need to provide a list of all pins in the header > file, where previously we used strings for this. This could become very > ugly if the set of pins changes in future generations of this IP block. > > Could we instead derive this from the pinmux nodes? For example you have > this in the example below: > > usb3p0 { > nvidia,lanes = "pcie-0"; > ... > }; > > Perhaps what we need is to either key off the node name or add another > property, such as: > > nvidia,usb3-port = <0>; > > This would match the nvidia,usb2-port property that you've added below. That is actually how I described the USB3 port to SS lane mapping originally, but in review of an earlier version of this series, Stephen suggested that I make it a separate, not pinconfig property since it wasn't a value written directly to the hardware. I'm fine with changing it back as the pinconfig property makes more sense to me as well. -- 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: FTDI driver in Linux
On Thu, Oct 16, 2014 at 02:21:02PM +0200, Johan Hovold wrote: > On Thu, Oct 16, 2014 at 02:55:22PM +0400, Victor Ashik wrote: > > 16.10.2014 14:02, Johan Hovold пишет: > > > On Thu, Oct 16, 2014 at 12:47:05PM +0400, Victor Ashik wrote: > > [91798.346109] usbserial: unknown parameter 'debug' ignored > > The debug module parameter has been removed. You need to enable it using > dynamic debugging (e.g. through debugfs). > > > [91798.346489] usbcore: registered new interface driver usbserial > > [91798.346512] usbcore: registered new interface driver usbserial_generic > > [91798.346531] usbserial: USB Serial support registered for generic > > [91803.034148] ftdi_sio: unknown parameter 'debug' ignored > > Same here (although it seems you enabled it in the driver directly). > > > [91803.034572] usbcore: registered new interface driver ftdi_sio > > [91803.034695] usbserial: USB Serial support registered for FTDI USB > > Serial Device > > [91803.034757] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected > > [91803.034898] usb 1-1.2: Detected SIO > > [91803.034901] usb 1-1.2: Number of endpoints 2 > > [91803.034902] usb 1-1.2: Endpoint 1 MaxPacketSize 64 > > [91803.034904] usb 1-1.2: Endpoint 2 MaxPacketSize 64 > > [91803.034906] usb 1-1.2: Setting MaxPacketSize 64 > > [91803.035940] ftdi_sio ttyUSB0: Unable to read latency timer: -32 > > [91803.036435] ftdi_sio ttyUSB0: Unable to write latency timer: -32 > > [91803.036711] usb 1-1.2: FTDI USB Serial Device converter now attached > > to ttyUSB0 > > [91806.063117] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set > > databits/stopbits/parity > > [91806.063467] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate > > [91806.063806] ftdi_sio ttyUSB0: urb failed to clear flow control > > [91806.064545] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate > > [91806.064914] ftdi_sio ttyUSB0: urb failed to clear flow control > > [91806.065289] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate > > [91806.065662] ftdi_sio ttyUSB0: urb failed to set to rts/cts flow control > > [91806.066036] ftdi_sio ttyUSB0: failed to get modem status: -32 > > [91806.066414] ftdi_sio ttyUSB0: urb failed to set to rts/cts flow control > > [91812.841711] ftdi_sio ttyUSB0: failed to get modem status: -32 > > [91812.842077] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate > > [91812.842437] ftdi_sio ttyUSB0: urb failed to clear flow control > > [91812.842788] ftdi_sio ttyUSB0: failed to get modem status: -32 > > [91812.843160] ftdi_sio ttyUSB0: error from flowcontrol urb > > So basically all control transfers are failing. (This should really have > been logged at error log level -- I'll fix that up.) They are logged at error level. You just haven't enabled debugging yet. > I'll try to have a look at the bsd logs you sent soon. Meanwhile you > could test if the device works at 115200 8N1, which could be the default > baud rate. Could you try the patch below? It's a bit of a long shot, but if it works this bug predates the shift to git in 2005. :) If it does not work, could you provide a log from when opening the device on netBSD with debugging enabled in that driver? Thanks, Johan >From 95b16d865f629587b0d10a01e168c4f1641af67a Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Wed, 29 Oct 2014 17:59:19 +0100 Subject: [PATCH] USB: ftdi_sio: fix legacy SIO interface number Signed-off-by: Johan Hovold --- drivers/usb/serial/ftdi_sio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index dc72b924c399..56adc06b4e2e 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -1531,6 +1531,7 @@ static void ftdi_determine_type(struct usb_serial_port *port) /* Old device. Assume it's the original SIO. */ priv->chip_type = SIO; priv->baud_base = 1200 / 16; + priv->interface = PIT_SIOA; } else if (version < 0x400) { /* Assume it's an FT8U232AM (or FT8U245AM) */ /* (It might be a BM because of the iSerialNumber bug, -- 2.0.4 -- 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: Add UDC driver for Broadcom USB3.0 device controller IP BDC
On Tue, Oct 14, 2014 at 11:53 AM, Felipe Balbi wrote: > Hi, sorry for my late response, I was pulled into some other activity. I will be sending out v2 patch this week. > > On Tue, Oct 14, 2014 at 11:30:40AM -0700, Ashwini Pahuja wrote: > > > >> > > +/* Upstream port status change sr */ >> > > +void bdc_sr_upsc(struct bdc *, struct bdc_sr *); >> > > +/* transfer sr */ >> > > +void bdc_sr_xsf(struct bdc *, struct bdc_sr *); >> > > +/* command completion */ >> > > +void bdc_sr_cmd(struct bdc *, struct bdc_sr *); >> > > +/* Controller exception */ >> > > +void bdc_sr_ce(struct bdc *, struct bdc_sr *); >> > > +/* bus interval adjustment */ >> > > +void bdc_sr_bia(struct bdc *, struct bdc_sr *); >> > > +/* Microframce count wrap */ >> > > +void bdc_sr_mcw(struct bdc *, struct bdc_sr *); >> > > +/* Transfer notification error */ >> > > +void bdc_sr_tne(struct bdc *, struct bdc_sr *); >> > > +/* Buffer descriptor error */ >> > > +void bdc_sr_bde(struct bdc *, struct bdc_sr *); >> > > + >> > > +/* EP0 XSF handlers */ >> > > +void bdc_xsf_ep0_setup_recv(struct bdc *, struct bdc_sr *); >> > > +void bdc_xsf_ep0_data_start(struct bdc *, struct bdc_sr *); >> > > +void bdc_xsf_ep0_status_start(struct bdc *, struct bdc_sr *); >> > > + >> > > +void bdc_func_wake_timer(struct work_struct *); >> > > + >> > > +int ep_disable(struct bdc_ep *); >> > > +int ep_enable(struct bdc_ep *); >> > >> > wy too much detail of your driver is exposed. This usually means >> > it's wrong. Figure out if you really, really need all of these >> > implementation details to be exposed like this. >> > >> > (Hint: you don't) >> >> OK, Do you mean a lot of function/variables are global instead of static >> and they shouldn't be exposed to all the files? If yes, I will improve this >> in v2. > > yeah, that needs to be cleaned up. > OK. >> > > +/* default 64 entries in a SRR */ >> > > +unsigned int num_sr_entries = 64; >> > > +module_param(num_sr_entries, uint, S_IRUGO); >> > > +MODULE_PARM_DESC(num_sr_entries, "SR entries in SRR,should be power of >> > 2"); >> > > + >> > > +/* Num of bds per table */ >> > > +unsigned int bds_per_table = 32; >> > > +module_param(bds_per_table, uint, S_IRUGO); >> > > +MODULE_PARM_DESC(bds_per_table, "number of bd per table, default 32"); >> > > + >> > > +/* Num of tables in bd list for control,bulk and Int ep */ >> > > +unsigned int num_tables = 2; >> > > +module_param(num_tables, uint, S_IRUGO); >> > > +MODULE_PARM_DESC(num_tables, "number of tables in a bd list for >> > control/bulk/Int ep, default 1"); > > btw, your default is wrong. > >> > > +/* Num of tables in bd list for Isoch ep */ >> > > +unsigned int num_tables_isoc = 6; >> > > +module_param(num_tables_isoc, uint, S_IRUGO); >> > > +MODULE_PARM_DESC(num_tables_isoc, "number of table in bd list for Isoch >> > ep, default 6"); >> > >> > why are any of these configurable ? >> > >> >> This driver is targeted for various kind of applications, so depending upon >> the application requirement and memory availability the user can pass >> configurable number of dma descriptor tables. If these module parameters >> are not there then user will have to recompile the driver. > > aren't there any read-only registers you can use to figure some of these > out in runtime ? Usually, the more module parameters you have, the > "harder" it is to actually use your driver. > >> > > +/* User can force disable U1/U2 entry/exit due to host/phy issues */ >> > > +bool disable_u1u2 = false; >> > > +module_param(disable_u1u2, bool, S_IRUSR); >> > > +MODULE_PARM_DESC(disable_u1u2, "Forcefully disable U1/U2 entry/exit"); >> > >> > have you really seen this happen ? Which host was broken ? How have you >> > proved it to be a host problem ? >> > >> >> Actually, I should have mentioned hubs in the comments, sometime back we >> came across a hub which had broken u1/u2 and that's why I provided user the >> flexibility to disable u1/u2 optionally. > > that should not be done by the UDC however. USB Host stack should take > care of considering that a quirky device. > >> > > +/* U1 Timeout default: 248usec */ >> > > +unsigned int u1_timeout = 0xf8; >> > > +module_param(u1_timeout, uint, S_IRUSR); >> > > +MODULE_PARM_DESC(u1_timeout, "U1T in usec, valid range 1-255"); >> > >> > this should be configurable per-instance. Rather than globably for >> > everybody. Sure, right now you only have one instance, but things can >> > change. >> > >> > The u1_timeout parameter will depend upon application i.e. how aggressive >> they want the low power modes to be, so this parameter provides flexibility >> to the user without recompiling the driver. and I will like to keep this >> parameter. > > Not arguing against that. My point is that if you have an SoC with more > than one instance of this controller, you could have a PCB layout so > that u1_timeout will be different for each port. So instead of making > this global for everybody, you should allow this to be configured > per-intance. > >> > > +/* Interru
Re: [PATCH RESEND V4 2/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
>> + for (i = 0; i < ARRAY_SIZE(mbox->vchan_allocated); i++) { >> + if (mbox->vchan_allocated[i]) >> + mbox_chan_received_data(&mbox->mbox.chans[i], &msg); >> + } > > It seems like the only reason why you need to explicitly check for an > allocated channel is that mbox_chan_received_data() would otherwise > crash. Are mailbox drivers really supposed to keep track of whether a > channel has been requested by a client? Isn't that something that should > be done in the core? Yeah, I'd agree that this is something that should be handled by the core. >> +static int tegra_xusb_mbox_probe(struct platform_device *pdev) >> +{ >> + struct tegra_xusb_mbox *mbox; >> + struct resource *res; >> + int ret; >> + >> + mbox = devm_kzalloc(&pdev->dev, sizeof(*mbox), GFP_KERNEL); >> + if (!mbox) >> + return -ENOMEM; >> + platform_set_drvdata(pdev, mbox); >> + spin_lock_init(&mbox->lock); >> + >> + mbox->mbox.dev = &pdev->dev; >> + mbox->mbox.chans = devm_kcalloc(&pdev->dev, TEGRA_XUSB_MBOX_NUM_CHANS, >> + sizeof(*mbox->mbox.chans), GFP_KERNEL); >> + if (!mbox->mbox.chans) >> + return -ENOMEM; >> + mbox->mbox.num_chans = TEGRA_XUSB_MBOX_NUM_CHANS; >> + mbox->mbox.ops = &tegra_xusb_mbox_chan_ops; >> + mbox->mbox.txdone_poll = true; >> + mbox->mbox.txpoll_period = 0; /* no need to actually poll */ > > Does the core perhaps need special handling for this? It seems like > poll_txdone() will always rearm the timer used to do the polling, > irrespective of whether the transfer is actually done or not. Yeah, that doesn't seem quite right... > Maybe something like this patch would be more correct in handling > this: > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c > index afcb430508ec..85691a7d8ca6 100644 > --- a/drivers/mailbox/mailbox.c > +++ b/drivers/mailbox/mailbox.c > @@ -117,10 +117,11 @@ static void poll_txdone(unsigned long data) > struct mbox_chan *chan = &mbox->chans[i]; > > if (chan->active_req && chan->cl) { > - resched = true; > txdone = chan->mbox->ops->last_tx_done(chan); > if (txdone) > tx_tick(chan, 0); > + else > + resched = true; > } > } ... but we still need to re-arm the timer if tx_tick() submits another message. Perhaps the better thing to do is to have msg_submit() arm the timer. >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> + if (!res) >> + return -ENODEV; >> + mbox->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res)); >> + if (!mbox->regs) >> + return -ENOMEM; > > This doesn't look right. Upon closer inspection, the reason why you > don't use devm_request_resource() is because these registers are shared > with the XHCI controller. > > Perhaps a better design would be for the XHCI driver to expose the > mailbox rather than split it off into a separate driver. Well that's what I had originally, but then it was suggested I make it a separate driver. Stephen also brought this up during review and suggested that some sort of MFD would be the best way to structure this, but was fine with the way I have it now. I can move this driver around (again) if you feel that strongly about it... >> diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h >> new file mode 100644 >> index 000..cfe211d >> --- /dev/null >> +++ b/include/soc/tegra/xusb.h > > Perhaps this should really be named xusb-mbox.h? I'd prefer to leave it as xusb.h so that any other XUSB-related definitions can be left here. -- 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 net-next 0/2] r8152: support nway_reset
From: Hayes Wang Date: Tue, 28 Oct 2014 14:05:50 +0800 > Fix the CHECK from checkpatch.pl and support nway_reset. Series applied, thanks. -- 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 RESEND V4 4/9] pinctrl: tegra-xusb: Add USB PHY support
>> diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c >> b/drivers/pinctrl/pinctrl-tegra-xusb.c > [...] >> struct tegra_xusb_padctl_function { >> const char *name; >> const char * const *groups; >> @@ -72,6 +222,16 @@ struct tegra_xusb_padctl_soc { >> >> const struct tegra_xusb_padctl_lane *lanes; >> unsigned int num_lanes; >> + >> + u32 rx_wander; >> + u32 rx_eq; >> + u32 cdr_cntl; >> + u32 dfe_cntl; >> + u32 hs_slew; >> + u32 ls_rslew[TEGRA_XUSB_UTMI_PHYS]; >> + u32 hs_discon_level; >> + u32 spare_in; >> + int hsic_port_offset; > > unsigned int? Are these values all SoC-specific or can they vary per > board? Yes, all the members I added to struct tegra_xusb_pactl_soc are SoC-specific. >> + >> + for (i = 0; i < TEGRA_XUSB_USB3_PHYS; i++) { >> + if (phy == padctl->phys[TEGRA_XUSB_PADCTL_USB3_P0 + i]) >> + break; > > You could simply return i here and then BUG_ON unconditionally. > >> + } >> + BUG_ON(i == TEGRA_XUSB_USB3_PHYS); >> + >> + return i; >> +} > > Actually, thinking about it some more, perhaps making this a WARN_ON() > and returning an error so that we can continue and propagate the error > would be more useful. BUG_ON() will completely hang the kernel with no > way out but rebooting. WARN_ON() will give a hint about something being > wrong and returning an error will allow the kernel to continue to run, > which might be the only way to diagnose and fix the problem, even if it > means that USB 3.0 support will be disabled. I felt like BUG_ON is more appropriate here. Hitting this case means there's a bug in the PHY core or a driver has passed a bogus pointer and the stack dump produced by the BUG_ON should make it obvious as to what the issue is. I don't feel too strongly about it though. >> + u32 value, offset; >> + >> + padctl->usb3_ports[port].context_saved = true; > > What's the purpose of saving the context here? This seems to be > triggered by a request from XUSB, but it's then restored when the PHY is > powered on. How does that even happen? Won't the PHY stay powered all > the time? Or shouldn't the context be saved when powering off the PHY? Right, context is saved when requested by the XUSB controller and restored on power on. This is used during runtime power-gating or LP0 where the PHYs are powered off and on and this context is lost. Neither of these are currently implemented by the host driver, however. As far as why the context is saved upon request and not at power off, I'm not sure. I've observed that these messages come in when a USB3.0 device is enumerated. Perhaps the XUSB controller is doing some sort of tuning. >> @@ -936,6 +2098,18 @@ static int tegra_xusb_padctl_probe(struct >> platform_device *pdev) >> goto unregister; >> } >> >> + INIT_WORK(&padctl->mbox_req_work, tegra_xusb_phy_mbox_work); >> + padctl->mbox_client.dev = &pdev->dev; >> + padctl->mbox_client.tx_block = true; >> + padctl->mbox_client.tx_tout = 0; >> + padctl->mbox_client.rx_callback = tegra_xusb_phy_mbox_rx; >> + padctl->mbox_chan = mbox_request_channel(&padctl->mbox_client, 0); >> + if (IS_ERR(padctl->mbox_chan)) { >> + err = PTR_ERR(padctl->mbox_chan); >> + dev_err(&pdev->dev, "failed to request mailbox: %d\n", err); >> + goto unregister; >> + } > > I think this should be done before the registering the PHY provider so > that we don't expose one (even for only a very short time) before we > haven't made sure that it can be used. > > Also, this effectively makes the mailbox mandatory, which means that the > above code is going to break on older DTBs. So I think we have no choice > but to make mailbox (and hence XUSB) support optional. I understand the need for binding stability, but it's not like these bindings have been around for very long (a release or two?) and this series has existed for almost the same amount of time. Are there really any DTBs out there that are going to break because of this? >> diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h >> index cfe211d..149434f 100644 >> --- a/include/soc/tegra/xusb.h >> +++ b/include/soc/tegra/xusb.h >> @@ -10,6 +10,13 @@ >> #ifndef __SOC_TEGRA_XUSB_H__ >> #define __SOC_TEGRA_XUSB_H__ >> >> +#define TEGRA_XUSB_USB3_PHYS 2 >> +#define TEGRA_XUSB_UTMI_PHYS 3 >> +#define TEGRA_XUSB_HSIC_PHYS 2 >> +#define TEGRA_XUSB_NUM_USB_PHYS (TEGRA_XUSB_USB3_PHYS + >> TEGRA_XUSB_UTMI_PHYS + \ >> + TEGRA_XUSB_HSIC_PHYS) >> +#define TEGRA_XUSB_NUM_PHYS (TEGRA_XUSB_NUM_USB_PHYS + 2) /* + SATA & PCIe >> */ > > These are really XUSB pad controller specific defines, why does anyone > else need to know this? They're not pad controller specific. They're also used in the xHCI host driver. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org Mo
Re: [PATCH usb 06/32] renesas_usbhs: common: remove duplicate check on resource
Hello. On 10/29/2014 07:00 PM, Varka Bhadram wrote: From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/renesas_usbhs/common.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index b3b6813..3ffd552 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -497,8 +497,9 @@ static int usbhs_probe(struct platform_device *pdev) /* platform data */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + Strange: in other patches you're moving this call close to devm_ioremap_resource(), but not here... Why? WBR, Sergei -- 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 v1] usb: gadget: pxa27x_udc: fix warning in non device-tree build
The recent change bringing device-tree support triggers a warning in a non device-tree build : drivers/usb/gadget/udc/pxa27x_udc.c:2405:28: warning: 'udc_pxa_dt_ids' defined but not used [-Wunused-variable] Fix the warning with a preprocessor condition. Signed-off-by: Robert Jarzmik --- drivers/usb/gadget/udc/pxa27x_udc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c b/drivers/usb/gadget/udc/pxa27x_udc.c index 69e7b816..9b03fab 100644 --- a/drivers/usb/gadget/udc/pxa27x_udc.c +++ b/drivers/usb/gadget/udc/pxa27x_udc.c @@ -2400,11 +2400,13 @@ static struct pxa_udc memory = { } }; +#if defined(CONFIG_OF) static struct of_device_id udc_pxa_dt_ids[] = { { .compatible = "marvell,pxa270-udc" }, {} }; MODULE_DEVICE_TABLE(of, udc_pxa_dt_ids); +#endif /** * pxa_udc_probe - probes the udc device -- 2.1.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: [PATCH usb 00/32] cleanup on resource check
On Wed, 29 Oct 2014, Varka Bhadram wrote: > This series removes the duplication of sanity check for > platform_get_resource() return resource. It will be checked > with devm_ioremap_resource() > > This series based on usb/master. > > Varka Bhadram (32): > host: ehci-atmel: remove duplicate check on resource > host: ehci-exynos: remove duplicate check on resource > host: ehci-fsl: remove duplicate check on resource > dwc3: core: remove duplicate check on resource > dwc3: dwc3-keystone: remove duplicate check on resource > renesas_usbhs: common: remove duplicate check on resource > phy: phy-rcar-usb: remove duplicate check on resource > musb: musb_dsps: remove duplicate check on resource > musb: musb_core: remove duplicate check on resource > host: xhci-plat: remove duplicate check on resource > host: uhci-platform: remove duplicate check on resource > host: ohci-st: remove duplicate check on resource > host: ohci-spear: remove duplicate check on resource > host: ehci-sh: remove duplicate check on resource > host: ohci-pxa27x: remove duplicate check on resource > host: ohci-platform: remove duplicate check on resource > host: ohci-octeon: remove duplicate check on resource > host: ohci-jz4740: remove duplicate check on resource > host: ohci-exynos: remove duplicate check on resource > host: ohci-da8xx: remove duplicate check on resource > host: ohci-at91: remove duplicate check on resource > host: ehci-w90x900: remove duplicate check on resource > host: ehci-tegra: remove duplicate check on resource > host: ehci-st: remove duplicate check on resource > host: ehci-spear: remove duplicate check on resource > host: ehci-sead3: remove duplicate check on resource > host: ehci-platform: remove duplicate check on resource > host: ehci-orion: remove duplicate check on resource > host: ehci-octeon: remove duplicate check on resource > host: ehci-mxc: remove duplicate check on resource > host: ehci-mv: remove duplicate check on resource > host: ehci-msm: remove duplicate check on resource For all the ehci, ohci, and uhci changes: Acked-by: Alan Stern I didn't look carefully at the others, but the dwc3-core patch (4/32) definitely seemed wrong. Alan Stern -- 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] USB: simple: add Google simple serial SubClass support
Add support for Google devices that export simple serial interfaces using the vendor specific SubClass/Protocol pair 0x50/0x01. Signed-off-by: Anton Staaf --- drivers/usb/serial/usb-serial-simple.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/usb/serial/usb-serial-simple.c b/drivers/usb/serial/usb-serial-simple.c index fb79775..85bb973 100644 --- a/drivers/usb/serial/usb-serial-simple.c +++ b/drivers/usb/serial/usb-serial-simple.c @@ -8,6 +8,7 @@ * Copyright (C) 2010 Zilogic Systems * Copyright (C) 2013 Wei Shuai * Copyright (C) 2013 Linux Foundation + * Copyright (C) 2014 Google, Inc. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License version @@ -80,6 +81,14 @@ DEVICE(suunto, SUUNTO_IDS); { USB_DEVICE(0x908, 0x0004) } DEVICE(siemens_mpi, SIEMENS_IDS); +/* Google Serial USB SubClass */ +#define GOOGLE_IDS() \ + { USB_VENDOR_AND_INTERFACE_INFO(0x18d1,\ + USB_CLASS_VENDOR_SPEC, \ + 0x50, \ + 0x01) } +DEVICE(google, GOOGLE_IDS); + /* All of the above structures mushed into two lists */ static struct usb_serial_driver * const serial_drivers[] = { &zio_device, @@ -90,6 +99,7 @@ static struct usb_serial_driver * const serial_drivers[] = { &hp4x_device, &suunto_device, &siemens_mpi_device, + &google_device, NULL }; @@ -102,6 +112,7 @@ static const struct usb_device_id id_table[] = { HP4X_IDS(), SUUNTO_IDS(), SIEMENS_IDS(), + GOOGLE_IDS(), { }, }; MODULE_DEVICE_TABLE(usb, id_table); -- 2.1.0.rc2.206.gedb03e5 -- 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
Potential USB PHY error handling fix for stable
Hi, One of the Linaro stable kernel users has suggested 2c4e3dbf63b39d (usb: phy: return -ENODEV on failure of try_module_get) as a fix for the stable kernel. While it's error handling that's being fixed this does seem like a reasonable candidate, it's a very simple fix and the behaviour without the change is to return a NULL pointer rather than an error pointer which callers will interpret as success which isn't good. Does this seem reasonable? Thanks, Mark signature.asc Description: Digital signature
Re: Potential USB PHY error handling fix for stable
On Wed, Oct 29, 2014 at 10:10:12PM +, Mark Brown wrote: > Hi, > > One of the Linaro stable kernel users has suggested 2c4e3dbf63b39d (usb: > phy: return -ENODEV on failure of try_module_get) as a fix for the > stable kernel. While it's error handling that's being fixed this does > seem like a reasonable candidate, it's a very simple fix and the > behaviour without the change is to return a NULL pointer rather than an > error pointer which callers will interpret as success which isn't good. > > Does this seem reasonable? What stable kernel are you referring to? This patch is in 3.17 already, and 3.16 is now end-of-life after this next release in a few hours. 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: Potential USB PHY error handling fix for stable
On Wed, Oct 29, 2014 at 03:30:18PM -0700, Greg Kroah-Hartman wrote: > On Wed, Oct 29, 2014 at 10:10:12PM +, Mark Brown wrote: > > One of the Linaro stable kernel users has suggested 2c4e3dbf63b39d (usb: > > phy: return -ENODEV on failure of try_module_get) as a fix for the > > stable kernel. While it's error handling that's being fixed this does > > seem like a reasonable candidate, it's a very simple fix and the > > behaviour without the change is to return a NULL pointer rather than an > > error pointer which callers will interpret as success which isn't good. > > Does this seem reasonable? > What stable kernel are you referring to? This patch is in 3.17 already, > and 3.16 is now end-of-life after this next release in a few hours. It applies to v3.14 as well, I didn't check further back. signature.asc Description: Digital signature
Re: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
Unless I'm missing something, this patch appears to have still not been picked up. It would be nice if it can go in for 3.18 so that we have working USB on pandaboard again at least in that release. Tony, would you mind carrying it as OMAP maintainer since we haven't heard anything from Kishon (the PHY maintainer) about this? It's been acked by Roger (whose patch introduced the problem). Thanks. (leaving the patch intact below) On Tue, Oct 07, 2014 at 12:02:51PM +0100, Oussama Ghorbel wrote: > The USB OTG port does not work since v3.16 on omap platform. > This is a regression introduced by the commit > eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure > and remove). > This because the call to pm_runtime_enable() function is moved after the > call to devm_phy_create() function, which has side effect since later in > the subsequent calls of devm_phy_create() there is a check with > pm_runtime_enabled() to configure few things. > > Signed-off-by: Oussama Ghorbel > --- > drivers/phy/phy-omap-usb2.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c > index 93d7835..acc13f8 100644 > --- a/drivers/phy/phy-omap-usb2.c > +++ b/drivers/phy/phy-omap-usb2.c > @@ -262,14 +262,16 @@ static int omap_usb2_probe(struct platform_device *pdev) > otg->phy= &phy->phy; > > platform_set_drvdata(pdev, phy); > + pm_runtime_enable(phy->dev); > > generic_phy = devm_phy_create(phy->dev, NULL, &ops, NULL); > - if (IS_ERR(generic_phy)) > + if (IS_ERR(generic_phy)) { > + pm_runtime_disable(phy->dev); > return PTR_ERR(generic_phy); > + } > > phy_set_drvdata(generic_phy, phy); > > - pm_runtime_enable(phy->dev); > phy_provider = devm_of_phy_provider_register(phy->dev, > of_phy_simple_xlate); > if (IS_ERR(phy_provider)) { > -- > 1.8.3.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 -- 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 2/2] ARM: shmobile: lager: enable USB3.0
On Wed, Oct 29, 2014 at 08:19:30PM +0900, Yoshihiro Shimoda wrote: > Hi Magnus-san, > > (2014/10/29 15:53), Magnus Damm wrote: > > On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda > > wrote: > >> Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 > >> driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: > >> > >> phy phy-e6590100.usb-phy.3: phy init failed --> -16 > >> xhci-hcd: probe of ee00.usb failed with error -16 > >> > >> If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind > >> the USB3.0 driver as the following: > >> > >> echo :02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind > >> echo :02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind > >> echo ee00.usb > /sys/bus/platform/drivers/xhci-hcd/bind > >> > >> Note that there will be pinctrl-related error messages if both > >> internal PCI and USB3.0 are enabled but they should be just ignored: > >> > >> sh-pfc e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot > >> claim for ee00.usb > >> sh-pfc e606.pfc: pin-182 (ee00.usb) status -22 > >> ata1: SATA link down (SStatus 0 SControl 300) > >> sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2 > >> on device sh-pfc > >> > >> Signed-off-by: Yoshihiro Shimoda > >> --- > >> arch/arm/boot/dts/r8a7790-lager.dts |6 ++ > >> 1 file changed, 6 insertions(+) > > > > Hi Shimoda-san, > > > > Thanks for your patch. I'm fine with this patch as a first step, but > > I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? > > I investigated this reason today, and I found the reason is > request_firmware(). I checked the following environments: > > Case 1: xHCI and EHCI and OHCI are enabled "=y" Case 2: xHCI and EHCI > and OHCI are loadable modules "=m" Case 3: xHCI and EHCI and OHCI are > enabled "=y", and CONFIG_EXTRA_FIRMWARE is enabled > > The results are: - In "Case 1", EHCI and OHCI are probed first because > xHCI didn't find the firmware. - In "Case 2" and "Case 3", xHCI is > probed first. > > > Is the current order just based on device init order? In my mind the > > expected behavior would be to always use USB 3.0 if it happens to be > > available in the hardware, specified in the DTS, enabled by the kernel > > configuration and firmware is loadable. Or does some case exist where > > it is better to use USB 2.0? I suspect no. > > I agree with you. > > > So I wonder if you have any plans how to make USB 3.0 enabled by > > default on Lager? > > It depends on a kernel config. I'm not sure of the shmobile_defconfig > strategy. But, in my opinion, one of a solution is kernel modules (this > means the "Case 2".) It sounds like we should enable CONFIG_EXTRA_FIRMWARE in shmobile_defconfig. I wonder what if any fallout we can foresee occurring if we do that. -- 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] cdc-acm: ensure that termios get set when the port is activated
The driver wasn't properly configuring the hardware for the current termios settings under all conditions. Ensure that termios are written to the device when the port is activated. Signed-off-by: Jim Paris --- Switched to Johan's suggestion of using a prototype rather than moving acm_tty_set_termios. This depends on his patch in order to get proper DTR handling. Thanks, Jim --- drivers/usb/class/cdc-acm.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index e934e19f49f5..d2cd1b6d02a7 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -58,6 +58,9 @@ static struct usb_driver acm_driver; static struct tty_driver *acm_tty_driver; static struct acm *acm_table[ACM_TTY_MINORS]; +static void acm_tty_set_termios(struct tty_struct *tty, + struct ktermios *termios_old); + static DEFINE_MUTEX(acm_table_lock); /* @@ -554,6 +557,8 @@ static int acm_port_activate(struct tty_port *port, struct tty_struct *tty) goto error_submit_urb; } + acm_tty_set_termios(tty, NULL); + /* * Unthrottle device in case the TTY was closed while throttled. */ -- 2.1.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: [PATCH usb 00/32] cleanup on resource check
On Thursday 30 October 2014 02:43 AM, Alan Stern wrote: On Wed, 29 Oct 2014, Varka Bhadram wrote: This series removes the duplication of sanity check for platform_get_resource() return resource. It will be checked with devm_ioremap_resource() This series based on usb/master. Varka Bhadram (32): host: ehci-atmel: remove duplicate check on resource host: ehci-exynos: remove duplicate check on resource host: ehci-fsl: remove duplicate check on resource dwc3: core: remove duplicate check on resource dwc3: dwc3-keystone: remove duplicate check on resource renesas_usbhs: common: remove duplicate check on resource phy: phy-rcar-usb: remove duplicate check on resource musb: musb_dsps: remove duplicate check on resource musb: musb_core: remove duplicate check on resource host: xhci-plat: remove duplicate check on resource host: uhci-platform: remove duplicate check on resource host: ohci-st: remove duplicate check on resource host: ohci-spear: remove duplicate check on resource host: ehci-sh: remove duplicate check on resource host: ohci-pxa27x: remove duplicate check on resource host: ohci-platform: remove duplicate check on resource host: ohci-octeon: remove duplicate check on resource host: ohci-jz4740: remove duplicate check on resource host: ohci-exynos: remove duplicate check on resource host: ohci-da8xx: remove duplicate check on resource host: ohci-at91: remove duplicate check on resource host: ehci-w90x900: remove duplicate check on resource host: ehci-tegra: remove duplicate check on resource host: ehci-st: remove duplicate check on resource host: ehci-spear: remove duplicate check on resource host: ehci-sead3: remove duplicate check on resource host: ehci-platform: remove duplicate check on resource host: ehci-orion: remove duplicate check on resource host: ehci-octeon: remove duplicate check on resource host: ehci-mxc: remove duplicate check on resource host: ehci-mv: remove duplicate check on resource host: ehci-msm: remove duplicate check on resource For all the ehci, ohci, and uhci changes: Acked-by: Alan Stern Thanx for your ACK. I didn't look carefully at the others, but the dwc3-core patch (4/32) definitely seemed wrong. I don't find any wrong in the code. Plese see the probe() static int dwc3_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct dwc3_platform_data *pdata = dev_get_platdata(dev); struct device_node *node = dev->of_node; struct resource *res; struct dwc3 *dwc; int ret; void __iomem*regs; void*mem; mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL); if (!mem) return -ENOMEM; dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); dwc->mem = mem; dwc->dev = dev; res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); if (!res) { dev_err(dev, "missing IRQ\n"); return -ENODEV; } dwc->xhci_resources[1].start = res->start; dwc->xhci_resources[1].end = res->end; dwc->xhci_resources[1].flags = res->flags; dwc->xhci_resources[1].name = res->name; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); /* * Request memory region but exclude xHCI regs, * since it will be requested by the xhci-plat driver. */ regs = devm_ioremap_resource(dev, res); if (IS_ERR(regs)) return PTR_ERR(regs); dwc->xhci_resources[0].start = res->start; dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + DWC3_XHCI_REGS_END; dwc->xhci_resources[0].flags = res->flags; dwc->xhci_resources[0].name = res->name; res->start += DWC3_GLOBALS_REGS_START; dwc->regs= regs; dwc->regs_size = resource_size(res); /* * restore res->start back to its original value so that, * in case the probe is deferred, we don't end up getting error in * request the memory region the next time probe is called. */ res->start -= DWC3_GLOBALS_REGS_START; if (node) { dwc->maximum_speed = of_usb_get_maximum_speed(node); dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize"); dwc->dr_mode = of_usb_get_dr_mode(node); } else if (pdata) { dwc->maximum_speed = pdata->maximum_speed; dwc->needs_fifo_resize = pdata->tx_fifo_resize; dwc->dr_mode = pdata->dr_mode; } /* default to superspeed if no maximum_speed passed */ if (dwc->maximum_speed == USB_SPEED_UNKNOWN) dwc->maximum_speed = USB_SPEED_SUPER; ret = dwc3_cor
Re: [PATCH usb 06/32] renesas_usbhs: common: remove duplicate check on resource
On Thursday 30 October 2014 01:24 AM, Sergei Shtylyov wrote: Hello. On 10/29/2014 07:00 PM, Varka Bhadram wrote: From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram --- drivers/usb/renesas_usbhs/common.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index b3b6813..3ffd552 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -497,8 +497,9 @@ static int usbhs_probe(struct platform_device *pdev) /* platform data */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + Strange: in other patches you're moving this call close to devm_ioremap_resource(), but not here... Why? No reason. Thanx for your careful review. I will fix it. Thanx WBR, Sergei -- Regards, Varka Bhadram. --- [ C-DAC is on facebook. Kindly follow us on the following url: https://www.facebook.com/CDACINDIA ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- --- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- -- 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: cdc-acm: add device id for GW Instek AFG-2225
Oliver Neukum wrote: > Then I guess I'll take no further action in kernel space. I for one would like the kernel messages to be less prominent, if they stay at all. Since descriptors are not always correct, it's not so useful for the kernel to output such "loud" messages. //Peter -- 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 04/32] dwc3: core: remove duplicate check on resource
On Wed, Oct 29, 2014 at 09:30:14PM +0530, Varka Bhadram wrote: > From: Varka Bhadram > > Sanity check on resource happening with devm_ioremap_resource(). > > Signed-off-by: Varka Bhadram next time, use scripts/get_maintainer.pl. It would tell you I maintain dwc3, musb and the gadget framework. I should also be Cced for renesas and dwc2 since those also come through my tree. > --- > drivers/usb/dwc3/core.c | 19 +++ > 1 file changed, 7 insertions(+), 12 deletions(-) > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index b0f4d52..c9ccac9 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -655,10 +655,13 @@ static int dwc3_probe(struct platform_device *pdev) > dwc->xhci_resources[1].name = res->name; > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - if (!res) { > - dev_err(dev, "missing memory resource\n"); > - return -ENODEV; > - } > + /* > + * Request memory region but exclude xHCI regs, > + * since it will be requested by the xhci-plat driver. > + */ > + regs = devm_ioremap_resource(dev, res); > + if (IS_ERR(regs)) > + return PTR_ERR(regs); > > dwc->xhci_resources[0].start = res->start; > dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + > @@ -668,14 +671,6 @@ static int dwc3_probe(struct platform_device *pdev) > > res->start += DWC3_GLOBALS_REGS_START; > > - /* > - * Request memory region but exclude xHCI regs, > - * since it will be requested by the xhci-plat driver. > - */ > - regs = devm_ioremap_resource(dev, res); > - if (IS_ERR(regs)) > - return PTR_ERR(regs); > - this is wrong. Read your patch again and it should be very easy to note the mistake. -- balbi signature.asc Description: Digital signature
Re: [PATCH usb 00/32] cleanup on resource check
Hi, On Thu, Oct 30, 2014 at 06:42:08AM +0530, Varka Bhadram wrote: > On Thursday 30 October 2014 02:43 AM, Alan Stern wrote: > >On Wed, 29 Oct 2014, Varka Bhadram wrote: > > > >>This series removes the duplication of sanity check for > >>platform_get_resource() return resource. It will be checked > >>with devm_ioremap_resource() > >> > >>This series based on usb/master. > >> > >>Varka Bhadram (32): > >> host: ehci-atmel: remove duplicate check on resource > >> host: ehci-exynos: remove duplicate check on resource > >> host: ehci-fsl: remove duplicate check on resource > >> dwc3: core: remove duplicate check on resource > >> dwc3: dwc3-keystone: remove duplicate check on resource > >> renesas_usbhs: common: remove duplicate check on resource > >> phy: phy-rcar-usb: remove duplicate check on resource > >> musb: musb_dsps: remove duplicate check on resource > >> musb: musb_core: remove duplicate check on resource > >> host: xhci-plat: remove duplicate check on resource > >> host: uhci-platform: remove duplicate check on resource > >> host: ohci-st: remove duplicate check on resource > >> host: ohci-spear: remove duplicate check on resource > >> host: ehci-sh: remove duplicate check on resource > >> host: ohci-pxa27x: remove duplicate check on resource > >> host: ohci-platform: remove duplicate check on resource > >> host: ohci-octeon: remove duplicate check on resource > >> host: ohci-jz4740: remove duplicate check on resource > >> host: ohci-exynos: remove duplicate check on resource > >> host: ohci-da8xx: remove duplicate check on resource > >> host: ohci-at91: remove duplicate check on resource > >> host: ehci-w90x900: remove duplicate check on resource > >> host: ehci-tegra: remove duplicate check on resource > >> host: ehci-st: remove duplicate check on resource > >> host: ehci-spear: remove duplicate check on resource > >> host: ehci-sead3: remove duplicate check on resource > >> host: ehci-platform: remove duplicate check on resource > >> host: ehci-orion: remove duplicate check on resource > >> host: ehci-octeon: remove duplicate check on resource > >> host: ehci-mxc: remove duplicate check on resource > >> host: ehci-mv: remove duplicate check on resource > >> host: ehci-msm: remove duplicate check on resource > >For all the ehci, ohci, and uhci changes: > > > >Acked-by: Alan Stern > > Thanx for your ACK. > > >I didn't look carefully at the others, but the dwc3-core patch (4/32) > >definitely seemed wrong. > > > I don't find any wrong in the code. Really ? Look more carefuly > static int dwc3_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; > struct dwc3_platform_data *pdata = dev_get_platdata(dev); > struct device_node *node = dev->of_node; > struct resource *res; > struct dwc3 *dwc; > > int ret; > > void __iomem*regs; > void*mem; > > mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL); > if (!mem) > return -ENOMEM; > > dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); > dwc->mem = mem; > dwc->dev = dev; > > res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); > if (!res) { > dev_err(dev, "missing IRQ\n"); > return -ENODEV; > } > dwc->xhci_resources[1].start = res->start; > dwc->xhci_resources[1].end = res->end; > dwc->xhci_resources[1].flags = res->flags; > dwc->xhci_resources[1].name = res->name; > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > /* >* Request memory region but exclude xHCI regs, >* since it will be requested by the xhci-plat driver. >*/ > regs = devm_ioremap_resource(dev, res); because you moved this call here... > if (IS_ERR(regs)) > return PTR_ERR(regs); > > dwc->xhci_resources[0].start = res->start; > dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + > DWC3_XHCI_REGS_END; > dwc->xhci_resources[0].flags = res->flags; > dwc->xhci_resources[0].name = res->name; > > res->start += DWC3_GLOBALS_REGS_START; ... before doing this, you're now ioremapping the entire space *INCLUDING* the XHCI address space, which means that you have just broken every single platform using this driver in host mode. -- balbi signature.asc Description: Digital signature
Re: Potential USB PHY error handling fix for stable
On Wed, Oct 29, 2014 at 10:54:35PM +, Mark Brown wrote: > On Wed, Oct 29, 2014 at 03:30:18PM -0700, Greg Kroah-Hartman wrote: > > On Wed, Oct 29, 2014 at 10:10:12PM +, Mark Brown wrote: > > > > One of the Linaro stable kernel users has suggested 2c4e3dbf63b39d (usb: > > > phy: return -ENODEV on failure of try_module_get) as a fix for the > > > stable kernel. While it's error handling that's being fixed this does > > > seem like a reasonable candidate, it's a very simple fix and the > > > behaviour without the change is to return a NULL pointer rather than an > > > error pointer which callers will interpret as success which isn't good. > > > > Does this seem reasonable? > > > What stable kernel are you referring to? This patch is in 3.17 already, > > and 3.16 is now end-of-life after this next release in a few hours. > > It applies to v3.14 as well, I didn't check further back. It goes further back than that, but since nobody complained so far, I'm ok with v3.14 only if Greg accepts that. -- balbi signature.asc Description: Digital signature
Re: [PATCH usb 04/32] dwc3: core: remove duplicate check on resource
On Wed, Oct 29, 2014 at 09:40:12PM -0500, Felipe Balbi wrote: > On Wed, Oct 29, 2014 at 09:30:14PM +0530, Varka Bhadram wrote: > > From: Varka Bhadram > > > > Sanity check on resource happening with devm_ioremap_resource(). > > > > Signed-off-by: Varka Bhadram > > next time, use scripts/get_maintainer.pl. It would tell you I maintain > dwc3, musb and the gadget framework. I should also be Cced for renesas > and dwc2 since those also come through my tree. oh yeah, drivers/usb/phy also goes through my tree. -- balbi signature.asc Description: Digital signature
Re: [PATCH usb 04/32] dwc3: core: remove duplicate check on resource
Hi Balbi, On 10/30/2014 08:17 AM, Felipe Balbi wrote: On Wed, Oct 29, 2014 at 09:40:12PM -0500, Felipe Balbi wrote: On Wed, Oct 29, 2014 at 09:30:14PM +0530, Varka Bhadram wrote: From: Varka Bhadram Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram next time, use scripts/get_maintainer.pl. It would tell you I maintain dwc3, musb and the gadget framework. I should also be Cced for renesas and dwc2 since those also come through my tree. oh yeah, drivers/usb/phy also goes through my tree. Ok. I will add Cc to you. Thanx -- Regards, Varka Bhadram. -- 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 00/32] cleanup on resource check
Hi Balbi, On 10/30/2014 08:13 AM, Felipe Balbi wrote: Hi, On Thu, Oct 30, 2014 at 06:42:08AM +0530, Varka Bhadram wrote: On Thursday 30 October 2014 02:43 AM, Alan Stern wrote: On Wed, 29 Oct 2014, Varka Bhadram wrote: This series removes the duplication of sanity check for platform_get_resource() return resource. It will be checked with devm_ioremap_resource() This series based on usb/master. Varka Bhadram (32): host: ehci-atmel: remove duplicate check on resource host: ehci-exynos: remove duplicate check on resource host: ehci-fsl: remove duplicate check on resource dwc3: core: remove duplicate check on resource dwc3: dwc3-keystone: remove duplicate check on resource renesas_usbhs: common: remove duplicate check on resource phy: phy-rcar-usb: remove duplicate check on resource musb: musb_dsps: remove duplicate check on resource musb: musb_core: remove duplicate check on resource host: xhci-plat: remove duplicate check on resource host: uhci-platform: remove duplicate check on resource host: ohci-st: remove duplicate check on resource host: ohci-spear: remove duplicate check on resource host: ehci-sh: remove duplicate check on resource host: ohci-pxa27x: remove duplicate check on resource host: ohci-platform: remove duplicate check on resource host: ohci-octeon: remove duplicate check on resource host: ohci-jz4740: remove duplicate check on resource host: ohci-exynos: remove duplicate check on resource host: ohci-da8xx: remove duplicate check on resource host: ohci-at91: remove duplicate check on resource host: ehci-w90x900: remove duplicate check on resource host: ehci-tegra: remove duplicate check on resource host: ehci-st: remove duplicate check on resource host: ehci-spear: remove duplicate check on resource host: ehci-sead3: remove duplicate check on resource host: ehci-platform: remove duplicate check on resource host: ehci-orion: remove duplicate check on resource host: ehci-octeon: remove duplicate check on resource host: ehci-mxc: remove duplicate check on resource host: ehci-mv: remove duplicate check on resource host: ehci-msm: remove duplicate check on resource For all the ehci, ohci, and uhci changes: Acked-by: Alan Stern Thanx for your ACK. I didn't look carefully at the others, but the dwc3-core patch (4/32) definitely seemed wrong. I don't find any wrong in the code. Really ? Look more carefuly static int dwc3_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct dwc3_platform_data *pdata = dev_get_platdata(dev); struct device_node *node = dev->of_node; struct resource *res; struct dwc3 *dwc; int ret; void __iomem*regs; void*mem; mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL); if (!mem) return -ENOMEM; dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); dwc->mem = mem; dwc->dev = dev; res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); if (!res) { dev_err(dev, "missing IRQ\n"); return -ENODEV; } dwc->xhci_resources[1].start = res->start; dwc->xhci_resources[1].end = res->end; dwc->xhci_resources[1].flags = res->flags; dwc->xhci_resources[1].name = res->name; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); /* * Request memory region but exclude xHCI regs, * since it will be requested by the xhci-plat driver. */ regs = devm_ioremap_resource(dev, res); because you moved this call here... if (IS_ERR(regs)) return PTR_ERR(regs); dwc->xhci_resources[0].start = res->start; dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + DWC3_XHCI_REGS_END; dwc->xhci_resources[0].flags = res->flags; dwc->xhci_resources[0].name = res->name; res->start += DWC3_GLOBALS_REGS_START; ... before doing this, you're now ioremapping the entire space *INCLUDING* the XHCI address space, which means that you have just broken every single platform using this driver in host mode. In that case, i will drop this patch. Is other patches are fine except #04/32 patch..? -- Regards, Varka Bhadram. -- 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 00/32] cleanup on resource check
On 10/30/2014 09:05 AM, Varka Bhadram wrote: Hi Balbi, On 10/30/2014 08:13 AM, Felipe Balbi wrote: Hi, On Thu, Oct 30, 2014 at 06:42:08AM +0530, Varka Bhadram wrote: On Thursday 30 October 2014 02:43 AM, Alan Stern wrote: On Wed, 29 Oct 2014, Varka Bhadram wrote: This series removes the duplication of sanity check for platform_get_resource() return resource. It will be checked with devm_ioremap_resource() This series based on usb/master. Varka Bhadram (32): host: ehci-atmel: remove duplicate check on resource host: ehci-exynos: remove duplicate check on resource host: ehci-fsl: remove duplicate check on resource dwc3: core: remove duplicate check on resource dwc3: dwc3-keystone: remove duplicate check on resource renesas_usbhs: common: remove duplicate check on resource phy: phy-rcar-usb: remove duplicate check on resource musb: musb_dsps: remove duplicate check on resource musb: musb_core: remove duplicate check on resource host: xhci-plat: remove duplicate check on resource host: uhci-platform: remove duplicate check on resource host: ohci-st: remove duplicate check on resource host: ohci-spear: remove duplicate check on resource host: ehci-sh: remove duplicate check on resource host: ohci-pxa27x: remove duplicate check on resource host: ohci-platform: remove duplicate check on resource host: ohci-octeon: remove duplicate check on resource host: ohci-jz4740: remove duplicate check on resource host: ohci-exynos: remove duplicate check on resource host: ohci-da8xx: remove duplicate check on resource host: ohci-at91: remove duplicate check on resource host: ehci-w90x900: remove duplicate check on resource host: ehci-tegra: remove duplicate check on resource host: ehci-st: remove duplicate check on resource host: ehci-spear: remove duplicate check on resource host: ehci-sead3: remove duplicate check on resource host: ehci-platform: remove duplicate check on resource host: ehci-orion: remove duplicate check on resource host: ehci-octeon: remove duplicate check on resource host: ehci-mxc: remove duplicate check on resource host: ehci-mv: remove duplicate check on resource host: ehci-msm: remove duplicate check on resource For all the ehci, ohci, and uhci changes: Acked-by: Alan Stern Thanx for your ACK. I didn't look carefully at the others, but the dwc3-core patch (4/32) definitely seemed wrong. I don't find any wrong in the code. Really ? Look more carefuly static int dwc3_probe(struct platform_device *pdev) { struct device*dev = &pdev->dev; struct dwc3_platform_data *pdata = dev_get_platdata(dev); struct device_node*node = dev->of_node; struct resource*res; struct dwc3*dwc; intret; void __iomem*regs; void*mem; mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL); if (!mem) return -ENOMEM; dwc = PTR_ALIGN(mem, DWC3_ALIGN_MASK + 1); dwc->mem = mem; dwc->dev = dev; res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); if (!res) { dev_err(dev, "missing IRQ\n"); return -ENODEV; } dwc->xhci_resources[1].start = res->start; dwc->xhci_resources[1].end = res->end; dwc->xhci_resources[1].flags = res->flags; dwc->xhci_resources[1].name = res->name; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); /* * Request memory region but exclude xHCI regs, * since it will be requested by the xhci-plat driver. */ regs = devm_ioremap_resource(dev, res); because you moved this call here... if (IS_ERR(regs)) return PTR_ERR(regs); dwc->xhci_resources[0].start = res->start; dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + DWC3_XHCI_REGS_END; dwc->xhci_resources[0].flags = res->flags; dwc->xhci_resources[0].name = res->name; res->start += DWC3_GLOBALS_REGS_START; ... before doing this, you're now ioremapping the entire space *INCLUDING* the XHCI address space, which means that you have just broken every single platform using this driver in host mode. In that case, i will drop this patch. Is other patches are fine except #04/32 patch..? Can i add you Ack..? And based on which tree i need to generate the patches.? I rebased all these patches on [1] of master branch. [1]: https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git -- Regards, Varka Bhadram. -- 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 net-next] r8152: set RTL8152_UNPLUG when finding -ENODEV
Set RTL8152_UNPLUG when finding -ENODEV. This could accelerate unloading the driver when the device is unplugged. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index e1810bc..f116335 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -690,6 +690,9 @@ static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size, } } + if (ret == -ENODEV) + set_bit(RTL8152_UNPLUG, &tp->flags); + return ret; } @@ -757,6 +760,9 @@ static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen, } error1: + if (ret == -ENODEV) + set_bit(RTL8152_UNPLUG, &tp->flags); + return ret; } @@ -1083,6 +1089,7 @@ static void read_bulk_callback(struct urb *urb) result = r8152_submit_rx(tp, agg, GFP_ATOMIC); if (result == -ENODEV) { + set_bit(RTL8152_UNPLUG, &tp->flags); netif_device_detach(tp->netdev); } else if (result) { spin_lock(&tp->rx_lock); @@ -1187,11 +1194,13 @@ static void intr_callback(struct urb *urb) resubmit: res = usb_submit_urb(urb, GFP_ATOMIC); - if (res == -ENODEV) + if (res == -ENODEV) { + set_bit(RTL8152_UNPLUG, &tp->flags); netif_device_detach(tp->netdev); - else if (res) + } else if (res) { netif_err(tp, intr, tp->netdev, "can't resubmit intr, status %d\n", res); + } } static inline void *rx_agg_align(void *data) @@ -1755,6 +1764,7 @@ static void tx_bottom(struct r8152 *tp) struct net_device *netdev = tp->netdev; if (res == -ENODEV) { + set_bit(RTL8152_UNPLUG, &tp->flags); netif_device_detach(netdev); } else { struct net_device_stats *stats = &netdev->stats; -- 1.9.3 -- 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