[PATCH 1/1] staging: usbip: put usb_device and kill event handler thread in error cleanups.
From: harvey.yang If probe returns with error, the kthread is still alive even when all usbip modules unloaded. So do cleanups in error handler. Signed-off-by: harvey.yang --- drivers/staging/usbip/stub_dev.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c index c8d79a7..16a6868 100644 --- a/drivers/staging/usbip/stub_dev.c +++ b/drivers/staging/usbip/stub_dev.c @@ -432,6 +432,8 @@ static int stub_probe(struct usb_interface *interface, dev_err(&interface->dev, "stub_add_files for %s\n", udev_busid); usb_set_intfdata(interface, NULL); usb_put_intf(interface); + usb_put_dev(udev); + kthread_stop_put(sdev->ud.eh); busid_priv->interf_count = 0; busid_priv->sdev = NULL; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] usb: renesas_usbhs: fixup patches for host
Hi Felipe, GregKH These pathces fixup renesas_usbhs host side strange behavior for v3.8 kernel. based on felipe/master branch Kuninori Morimoto (3): usb: renesas_usbhs: remove debug information from usbhsh_hub_status_data() usb: renesas_usbhs: use transfer counter if IN direction bulk pipe usb: renesas_usbhs: host: add endpoint user counter drivers/usb/renesas_usbhs/fifo.c |4 ++ drivers/usb/renesas_usbhs/mod_host.c | 28 +- drivers/usb/renesas_usbhs/pipe.c | 101 ++ drivers/usb/renesas_usbhs/pipe.h |1 + 4 files changed, 119 insertions(+), 15 deletions(-) Best regards --- Kuninori Morimoto -- 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/3] usb: renesas_usbhs: remove debug information from usbhsh_hub_status_data()
Because usbhsh_hub_status_data() will be called many times,
there are too many obstructive/useless debug informations if driver has #define
DEBUG.
Thus, other important dev_dbg() information will hide.
This patch removed obstructive/useless dev_dbg().
Signed-off-by: Kuninori Morimoto
---
drivers/usb/renesas_usbhs/mod_host.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/mod_host.c
b/drivers/usb/renesas_usbhs/mod_host.c
index ff38a30..9bc8c2b 100644
--- a/drivers/usb/renesas_usbhs/mod_host.c
+++ b/drivers/usb/renesas_usbhs/mod_host.c
@@ -1085,8 +1085,6 @@ static void usbhsh_endpoint_disable(struct usb_hcd *hcd,
static int usbhsh_hub_status_data(struct usb_hcd *hcd, char *buf)
{
struct usbhsh_hpriv *hpriv = usbhsh_hcd_to_hpriv(hcd);
- struct usbhs_priv *priv = usbhsh_hpriv_to_priv(hpriv);
- struct device *dev = usbhs_priv_to_dev(priv);
int roothub_id = 1; /* only 1 root hub */
/*
@@ -1098,8 +1096,6 @@ static int usbhsh_hub_status_data(struct usb_hcd *hcd,
char *buf)
else
*buf = 0;
- dev_dbg(dev, "%s (%02x)\n", __func__, *buf);
-
return !!(*buf);
}
--
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 2/3] usb: renesas_usbhs: use transfer counter if IN direction bulk pipe
received data will break if it was bulk pipe and large data size,
because pipe kept BUF PID even though it doesn't have enough buffer.
To avoid this issue, renesas_usbhs can use transfer counter.
Pipe PID will be NAK if it didn't have enough buffer by this patch.
renesas_usbhs has strange address mapping.
Thus, it is difficult to calculate transfer counter setting address.
This patch use fixed table for it.
Signed-off-by: Kuninori Morimoto
---
drivers/usb/renesas_usbhs/fifo.c |4 ++
drivers/usb/renesas_usbhs/pipe.c | 101 ++
drivers/usb/renesas_usbhs/pipe.h |1 +
3 files changed, 106 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 4f60e03..6aab515 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -488,6 +488,8 @@ static int usbhsf_pio_try_push(struct usbhs_pkt *pkt, int
*is_done)
usbhs_pipe_data_sequence(pipe, pkt->sequence);
pkt->sequence = -1; /* -1 sequence will be ignored */
+ usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->length);
+
ret = usbhsf_fifo_select(pipe, fifo, 1);
if (ret < 0)
return 0;
@@ -594,6 +596,7 @@ static int usbhsf_prepare_pop(struct usbhs_pkt *pkt, int
*is_done)
usbhs_pipe_data_sequence(pipe, pkt->sequence);
pkt->sequence = -1; /* -1 sequence will be ignored */
+ usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->length);
usbhs_pipe_enable(pipe);
usbhsf_rx_irq_ctrl(pipe, 1);
@@ -795,6 +798,7 @@ static void xfer_work(struct work_struct *work)
dev_dbg(dev, " %s %d (%d/ %d)\n",
fifo->name, usbhs_pipe_number(pipe), pkt->length, pkt->zero);
+ usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->trans);
usbhs_pipe_enable(pipe);
usbhsf_dma_start(pipe, fifo);
dma_async_issue_pending(chan);
diff --git a/drivers/usb/renesas_usbhs/pipe.c b/drivers/usb/renesas_usbhs/pipe.c
index 122526c..7926e1c 100644
--- a/drivers/usb/renesas_usbhs/pipe.c
+++ b/drivers/usb/renesas_usbhs/pipe.c
@@ -93,6 +93,82 @@ static void usbhsp_pipe_cfg_set(struct usbhs_pipe *pipe, u16
mask, u16 val)
}
/*
+ * PIPEnTRN/PIPEnTRE functions
+ */
+static void usbhsp_pipe_trn_set(struct usbhs_pipe *pipe, u16 mask, u16 val)
+{
+ struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
+ struct device *dev = usbhs_priv_to_dev(priv);
+ int num = usbhs_pipe_number(pipe);
+ u16 reg;
+
+ /*
+* It is impossible to calculate address,
+* since PIPEnTRN addresses were mapped randomly.
+*/
+#define CASE_PIPExTRN(a) \
+ case 0x ## a: \
+ reg = PIPE ## a ## TRN; \
+ break;
+
+ switch (num) {
+ CASE_PIPExTRN(1);
+ CASE_PIPExTRN(2);
+ CASE_PIPExTRN(3);
+ CASE_PIPExTRN(4);
+ CASE_PIPExTRN(5);
+ CASE_PIPExTRN(B);
+ CASE_PIPExTRN(C);
+ CASE_PIPExTRN(D);
+ CASE_PIPExTRN(E);
+ CASE_PIPExTRN(F);
+ CASE_PIPExTRN(9);
+ CASE_PIPExTRN(A);
+ default:
+ dev_err(dev, "unknown pipe (%d)\n", num);
+ return;
+ }
+ __usbhsp_pipe_xxx_set(pipe, 0, reg, mask, val);
+}
+
+static void usbhsp_pipe_tre_set(struct usbhs_pipe *pipe, u16 mask, u16 val)
+{
+ struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
+ struct device *dev = usbhs_priv_to_dev(priv);
+ int num = usbhs_pipe_number(pipe);
+ u16 reg;
+
+ /*
+* It is impossible to calculate address,
+* since PIPEnTRE addresses were mapped randomly.
+*/
+#define CASE_PIPExTRE(a) \
+ case 0x ## a: \
+ reg = PIPE ## a ## TRE; \
+ break;
+
+ switch (num) {
+ CASE_PIPExTRE(1);
+ CASE_PIPExTRE(2);
+ CASE_PIPExTRE(3);
+ CASE_PIPExTRE(4);
+ CASE_PIPExTRE(5);
+ CASE_PIPExTRE(B);
+ CASE_PIPExTRE(C);
+ CASE_PIPExTRE(D);
+ CASE_PIPExTRE(E);
+ CASE_PIPExTRE(F);
+ CASE_PIPExTRE(9);
+ CASE_PIPExTRE(A);
+ default:
+ dev_err(dev, "unknown pipe (%d)\n", num);
+ return;
+ }
+
+ __usbhsp_pipe_xxx_set(pipe, 0, reg, mask, val);
+}
+
+/*
* PIPEBUF
*/
static void usbhsp_pipe_buf_set(struct usbhs_pipe *pipe, u16 mask, u16 val)
@@ -264,6 +340,31 @@ int usbhs_pipe_is_stall(struct usbhs_pipe *pipe)
return (int)(pid == PID_STALL10 || pid == PID_STALL11);
}
+void usbhs_pipe_set_trans_count_if_bulk(struct usbhs_pipe *pipe, int len)
+{
+ if (!usbhs_pipe_type_is(pipe, USB_ENDPOINT_XFER_BULK))
+ return;
+
+ /*
+* clear and disable transfer counter for IN/OUT pipe
+*/
+ usbhsp_pipe_tre_set(pipe, TRCLR | TRENB, TRCLR);
+
+ /*
+* Only IN direction bulk pipe can use transfer
[PATCH 3/3] usb: renesas_usbhs: host: add endpoint user counter
renesas_usbhs attaches pipe to endpoint when urb was queued, and it will be
detached when transfer was done.
Multi device controlling was enabled by this behavior.
Now renesas_usbhs driver tried to wait until detaching
if urb was queued to endpoint which already has been attached to pipe,
and it created strange driver behavior.
But it can re-use this attached pipe if multi urb was queued.
This patch implements it.
Signed-off-by: Kuninori Morimoto
---
drivers/usb/renesas_usbhs/mod_host.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/mod_host.c
b/drivers/usb/renesas_usbhs/mod_host.c
index 9bc8c2b..3d3cd6c 100644
--- a/drivers/usb/renesas_usbhs/mod_host.c
+++ b/drivers/usb/renesas_usbhs/mod_host.c
@@ -85,6 +85,7 @@ struct usbhsh_ep {
struct usbhsh_device*udev; /* attached udev */
struct usb_host_endpoint *ep;
struct list_headep_list; /* list to usbhsh_device */
+ unsigned intcounter; /* pipe attach counter */
};
#define USBHSH_DEVICE_MAX 10 /* see DEVADDn / DCPMAXP / PIPEMAXP */
@@ -271,8 +272,12 @@ static int usbhsh_pipe_attach(struct usbhsh_hpriv *hpriv,
/ spin lock /
usbhs_lock(priv, flags);
- if (unlikely(usbhsh_uep_to_pipe(uep))) {
- dev_err(dev, "uep already has pipe\n");
+ /*
+* if uep has been attached to pipe,
+* reuse it
+*/
+ if (usbhsh_uep_to_pipe(uep)) {
+ ret = 0;
goto usbhsh_pipe_attach_done;
}
@@ -320,6 +325,9 @@ static int usbhsh_pipe_attach(struct usbhsh_hpriv *hpriv,
}
usbhsh_pipe_attach_done:
+ if (0 == ret)
+ uep->counter++;
+
usbhs_unlock(priv, flags);
/ spin unlock **/
@@ -346,7 +354,7 @@ static void usbhsh_pipe_detach(struct usbhsh_hpriv *hpriv,
if (unlikely(!pipe)) {
dev_err(dev, "uep doens't have pipe\n");
- } else {
+ } else if (1 == uep->counter--) { /* last user */
struct usb_host_endpoint *ep = usbhsh_uep_to_ep(uep);
struct usbhsh_device *udev = usbhsh_uep_to_udev(uep);
@@ -391,6 +399,7 @@ static int usbhsh_endpoint_attach(struct usbhsh_hpriv
*hpriv,
/*
* init endpoint
*/
+ uep->counter = 0;
INIT_LIST_HEAD(&uep->ep_list);
list_add_tail(&uep->ep_list, &udev->ep_list_head);
@@ -959,7 +968,6 @@ static int usbhsh_urb_enqueue(struct usb_hcd *hcd,
struct usb_host_endpoint *ep = urb->ep;
struct usbhsh_device *new_udev = NULL;
int is_dir_in = usb_pipein(urb->pipe);
- int i;
int ret;
dev_dbg(dev, "%s (%s)\n", __func__, is_dir_in ? "in" : "out");
@@ -1005,13 +1013,7 @@ static int usbhsh_urb_enqueue(struct usb_hcd *hcd,
* attach pipe to endpoint
* see [image of mod_host]
*/
- for (i = 0; i < 1024; i++) {
- ret = usbhsh_pipe_attach(hpriv, urb);
- if (ret < 0)
- msleep(100);
- else
- break;
- }
+ ret = usbhsh_pipe_attach(hpriv, urb);
if (ret < 0) {
dev_err(dev, "pipe attach failed\n");
goto usbhsh_urb_enqueue_error_free_endpoint;
--
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] hid: usbhid: add quirk for SB arena headset v2
On Mon, 5 Nov 2012, Chris J Arges wrote: > >> When an SB Arena USB headset is plugged in, it registers the volume > >> keys on the headset as a keyboard and continually sends events causing > >> issues with normal keyboard input. This quirk disables the volume keys. > > > > I don't know how the device looks like, but wouldn't it make more sense to > > actually remap the bogus keys it's sending to produce KEY_VOLUMEUP and > > KEY_VOLUMEDOWN? > > > > Yes, if I can track this hardware down or get data I'll fix it like > this. This happened to be a do-no harm fix for the following bug: > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1007575 You should be able to obtain it easily either by running evtest on corresponding /dev/input/eventX node, or by looking into debugfs hid//events file. -- Jiri Kosina SUSE Labs -- 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 fixes for v3.7-rc5
Hi Greg, I have one extra fix for this -rc cycle. Hopefully this is the last one. Let me know if you prefer not to apply this build fix. cheers The following changes since commit f6bc8c29383456b89ac1b6f1aa768d195670fb53: usb: otg: Fix build errors if USB_MUSB_OMAP2PLUS is selected as module (2012-10-30 14:37:07 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.7-rc5 for you to fetch changes up to a81ec4b14810b1590c17e32a118d55d7b50e0413: usb: gadget: file_storage: fix build error by selecting libcomposite (2012-10-31 16:38:08 +0200) usb: fixes for v3.7-rc5 A single build fix for file_storage gadget found by Randy's and Stephen's randconfig builds. This isn't really major because file_storage gadget will be removed on v3.8, but we still need to keep it building for the time being. Sebastian Andrzej Siewior (1): usb: gadget: file_storage: fix build error by selecting libcomposite drivers/usb/gadget/Kconfig | 1 + 1 file changed, 1 insertion(+) -- 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: ncm: correct endianess conversion
On Sun, Nov 04, 2012 at 03:30:21PM +0100, Dmytro Milinevskyy wrote:
> Convert USB descriptor's fields to CPU byte order before using locally in USB
> NCM gadget driver.
> Tested on MIPS32 big-endian device.
>
> Signed-off-by: Dmytro Milinevskyy
doesn't apply:
$ patch -p1 --dry-run < patch.diff
patching file drivers/usb/gadget/f_ncm.c
patch: malformed patch at line 31: @@ -869,15 +869,19 @@ static struct
sk_buff *ncm_wrap_ntb(struct gether *port,
can you use git-send-email ?
> ---
> drivers/usb/gadget/f_ncm.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
> index b651b52..a7cdd47 100644
> --- a/drivers/usb/gadget/f_ncm.c
> +++ b/drivers/usb/gadget/f_ncm.c
> @@ -102,7 +102,7 @@ static inline unsigned ncm_bitrate(struct usb_gadget *g)
>USB_CDC_NCM_NTB32_SUPPORTED)
> static struct usb_cdc_ncm_ntb_parameters ntb_parameters = {
> - .wLength = sizeof ntb_parameters,
> + .wLength = cpu_to_le16(sizeof(ntb_parameters)),
> .bmNtbFormatsSupported = cpu_to_le16(FORMATS_SUPPORTED),
> .dwNtbInMaxSize = cpu_to_le32(NTB_DEFAULT_IN_SIZE),
> .wNdpInDivisor = cpu_to_le16(4),
> @@ -869,15 +869,19 @@ static struct sk_buff *ncm_wrap_ntb(struct gether *port,
> struct sk_buff *skb2;
> int ncb_len = 0;
> __le16 *tmp;
> - int div = ntb_parameters.wNdpInDivisor;
> - int rem = ntb_parameters.wNdpInPayloadRemainder;
> + int div;
> + int rem;
> int pad;
> - int ndp_align = ntb_parameters.wNdpInAlignment;
> + int ndp_align;
> int ndp_pad;
> unsignedmax_size = ncm->port.fixed_in_len;
> struct ndp_parser_opts *opts = ncm->parser_opts;
> unsignedcrc_len = ncm->is_crc ? sizeof(uint32_t) : 0;
> + div = le16_to_cpu(ntb_parameters.wNdpInDivisor);
> + rem = le16_to_cpu(ntb_parameters.wNdpInPayloadRemainder);
> + ndp_align = le16_to_cpu(ntb_parameters.wNdpInAlignment);
> +
> ncb_len += opts->nth_size;
> ndp_pad = ALIGN(ncb_len, ndp_align) - ncb_len;
> ncb_len += ndp_pad;
> --
> 1.8.0
>
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: > From: Michal Nazarewicz > > The File-backed Storage Gadget (g_file_storage) is being removed, since > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit > changes defconfigs point to the new gadget. > > Signed-off-by: Michal Nazarewicz I need more Acks here. Only got one from Nicolas. Anyone else ? > --- > arch/arm/configs/afeb9260_defconfig|2 +- > arch/arm/configs/at91sam9260_defconfig |2 +- > arch/arm/configs/at91sam9261_defconfig |2 +- > arch/arm/configs/at91sam9263_defconfig |2 +- > arch/arm/configs/at91sam9g20_defconfig |2 +- > arch/arm/configs/corgi_defconfig |2 +- > arch/arm/configs/davinci_all_defconfig |2 +- > arch/arm/configs/h7202_defconfig |3 +-- > arch/arm/configs/magician_defconfig|2 +- > arch/arm/configs/mini2440_defconfig|2 +- > arch/arm/configs/omap1_defconfig |3 +-- > arch/arm/configs/prima2_defconfig |1 - > arch/arm/configs/spitz_defconfig |2 +- > arch/arm/configs/stamp9g20_defconfig |2 +- > arch/arm/configs/viper_defconfig |2 +- > arch/arm/configs/zeus_defconfig|2 +- > arch/avr32/configs/atngw100_defconfig |2 +- > arch/avr32/configs/atngw100_evklcd100_defconfig|2 +- > arch/avr32/configs/atngw100_evklcd101_defconfig|2 +- > arch/avr32/configs/atngw100_mrmt_defconfig |2 +- > arch/avr32/configs/atngw100mkii_defconfig |2 +- > .../avr32/configs/atngw100mkii_evklcd100_defconfig |2 +- > .../avr32/configs/atngw100mkii_evklcd101_defconfig |2 +- > arch/avr32/configs/atstk1002_defconfig |2 +- > arch/avr32/configs/atstk1003_defconfig |2 +- > arch/avr32/configs/atstk1004_defconfig |2 +- > arch/avr32/configs/atstk1006_defconfig |2 +- > arch/avr32/configs/favr-32_defconfig |2 +- > arch/avr32/configs/hammerhead_defconfig|2 +- > arch/blackfin/configs/CM-BF527_defconfig |2 +- > arch/blackfin/configs/CM-BF548_defconfig |2 +- > arch/blackfin/configs/CM-BF561_defconfig |2 +- > arch/mips/configs/bcm47xx_defconfig|2 +- > arch/mips/configs/mtx1_defconfig |2 +- > arch/sh/configs/ecovec24_defconfig |2 +- > arch/sh/configs/se7724_defconfig |2 +- > 37 files changed, 35 insertions(+), 39 deletions(-) > > diff --git a/arch/arm/configs/afeb9260_defconfig > b/arch/arm/configs/afeb9260_defconfig > index c285a9d..a8dbc1e 100644 > --- a/arch/arm/configs/afeb9260_defconfig > +++ b/arch/arm/configs/afeb9260_defconfig > @@ -79,7 +79,7 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_RTC_CLASS=y > CONFIG_RTC_DEBUG=y > diff --git a/arch/arm/configs/at91sam9260_defconfig > b/arch/arm/configs/at91sam9260_defconfig > index 505b376..0ea5d2c 100644 > --- a/arch/arm/configs/at91sam9260_defconfig > +++ b/arch/arm/configs/at91sam9260_defconfig > @@ -75,7 +75,7 @@ CONFIG_USB_STORAGE_DEBUG=y > CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_AT91SAM9=y > diff --git a/arch/arm/configs/at91sam9261_defconfig > b/arch/arm/configs/at91sam9261_defconfig > index 1e8712e..c87beb9 100644 > --- a/arch/arm/configs/at91sam9261_defconfig > +++ b/arch/arm/configs/at91sam9261_defconfig > @@ -125,7 +125,7 @@ CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_ETH=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_MMC=y > CONFIG_MMC_ATMELMCI=m > diff --git a/arch/arm/configs/at91sam9263_defconfig > b/arch/arm/configs/at91sam9263_defconfig > index d2050ca..c5212f4 100644 > --- a/arch/arm/configs/at91sam9263_defconfig > +++ b/arch/arm/configs/at91sam9263_defconfig > @@ -133,7 +133,7 @@ CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_ETH=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_MMC=y > CONFIG_SDIO_UART=m > diff --git a/arch/arm/configs/at91sam9g20_defconfig > b/arch/arm/configs/at91sam9g20_defconfig > index e1b0e80..3b18810 100644 > --- a/arch/arm/configs/at91sam9g20_defconfig > +++ b/arch/arm/configs/at91sam9g20_defconfig > @@ -96,7 +96,7 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m >
Re: [PATCHv2 2/6] usb: gadget: Remove File-backed Storage Gadget (g_file_storage).
On Fri, Nov 02, 2012 at 02:31:51PM +0100, Michal Nazarewicz wrote: > From: Michal Nazarewicz > > The File-backed Storage Gadget (g_file_storage) gadget has been replaced > with Mass Storage Gadget (g_mass_storage) which uses the composite > framework. This commit removes g_file_storage (and most references to it). > > Signed-off-by: Michal Nazarewicz > Acked-by: Alan Stern Doesn't apply. Please rebase on my "gadget" branch: $ patch -p1 --dry-run < patch.diff patching file Documentation/DocBook/gadget.tmpl patching file Documentation/usb/mass-storage.txt patching file drivers/usb/gadget/Kconfig Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file drivers/usb/gadget/Kconfig.rej patching file drivers/usb/gadget/Makefile patching file drivers/usb/gadget/file_storage.c patching file drivers/usb/gadget/net2280.c patching file drivers/usb/gadget/pxa27x_udc.h patching file drivers/usb/musb/musb_gadget.c Hunk #1 FAILED at 709. Hunk #2 FAILED at 744. 2 out of 2 hunks FAILED -- saving rejects to file drivers/usb/musb/musb_gadget.c.rej -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] usb: renesas_usbhs: use transfer counter if IN direction bulk pipe
On Tue, Nov 06, 2012 at 12:11:43AM -0800, Kuninori Morimoto wrote: > received data will break if it was bulk pipe and large data size, > because pipe kept BUF PID even though it doesn't have enough buffer. > To avoid this issue, renesas_usbhs can use transfer counter. > Pipe PID will be NAK if it didn't have enough buffer by this patch. > > renesas_usbhs has strange address mapping. > Thus, it is difficult to calculate transfer counter setting address. > This patch use fixed table for it. > > Signed-off-by: Kuninori Morimoto this one fails to apply. Please rebase on my gadget branch: $ patch -p1 --dry-run < patch.diff patching file drivers/usb/renesas_usbhs/fifo.c Hunk #3 FAILED at 798. 1 out of 3 hunks FAILED -- saving rejects to file drivers/usb/renesas_usbhs/fifo.c.rej patching file drivers/usb/renesas_usbhs/pipe.c patching file drivers/usb/renesas_usbhs/pipe.h -- balbi signature.asc Description: Digital signature
RE: [PATCH V3 3/4] usb: Create link files between child device and usb port device.
Hi Alan:
Thanks for your review. I will update soon.
Best Regards
Tianyu Lan
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Monday, November 05, 2012 10:55 PM
To: Lan, Tianyu
Cc: gre...@linuxfoundation.org; sarah.a.sh...@linux.intel.com;
linux-usb@vger.kernel.org
Subject: Re: [PATCH V3 3/4] usb: Create link files between child device and usb
port device.
On Sun, 4 Nov 2012, Lan Tianyu wrote:
> To show the relationship between usb port and child device, add link
> file "port" under usb device's sysfs directoy and "device" under usb
> port device's sysfs directory. They are linked to each other.
>
> Signed-off-by: Lan Tianyu
> ---
> drivers/usb/core/hub.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> 706db5c..a08a018 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2015,6 +2015,8 @@ void usb_disconnect(struct usb_device **pdev) {
> struct usb_device *udev = *pdev;
> struct usb_hub *hub = hdev_to_hub(udev);
> + struct usb_port *port_dev =
> + hdev_to_hub(udev->parent)->ports[udev->portnum - 1];
This is bad. It will crash if udev->parent is NULL.
> int i;
>
> /* mark the device as inactive, so any further urb submissions for
> @@ -2041,6 +2043,8 @@ void usb_disconnect(struct usb_device **pdev)
> usb_disable_device(udev, 0);
> usb_hcd_synchronize_unlinks(udev);
>
> + sysfs_remove_link(&udev->dev.kobj, "port");
> + sysfs_remove_link(&port_dev->dev.kobj, "device");
You might as well avoid defining port_dev until here.
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
Re: [PATCH v4 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hi, On Thu, Oct 25, 2012 at 08:24:09PM +0530, kishon wrote: > Hi Benoit, > > On Thursday 25 October 2012 07:11 PM, Benoit Cousson wrote: > >Hi Kishon, > > > >On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote: > >>Includes few minor fixes in dwc3-omap like populating the compatible > >>string in a correct way, extracting the utmi-mode property properly and > >>changing the index of get_irq since irq of core is removed from hwmod > >>entry. > >>Also updated the documentation with dwc3-omap device tree binding > >>information. > >> > >>Signed-off-by: Kishon Vijay Abraham I > >>--- > >> drivers/usb/dwc3/dwc3-omap.c | 14 ++ > >> 1 file changed, 6 insertions(+), 8 deletions(-) > >> > >>diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c > >>index b84ddf3..10aad46 100644 > >>--- a/drivers/usb/dwc3/dwc3-omap.c > >>+++ b/drivers/usb/dwc3/dwc3-omap.c > >>@@ -318,11 +318,10 @@ static int __devinit dwc3_omap_probe(struct > >>platform_device *pdev) > >>struct resource *res; > >>struct device *dev = &pdev->dev; > >> > >>- int size; > >>int ret = -ENOMEM; > >>int irq; > >> > >>- const u32 *utmi_mode; > >>+ u32 utmi_mode; > >>u32 reg; > >> > >>void __iomem*base; > >>@@ -336,13 +335,13 @@ static int __devinit dwc3_omap_probe(struct > >>platform_device *pdev) > >> > >>platform_set_drvdata(pdev, omap); > >> > >>- irq = platform_get_irq(pdev, 1); > >>+ irq = platform_get_irq(pdev, 0); > > > >Cannot you use the name of the resource to avoid that kind of trick? > > *name* is mostly used when we have multiple resource of the same type > for a single device. Previously we were clubbing wrapper resources > and core resources in a single hwmod device, so we had to use > different indexing. > But with dt we have separated those under two different devices and > hence we can always use index as '0'. But if you think we should have > *name*, let me know, I can resend this patch :-) since there were no more replies here, i'm assuming Benoit's happy with Kishon's explanation. Will apply this series as is. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 0/7] usb: dwc3-omap: add dt support
On Mon, Oct 15, 2012 at 06:57:53PM +0530, Kishon Vijay Abraham I wrote:
> This patch series adds dt support to dwc3 core and fixes few minor
> stuff in dwc3-omap glue to get dwc3 working.
>
> While at that it also uses *of_platform* to create the child device
> (dwc3-core) and fixes to use runtime API's to enable clock and write
> to SYSCONFIG register.
>
> Changes from v3:
> * rebased to latest commit in balbi's tree
> * Fixed few typos in the commit log
> * Added *extern* keyword for dwc3_omap_mailbox function declaration
>
> Changes from v2:
> * Fixed Sergei comment to use of_property_read_u32 insted of of_get_property
>
> Changes from v1:
> * made device_for_each_child() as a seperate patch
> * made all other minor fixes wrt typos and function renames
>
> This patch series is developed on:
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git dwc3
please rebase on my dwc3 branch. Because of commit belo, patches 1 and 2
won't apply:
commit 124dafde8f8174caf5cef1c3eaba001657d66f4f
Author: Sebastian Andrzej Siewior
Date: Mon Oct 29 18:09:53 2012 +0100
usb: dwc3: remove custom unique id handling
The lockless implementation of the unique id is quite impressive (:P)
but dirver's core can handle it, we can remove it and make our code a
little smaller.
Cc: Anton Tikhomirov
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b923183..d8d327a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -66,45 +66,6 @@ MODULE_PARM_DESC(maximum_speed, "Maximum supported speed.");
/* --
*/
-#define DWC3_DEVS_POSSIBLE 32
-
-static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
-
-int dwc3_get_device_id(void)
-{
- int id;
-
-again:
- id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
- if (id < DWC3_DEVS_POSSIBLE) {
- int old;
-
- old = test_and_set_bit(id, dwc3_devs);
- if (old)
- goto again;
- } else {
- pr_err("dwc3: no space for new device\n");
- id = -ENOMEM;
- }
-
- return id;
-}
-EXPORT_SYMBOL_GPL(dwc3_get_device_id);
-
-void dwc3_put_device_id(int id)
-{
- int ret;
-
- if (id < 0)
- return;
-
- ret = test_bit(id, dwc3_devs);
- WARN(!ret, "dwc3: ID %d not in use\n", id);
- smp_mb__before_clear_bit();
- clear_bit(id, dwc3_devs);
-}
-EXPORT_SYMBOL_GPL(dwc3_put_device_id);
-
void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
{
u32 reg;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 243affc..4999563 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -868,7 +868,4 @@ void dwc3_host_exit(struct dwc3 *dwc);
int dwc3_gadget_init(struct dwc3 *dwc);
void dwc3_gadget_exit(struct dwc3 *dwc);
-extern int dwc3_get_device_id(void);
-extern void dwc3_put_device_id(int id);
-
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..586f105 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -94,7 +94,6 @@ static int __devinit dwc3_exynos_probe(struct platform_device
*pdev)
struct dwc3_exynos *exynos;
struct clk *clk;
- int devid;
int ret = -ENOMEM;
exynos = kzalloc(sizeof(*exynos), GFP_KERNEL);
@@ -105,20 +104,16 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, exynos);
- devid = dwc3_get_device_id();
- if (devid < 0)
- goto err1;
-
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(&pdev->dev, "couldn't register PHYs\n");
goto err1;
}
- dwc3 = platform_device_alloc("dwc3", devid);
+ dwc3 = platform_device_alloc("dwc3", PLATFORM_DEVID_AUTO);
if (!dwc3) {
dev_err(&pdev->dev, "couldn't allocate dwc3 device\n");
- goto err2;
+ goto err1;
}
clk = clk_get(&pdev->dev, "usbdrd30");
@@ -170,8 +165,6 @@ err4:
clk_put(clk);
err3:
platform_device_put(dwc3);
-err2:
- dwc3_put_device_id(devid);
err1:
kfree(exynos);
err0:
@@ -187,8 +180,6 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
- dwc3_put_device_id(exynos->dwc3->id);
-
if (pdata && pdata->phy_exit)
pdata->phy_exit(pdev, pdata->phy_type);
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index ee57a10..900d435 100644
--- a/drivers/
Re: [PATCH] cppi_dma: export cppi_interrupt()
Hello. On 06-11-2012 6:21, Greg KH wrote: Now that DaVinci glue layer can be modular, we must export cppi_interrupt() that it may call... Signed-off-by: Sergei Shtylyov Cc: sta...@vger.kernel.org # 3.0+ Why would we need to export this for such old kernels? I haven't heard of any build problems due to this patch not being present, do you have a pointer to them? I haven't heard of any problems either until I tried building DaVinci glue layer modular myself, just yesterday. I have traced the issue back to 3.0, so I tagged it accordingly. It's on you discretion whether to apply this to stable kernels, of course. BTW, there's also section mismatch in this driver which I'll try to investigate today... greg k-h 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
Re: [GIT PULL] USB fixes for v3.7-rc5
On Tue, Nov 06, 2012 at 01:16:17PM +0200, Felipe Balbi wrote: > Hi Greg, > > I have one extra fix for this -rc cycle. Hopefully this is the last one. > > Let me know if you prefer not to apply this build fix. I'd prefer not, if at all possible. Patches to fix 'randconfig' breakage are very low priority to me, so having this go into 3.8 would be better. sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB fixes for v3.7-rc5
Hi, On Tue, Nov 06, 2012 at 01:29:45PM +0100, Greg KH wrote: > On Tue, Nov 06, 2012 at 01:16:17PM +0200, Felipe Balbi wrote: > > Hi Greg, > > > > I have one extra fix for this -rc cycle. Hopefully this is the last one. > > > > Let me know if you prefer not to apply this build fix. > > I'd prefer not, if at all possible. Patches to fix 'randconfig' > breakage are very low priority to me, so having this go into 3.8 would > be better. > > sorry, no problems ;-) Then I'll just drop this since on v3.8 g_file_storage will be removed. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example
On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
> OMAP2+ family of devices are now obtaining resources via DT, earlier
> it was obtained from hwmod. Update binding document accrodingly, while
> at it add example.
>
> Signed-off-by: Afzal Mohammed
> ---
> .../devicetree/bindings/usb/am33xx-usb.txt | 21
> +
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> index a922505..6b7e3bd 100644
> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> @@ -1,5 +1,7 @@
> AM33XX MUSB GLUE
> - compatible : Should be "ti,musb-am33xx"
> + - reg : offset and length of register sets, first usbss, then for musb
> instances
> + - interrupts : usbss, musb instance interrupts in order
> - ti,hwmods : must be "usb_otg_hs"
> - multipoint : Should be "1" indicating the musb controller supports
> multipoint. This is a MUSB configuration-specific setting.
> @@ -12,3 +14,22 @@ AM33XX MUSB GLUE
> represents PERIPHERAL.
> - power : Should be "250". This signifies the controller can supply upto
> 500mA when operating in host mode.
> +
> +Example:
> +
> +usb_otg_hs@4740 {
this should be usb@4740.
> + compatible = "ti,musb-am33xx";
> + reg = <0x4740 0x1000/* usbss */
> +0x47401000 0x800 /* musb instance 0 */
> +0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17/* usbss */
> + 18/* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> +};
> --
> 1.7.12
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend
On 6 November 2012 01:45, Ming Lei wrote: > This patch fixes memory leak in smsc95xx_suspend. Good spot, thanks! Note that check_warn_return just above your kfree can cause early return in the error case, which would still leak filter_mask, so we might want to explicitly expand that instance of the helper macro. > Also, it isn't necessary to bother mm to allocate 8bytes/16byte, > and we can use stack variable safely. Acked-By: Steve Glendinning -- 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 0/4] Adding usb2.0 host-phy support for exynos5250
Hi, On Mon, Oct 29, 2012 at 07:12:36PM +0530, Vivek Gautam wrote: > This patchset is based on the work by Praveen Paneri for > samsung-usbphy driver: > http://comments.gmane.org/gmane.linux.kernel.samsung-soc/12653 > > Changes from v2: > - Using "EXYNOS5_PHY_" as common prefix along with exact names for >PHY SFRs for register definitions > - Using register names with bit macros to make things more clear. > - Removed parentheses around 0x230 in definition for EXYNOS5_USB_CFG >in [patch 2/4 v2]. > > Tested on smdk5250 target with usb-next branch along with arch patches > for exynos5250: > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13042 > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13048 > > Vivek Gautam (4): > usb: phy: samsung: Add host phy support to samsung-phy driver > ARM: Exynos5250: Enabling samsung-usbphy driver > USB: ehci-s5p: Add phy driver support > USB: ohci-exynos: Add phy driver support I really don't know what to do with this series. I know it depends on the other PHY changes which I have in my queue, but it touches too much arch specific code, plus the USB Host code which I don't maintain. On top of all that, I have no platform to test these patches, which makes me even more worried about signing off under this series ;-) Would it be ok if we delay this to v3.9 ? At least the dependency with other PHY changes would be dropped by then. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: musb: ux500: fix 'musbid' undeclared error in ux500_remove()
On Wed, Oct 31, 2012 at 08:51:39PM +0530, Rajaram R wrote: > On Wed, Oct 31, 2012 at 8:00 PM, Felipe Balbi wrote: > > Hi, > > > > On Wed, Oct 31, 2012 at 07:45:53PM +0530, Rajaram R wrote: > >> On Tue, Oct 23, 2012 at 11:42 AM, Wei Yongjun wrote: > >> > commit 65b3d52d02a558fbfe08e43688e15390c5ab3067 > >> > (usb: musb: add musb_ida for multi instance support) > >> > used musbid in ux500_remove() but nerver declared it. > >> > >> The above message doesnot match with your fix. You say ux500_remove is > >> using musbhid but build error is in probe. > >> > >> I also dont see anywhere in the code we use this variable musbid. > > > > -ECONFUSED: > > :-) No.. This patch could have been avoided if a build test was done > when the original patch pushed this change... !! > > Anyway I can send a patch correcting the text if required... which text ? The commit log ? that can't be fixed ;-) -- balbi signature.asc Description: Digital signature
[ANNOUNCE] Queue empty
Hi guys, this is just a quick note to let you know that I have nothing pending in my queue anymore. That means both fixes for this -rc (which is already too late for anyway) and code for v3.8 merge window. If I have missed anything, please resend with a subject such as 'PATCH/RESEND' so I know what it means. Some of the patches I have asked for newer versions, and I will wait until -rc5 before sending my pull request to Greg but not much later than that, since I like my code to soak in linux-next and Greg's usb-next branches for at least one week before it gets merged upstream. Cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] USB: EHCI: prepare to make ehci-hcd a library module
On Thu, Nov 01, 2012 at 11:12:58AM -0400, Alan Stern wrote:
> This patch (as1624) prepares ehci-hcd for being split up into a core
> library and separate platform driver modules. A generic
> ehci_hc_driver structure is created, containing all the "standard"
> values, and a new mechanism is added whereby a driver module can
> specify a set of overrides to those values. In addition the
> ehci_setup(), ehci_suspend(), and ehci_resume() routines need to be
> EXPORTed for use by the drivers.
>
> As a side effect of this change, a few routines no longer need to be
> marked __maybe_unused.
>
> Signed-off-by: Alan Stern
> CC: Felipe Balbi
>
> ---
>
> drivers/usb/host/ehci-hcd.c | 73
> ++--
> drivers/usb/host/ehci-hub.c |6 +--
> drivers/usb/host/ehci.h | 17 ++
> 3 files changed, 89 insertions(+), 7 deletions(-)
>
> Index: usb-3.7/drivers/usb/host/ehci.h
> ===
> --- usb-3.7.orig/drivers/usb/host/ehci.h
> +++ usb-3.7/drivers/usb/host/ehci.h
> @@ -781,4 +781,21 @@ static inline u32 hc32_to_cpup (const st
>
> /*-*/
>
> +/* Declarations of things exported for use by ehci platform drivers */
> +
> +struct ehci_driver_overrides {
> + const char *product_desc;
just one question: do we really need to allow for product_desc override?
Isn't it enough to just call it "EHCI Host Controller" or "Enhanced Host
Controller Interface"
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend
On Tue, Nov 6, 2012 at 9:20 PM, Steve Glendinning wrote: > On 6 November 2012 01:45, Ming Lei wrote: >> This patch fixes memory leak in smsc95xx_suspend. > > Good spot, thanks! > > Note that check_warn_return just above your kfree can cause early > return in the error case, which would still leak filter_mask, so we > might want to explicitly expand that instance of the helper macro. OK, will update the patch. BTW, I just saw the smsc95xx datasheet and the vendor's driver source code, and found the chip supports runtime PM well (remote wakeup on 'good packet' or link change), so do you plan to implement that? Thanks, -- Ming Lei -- 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 0/4] Adding usb2.0 host-phy support for exynos5250
Hi Balbi, On Tue, Nov 6, 2012 at 6:44 PM, Felipe Balbi wrote: > Hi, > > On Mon, Oct 29, 2012 at 07:12:36PM +0530, Vivek Gautam wrote: >> This patchset is based on the work by Praveen Paneri for >> samsung-usbphy driver: >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/12653 >> >> Changes from v2: >> - Using "EXYNOS5_PHY_" as common prefix along with exact names for >>PHY SFRs for register definitions >> - Using register names with bit macros to make things more clear. >> - Removed parentheses around 0x230 in definition for EXYNOS5_USB_CFG >>in [patch 2/4 v2]. >> >> Tested on smdk5250 target with usb-next branch along with arch patches >> for exynos5250: >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13042 >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13048 >> >> Vivek Gautam (4): >> usb: phy: samsung: Add host phy support to samsung-phy driver >> ARM: Exynos5250: Enabling samsung-usbphy driver >> USB: ehci-s5p: Add phy driver support >> USB: ohci-exynos: Add phy driver support > > I really don't know what to do with this series. I know it depends on > the other PHY changes which I have in my queue, but it touches too much > arch specific code, plus the USB Host code which I don't maintain. > True, that it has dependency on the work by Praveen Paneri for samsung-usbphy driver plus the arch support patches. This is based on usb-next branch, so the host-code can be taken care of ? > On top of all that, I have no platform to test these patches, which > makes me even more worried about signing off under this series ;-) > The patches have however been tested. The two patches: "USB: ehci-s5p: Add phy driver support", "USB: ohci-exynos: Add phy driver support" have been acked by Jingoo Han based on the patch-series. Possibly Kukjin Kim can help on this one. Kukjin, Can we have a thought on this please. > Would it be ok if we delay this to v3.9 ? At least the dependency with > other PHY changes would be dropped by then. > This changes are almost in shape ;-) and i am updating the next patchset soon. If possible can we try to get this in 3.8 please. :-) > -- > balbi -- Thanks & Regards Vivek -- 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] usb: musb: dsps: dt binding - add resources, example
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed
---
v2: node name changed to "usb"
.../devicetree/bindings/usb/am33xx-usb.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..ea840f7 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be "ti,musb-am33xx"
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be "usb_otg_hs"
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb@4740 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800>; /* musb instance 1 */
+ interrupts = <17/* usbss */
+ 18/* musb instance 0 */
+ 19>; /* musb instance 1 */
+ multipoint = <1>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ port0-mode = <3>;
+ port1-mode = <3>;
+ power = <250>;
+ ti,hwmods = "usb_otg_hs";
+};
--
1.7.12
--
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 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend
> BTW, I just saw the smsc95xx datasheet and the vendor's driver > source code, and found the chip supports runtime PM well > (remote wakeup on 'good packet' or link change), so do you > plan to implement that? Yes, I do plan to implement this. Note that this feature is only supported on some product variants, for example LAN9500A, so it won't benefit all smsc95xx users. -- 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 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend
On Tue, Nov 6, 2012 at 9:58 PM, Steve Glendinning wrote: >> BTW, I just saw the smsc95xx datasheet and the vendor's driver >> source code, and found the chip supports runtime PM well >> (remote wakeup on 'good packet' or link change), so do you >> plan to implement that? > > Yes, I do plan to implement this. Good news, :-) > Note that this feature is only > supported on some product variants, for example LAN9500A, so it won't > benefit all smsc95xx users. Right. Looks remote wakeup on “Link Status Change” (SUSPEND1) can be supported by all smsc95xx , and remote wakeup on 'good packets'(SUSPEND3) is only supported by LAN9500A. Thanks, -- Ming Lei Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example
Hi Balbi,
On Tuesday 06 November 2012 06:32 PM, Felipe Balbi wrote:
On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
+Example:
+
+usb_otg_hs@4740 {
this should be usb@4740.
Updated version with the above change has been posted.
Regards
Afzal
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/5] Adding usb2.0 host-phy support for exynos5250
This patchset is based on the work by Praveen Paneri for samsung-usbphy driver: http://www.spinics.net/lists/linux-usb/msg73518.html Changes from v3: - Moved enums S5P_USB_PHY_DEVICE, S5P_USB_PHY_HOST from machine to file include/linux/usb/samsung_usb_phy.h as USB_PHY_TYPE_DEVICE and USB_PHY_TYPE_HOST to make it more generic. Further resolve its dependencies. - Introduced a function 'samsung_usbphy_set_type()' which takes care of setting up the phy_type: HOST/DEVICE. This function can be called by host/otg drivers to setup phy_type prior to handling the respective PHYs. - Added an error-path for HOST type phy in s5p_usb_phy_pmu_isolation() for 'mach-s3c64xx'. - Moving to PHY driver as default for ehci-s5p and ohci-exynos, and only when failed fall back to plat-data. - Added samsung_usbphy_set_type() prior to doing usb_phy_init() or usb_phy_shutdown() so that appropriate PHY gets init or shutdown. Tested on smdk5250 target with usb-next branch along with arch patches for exynos5250: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13042 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13048 Vivek Gautam (5): ARM: EXYNOS: Update & move usb-phy types to generic include layer usb: phy: samsung: Add host phy support to samsung-phy driver ARM: Exynos5250: Enabling samsung-usbphy driver USB: ehci-s5p: Add phy driver support USB: ohci-exynos: Add phy driver support .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- arch/arm/boot/dts/exynos5250.dtsi |5 + arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/include/mach/map.h|1 + arch/arm/mach-exynos/mach-exynos5-dt.c |9 + arch/arm/mach-exynos/setup-usb-phy.c | 52 ++- arch/arm/mach-s3c64xx/setup-usb-phy.c | 18 +- arch/arm/mach-s5pv210/setup-usb-phy.c |5 +- arch/arm/plat-samsung/include/plat/usb-phy.h |8 +- drivers/usb/host/ehci-s5p.c| 71 +++- drivers/usb/host/ohci-exynos.c | 71 +++- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 383 ++-- include/linux/platform_data/samsung-usbphy.h |4 +- include/linux/usb/samsung_usb_phy.h| 30 ++ 15 files changed, 571 insertions(+), 101 deletions(-) create mode 100644 include/linux/usb/samsung_usb_phy.h -- 1.7.6.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 v4 1/5] ARM: EXYNOS: Update & move usb-phy types to generic include layer
Updating the names of usb-phy types to more generic names:
USB_PHY_TYPE_DEIVCE & USB_PHY_TYPE_HOST; and further update its
dependencies.
Signed-off-by: Praveen Paneri
Signed-off-by: Vivek Gautam
---
arch/arm/mach-exynos/setup-usb-phy.c |9 +
arch/arm/mach-s5pv210/setup-usb-phy.c|5 +++--
arch/arm/plat-samsung/include/plat/usb-phy.h |5 -
drivers/usb/host/ehci-s5p.c |9 +
drivers/usb/host/ohci-exynos.c |9 +
include/linux/usb/samsung_usb_phy.h | 17 +
6 files changed, 35 insertions(+), 19 deletions(-)
create mode 100644 include/linux/usb/samsung_usb_phy.h
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index 1c62d20..c77f51b 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -204,9 +205,9 @@ static int exynos4210_usb_phy1_exit(struct platform_device
*pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_init(pdev);
- else if (type == S5P_USB_PHY_HOST)
+ else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_init(pdev);
return -EINVAL;
@@ -214,9 +215,9 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return exynos4210_usb_phy0_exit(pdev);
- else if (type == S5P_USB_PHY_HOST)
+ else if (type == USB_PHY_TYPE_HOST)
return exynos4210_usb_phy1_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/mach-s5pv210/setup-usb-phy.c
b/arch/arm/mach-s5pv210/setup-usb-phy.c
index be39cf4..cdb80a5 100644
--- a/arch/arm/mach-s5pv210/setup-usb-phy.c
+++ b/arch/arm/mach-s5pv210/setup-usb-phy.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -75,7 +76,7 @@ static int s5pv210_usb_otgphy_exit(struct platform_device
*pdev)
int s5p_usb_phy_init(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_init(pdev);
return -EINVAL;
@@ -83,7 +84,7 @@ int s5p_usb_phy_init(struct platform_device *pdev, int type)
int s5p_usb_phy_exit(struct platform_device *pdev, int type)
{
- if (type == S5P_USB_PHY_DEVICE)
+ if (type == USB_PHY_TYPE_DEVICE)
return s5pv210_usb_otgphy_exit(pdev);
return -EINVAL;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h
b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 165ffe7..4e6f370 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -11,11 +11,6 @@
#ifndef __PLAT_SAMSUNG_USB_PHY_H
#define __PLAT_SAMSUNG_USB_PHY_H __FILE__
-enum s5p_usb_phy_type {
- S5P_USB_PHY_DEVICE,
- S5P_USB_PHY_HOST,
-};
-
extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
extern void s5p_usb_phy_pmu_isolation(int on);
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index abc178d..0cd0c7b 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#define EHCI_INSNREG00(base) (base + 0x90)
@@ -164,7 +165,7 @@ static int __devinit s5p_ehci_probe(struct platform_device
*pdev)
}
if (pdata->phy_init)
- pdata->phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
ehci = hcd_to_ehci(hcd);
ehci->caps = hcd->regs;
@@ -198,7 +199,7 @@ static int __devexit s5p_ehci_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
if (pdata && pdata->phy_exit)
- pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci->clk);
@@ -229,7 +230,7 @@ static int s5p_ehci_suspend(struct device *dev)
rc = ehci_suspend(hcd, do_wakeup);
if (pdata && pdata->phy_exit)
- pdata->phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci->clk);
@@ -246,7 +247,7 @@ static int s5p_ehci_resume(struct device *dev)
clk_prepare_enable(s5p_ehci->clk);
if (pdata && pdata->phy_init)
- pdata->phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
/* DMA burst Enable */
writel
[PATCH 2/5] usb: phy: samsung: Add host phy support to samsung-phy driver
This patch adds host phy support to samsung-usbphy.c and
further adds support for samsung's exynos5250 usb-phy.
Signed-off-by: Vivek Gautam
Signed-off-by: Praveen Paneri
---
arch/arm/mach-exynos/setup-usb-phy.c |2 +-
arch/arm/mach-s3c64xx/setup-usb-phy.c| 18 +-
arch/arm/plat-samsung/include/plat/usb-phy.h |2 +-
drivers/usb/phy/Kconfig |2 +-
drivers/usb/phy/samsung-usbphy.c | 383 --
include/linux/platform_data/samsung-usbphy.h |4 +-
include/linux/usb/samsung_usb_phy.h | 13 +
7 files changed, 385 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index c77f51b..39de35f 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -223,7 +223,7 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int type)
return -EINVAL;
}
-void s5p_usb_phy_pmu_isolation(int on)
+void s5p_usb_phy_pmu_isolation(int on, int type)
{
if (on) {
writel(readl(S5P_USBDEVICE_PHY_CONTROL)
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index 3aee778..da134f3 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -10,16 +10,22 @@
*/
#include
+#include
#include
#include
-void s5p_usb_phy_pmu_isolation(int on)
+void s5p_usb_phy_pmu_isolation(int on, int type)
{
- if (on) {
- writel(readl(S3C64XX_OTHERS) & ~S3C64XX_OTHERS_USBMASK,
- S3C64XX_OTHERS);
+ if (type == USB_PHY_TYPE_HOST) {
+ pr_err(" Not a valid phy type\n");
+ return -EINVAL;
} else {
- writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK,
- S3C64XX_OTHERS);
+ if (on) {
+ writel(readl(S3C64XX_OTHERS) & ~S3C64XX_OTHERS_USBMASK,
+ S3C64XX_OTHERS);
+ } else {
+ writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK,
+ S3C64XX_OTHERS);
+ }
}
}
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h
b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 4e6f370..5156343 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -13,6 +13,6 @@
extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
-extern void s5p_usb_phy_pmu_isolation(int on);
+extern void s5p_usb_phy_pmu_isolation(int on, int type);
#endif /* __PLAT_SAMSUNG_USB_PHY_H */
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 313685f..65b9551 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -35,7 +35,7 @@ config MV_U3D_PHY
config SAMSUNG_USBPHY
bool "Samsung USB PHY controller Driver"
- depends on USB_S3C_HSOTG
+ depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS
select USB_OTG_UTILS
help
Enable this to support Samsung USB phy controller for samsung
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 3c84aab..3b4863d 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -5,7 +5,8 @@
*
* Author: Praveen Paneri
*
- * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
+ * Samsung USB-PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and
+ * OHCI-EXYNOS controllers.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -24,7 +25,7 @@
#include
#include
#include
-#include
+#include
#include
/* Register definitions */
@@ -56,6 +57,116 @@
#define RSTCON_HLINK_SWRST (0x1 << 1)
#define RSTCON_SWRST (0x1 << 0)
+/* EXYNOS5 */
+#define EXYNOS5_PHY_HOST_CTRL0 (0x00)
+
+#define HOST_CTRL0_PHYSWRSTALL (0x1 << 31)
+
+#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
+#define HOST_CTRL0_REFCLKSEL(_x) ((_x) << 19)
+#define HOST_CTRL0_REFCLKSEL_XTAL \
+ HOST_CTRL0_REFCLKSEL(0x0)
+#define HOST_CTRL0_REFCLKSEL_EXTL \
+ HOST_CTRL0_REFCLKSEL(0x1)
+#define HOST_CTRL0_REFCLKSEL_CLKCORE \
+ HOST_CTRL0_REFCLKSEL(0x2)
+
+#define HOST_CTRL0_FSEL_MASK (0x7 << 16)
+#define HOST_CTRL0_FSEL(_x)((_x) << 16)
+#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7)
+#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5)
+#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4)
+#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3)
+#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2)
+#d
[PATCH v4 3/5] ARM: Exynos5250: Enabling samsung-usbphy driver
Adding usbphy node for Exynos5250 along with the platform data
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 12 +-
arch/arm/boot/dts/exynos5250.dtsi |5 ++
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |9
arch/arm/mach-exynos/setup-usb-phy.c | 41 ---
arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
7 files changed, 61 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..9e21f4b 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -1,11 +1,19 @@
* Samsung's usb phy transceiver
-The Samsung's phy transceiver is used for controlling usb otg phy for
-s3c-hsotg usb device controller.
+The Samsung's phy transceiver is used for controlling usb phy for
+s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
+across Samsung SOCs.
TODO: Adding the PHY binding with controller(s) according to the under
developement generic PHY driver.
+Exynos4210:
Required properties:
- compatible : should be "samsung,exynos4210-usbphy"
- reg : base physical address of the phy registers and length of memory mapped
region.
+
+Exynos5250:
+Required properties:
+- compatible : should be "samsung,exynos5250-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index dddfd6e..82bf042 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -218,6 +218,11 @@
#size-cells = <0>;
};
+ usbphy {
+ compatible = "samsung,exynos5250-usbphy";
+ reg = <0x1213 0x100>;
+ };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index da55107..d73fa42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -419,6 +419,7 @@ config MACH_EXYNOS5_DT
bool "SAMSUNG EXYNOS5 Machine using device tree"
depends on ARCH_EXYNOS5
select ARM_AMBA
+ select EXYNOS4_SETUP_USB_PHY
select SOC_EXYNOS5250
select USE_OF
help
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 9694424..7f5eb03 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -195,6 +195,7 @@
#define EXYNOS4_PA_EHCI0x1258
#define EXYNOS4_PA_OHCI0x1259
#define EXYNOS4_PA_HSPHY 0x125B
+#define EXYNOS5_PA_HSPHY 0x1213
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART0x1380
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index db1cd8e..bf20918 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
@@ -18,9 +19,15 @@
#include
#include
+#include
#include "common.h"
+static struct samsung_usbphy_data exynos5_usbphy_pdata = {
+ .pmu_isolation = s5p_usb_phy_pmu_isolation,
+ .phy_cfg_sel = s5p_usb_phy_cfg_sel,
+};
+
/*
* The following lookup table is used to override device names when devices
* are registered from device tree. This is temporarily added to enable
@@ -72,6 +79,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
"exynos-gsc.2", NULL),
OF_DEV_AUXDATA("samsung,exynos5-gsc", EXYNOS5_PA_GSC3,
"exynos-gsc.3", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-usbphy", EXYNOS5_PA_HSPHY,
+ "s3c-usbphy", &exynos5_usbphy_pdata),
{},
};
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index 39de35f..6c768e0 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -15,11 +15,15 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
+#define EXYNOS5_USB_CFG(S3C_VA_SYS + 0x230)
+
static atomic_t host_usage;
static int exynos4_usb_host_phy_is_on(void)
@@ -225,13 +229,36 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int
type)
void s5p_usb_phy_pmu_isolation(int on, int type)
{
- if (on) {
- writel(readl(S5P_USBDEVICE_PHY_CONTROL)
- & ~S5P_USBDE
[PATCH v4 0/5] usbnet: avoiding access auto-suspended device
Hi, This patchset avoids accessing auto-suspended device in ioctl path, which is generally triggered by some network utility(ethtool, ifconfig, ...) Most of network devices have the problem, but as discussed in the thread: http://marc.info/?t=13505486063&r=1&w=2 the problem should be solved inside driver. Considered that only smsc75xx and smsc95xx calls usbnet_read_cmd() and usbnet_write_cmd() inside its resume and suspend callback, the patcheset introduces the nopm version of the two functions which should be called only in the resume and suspend callback. So we can solve the problem by runtime resuming device before doing control message things. The patchset is against 3.7.0-rc4-next-20121105, and has been tested OK on smsc95xx usbnet device. Change logs: V4: - kfree in failure path, only patch 3/5 changed V3: - fix comment and code style reported by Sergei Shtylyov V2: - rebased on the latest net-next tree, only 2/5 changed V1: - rebased on 3.7.0-rc3-next-20121102, only patch 4/5 changed - fix one memory leak during smsc95xx_suspend, patch 3/5 added drivers/net/usb/smsc75xx.c | 147 +++- drivers/net/usb/smsc95xx.c | 147 drivers/net/usb/usbnet.c | 74 -- include/linux/usb/usbnet.h |4 ++ 4 files changed, 258 insertions(+), 114 deletions(-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/5] usbnet: introduce usbnet_{read|write}_cmd_nopm
This patch introduces the below two helpers to prepare for solving
the usbnet runtime PM problem, which may cause some network utilities
(ifconfig, ethtool,...) touch a suspended device.
usbnet_read_cmd_nopm()
usbnet_write_cmd_nopm()
The above two helpers should be called by usbnet resume/suspend
callback to avoid deadlock.
Signed-off-by: Ming Lei
---
drivers/net/usb/usbnet.c | 62
include/linux/usb/usbnet.h |4 +++
2 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 09ea47a..a7fb074 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1614,8 +1614,8 @@ void usbnet_device_suggests_idle(struct usbnet *dev)
EXPORT_SYMBOL(usbnet_device_suggests_idle);
/*-*/
-int usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
- u16 value, u16 index, void *data, u16 size)
+static int __usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
+u16 value, u16 index, void *data, u16 size)
{
void *buf = NULL;
int err = -ENOMEM;
@@ -1639,10 +1639,10 @@ int usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8
reqtype,
out:
return err;
}
-EXPORT_SYMBOL_GPL(usbnet_read_cmd);
-int usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
-u16 value, u16 index, const void *data, u16 size)
+static int __usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
+ u16 value, u16 index, const void *data,
+ u16 size)
{
void *buf = NULL;
int err = -ENOMEM;
@@ -1665,8 +1665,56 @@ int usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8
reqtype,
out:
return err;
}
+
+/*
+ * The function can't be called inside suspend/resume callback,
+ * otherwise deadlock will be caused.
+ */
+int usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
+ u16 value, u16 index, void *data, u16 size)
+{
+ return __usbnet_read_cmd(dev, cmd, reqtype, value, index,
+data, size);
+}
+EXPORT_SYMBOL_GPL(usbnet_read_cmd);
+
+/*
+ * The function can't be called inside suspend/resume callback,
+ * otherwise deadlock will be caused.
+ */
+int usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
+u16 value, u16 index, const void *data, u16 size)
+{
+ return __usbnet_write_cmd(dev, cmd, reqtype, value, index,
+ data, size);
+}
EXPORT_SYMBOL_GPL(usbnet_write_cmd);
+/*
+ * The function can be called inside suspend/resume callback safely
+ * and should only be called by suspend/resume callback generally.
+ */
+int usbnet_read_cmd_nopm(struct usbnet *dev, u8 cmd, u8 reqtype,
+ u16 value, u16 index, void *data, u16 size)
+{
+ return __usbnet_read_cmd(dev, cmd, reqtype, value, index,
+data, size);
+}
+EXPORT_SYMBOL_GPL(usbnet_read_cmd_nopm);
+
+/*
+ * The function can be called inside suspend/resume callback safely
+ * and should only be called by suspend/resume callback generally.
+ */
+int usbnet_write_cmd_nopm(struct usbnet *dev, u8 cmd, u8 reqtype,
+ u16 value, u16 index, const void *data,
+ u16 size)
+{
+ return __usbnet_write_cmd(dev, cmd, reqtype, value, index,
+ data, size);
+}
+EXPORT_SYMBOL_GPL(usbnet_write_cmd_nopm);
+
static void usbnet_async_cmd_cb(struct urb *urb)
{
struct usb_ctrlrequest *req = (struct usb_ctrlrequest *)urb->context;
@@ -1680,6 +1728,10 @@ static void usbnet_async_cmd_cb(struct urb *urb)
usb_free_urb(urb);
}
+/*
+ * The caller must make sure that device can't be put into suspend
+ * state until the control URB completes.
+ */
int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, const void *data, u16 size)
{
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 4410e416..9bbeabf 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -167,6 +167,10 @@ extern int usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8
reqtype,
u16 value, u16 index, void *data, u16 size);
extern int usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, const void *data, u16 size);
+extern int usbnet_read_cmd_nopm(struct usbnet *dev, u8 cmd, u8 reqtype,
+ u16 value, u16 index, void *data, u16 size);
+extern int usbnet_write_cmd_nopm(struct usbnet *dev, u8 cmd, u8 reqtype,
+ u16 value, u16 index, const void *data, u16 size);
extern int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, const void *data, u16 size);
--
1.7.9.5
-
[PATCH v4 2/5] usbnet: smsc75xx: apply the introduced usbnet_{read|write}_cmd_nopm
This patch applies the introduced usbnet_read_cmd_nopm() and
usbnet_write_cmd_nopm() in the callback of resume and suspend
to avoid deadlock if USB runtime PM is considered into
usbnet_read_cmd() and usbnet_write_cmd().
Cc: Steve Glendinning
Signed-off-by: Ming Lei
---
drivers/net/usb/smsc75xx.c | 147 +++-
1 file changed, 90 insertions(+), 57 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 85d70c2..c5353cf 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -85,18 +85,23 @@ static bool turbo_mode = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
-static int __must_check smsc75xx_read_reg(struct usbnet *dev, u32 index,
- u32 *data)
+static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index,
+ u32 *data, int in_pm)
{
u32 buf;
int ret;
+ int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
BUG_ON(!dev);
- ret = usbnet_read_cmd(dev, USB_VENDOR_REQUEST_READ_REGISTER,
- USB_DIR_IN | USB_TYPE_VENDOR |
- USB_RECIP_DEVICE,
- 0, index, &buf, 4);
+ if (!in_pm)
+ fn = usbnet_read_cmd;
+ else
+ fn = usbnet_read_cmd_nopm;
+
+ ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN
+| USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+0, index, &buf, 4);
if (unlikely(ret < 0))
netdev_warn(dev->net,
"Failed to read reg index 0x%08x: %d", index, ret);
@@ -107,21 +112,26 @@ static int __must_check smsc75xx_read_reg(struct usbnet
*dev, u32 index,
return ret;
}
-static int __must_check smsc75xx_write_reg(struct usbnet *dev, u32 index,
- u32 data)
+static int __must_check __smsc75xx_write_reg(struct usbnet *dev, u32 index,
+u32 data, int in_pm)
{
u32 buf;
int ret;
+ int (*fn)(struct usbnet *, u8, u8, u16, u16, const void *, u16);
BUG_ON(!dev);
+ if (!in_pm)
+ fn = usbnet_write_cmd;
+ else
+ fn = usbnet_write_cmd_nopm;
+
buf = data;
cpu_to_le32s(&buf);
- ret = usbnet_write_cmd(dev, USB_VENDOR_REQUEST_WRITE_REGISTER,
- USB_DIR_OUT | USB_TYPE_VENDOR |
- USB_RECIP_DEVICE,
- 0, index, &buf, 4);
+ ret = fn(dev, USB_VENDOR_REQUEST_WRITE_REGISTER, USB_DIR_OUT
+| USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+0, index, &buf, 4);
if (unlikely(ret < 0))
netdev_warn(dev->net,
"Failed to write reg index 0x%08x: %d", index, ret);
@@ -129,16 +139,38 @@ static int __must_check smsc75xx_write_reg(struct usbnet
*dev, u32 index,
return ret;
}
+static int __must_check smsc75xx_read_reg_nopm(struct usbnet *dev, u32 index,
+ u32 *data)
+{
+ return __smsc75xx_read_reg(dev, index, data, 1);
+}
+
+static int __must_check smsc75xx_write_reg_nopm(struct usbnet *dev, u32 index,
+ u32 data)
+{
+ return __smsc75xx_write_reg(dev, index, data, 1);
+}
+
+static int __must_check smsc75xx_read_reg(struct usbnet *dev, u32 index,
+ u32 *data)
+{
+ return __smsc75xx_read_reg(dev, index, data, 0);
+}
+
+static int __must_check smsc75xx_write_reg(struct usbnet *dev, u32 index,
+ u32 data)
+{
+ return __smsc75xx_write_reg(dev, index, data, 0);
+}
+
static int smsc75xx_set_feature(struct usbnet *dev, u32 feature)
{
if (WARN_ON_ONCE(!dev))
return -EINVAL;
- cpu_to_le32s(&feature);
-
- return usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
- USB_REQ_SET_FEATURE, USB_RECIP_DEVICE, feature, 0, NULL, 0,
- USB_CTRL_SET_TIMEOUT);
+ return usbnet_write_cmd_nopm(dev, USB_REQ_SET_FEATURE,
+USB_DIR_OUT | USB_RECIP_DEVICE,
+feature, 0, NULL, 0);
}
static int smsc75xx_clear_feature(struct usbnet *dev, u32 feature)
@@ -146,11 +178,9 @@ static int smsc75xx_clear_feature(struct usbnet *dev, u32
feature)
if (WARN_ON_ONCE(!dev))
return -EINVAL;
- cpu_to_le32s(&feature);
-
- return usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
- USB_REQ_CLEAR_FEATURE, USB_RECIP_DEVICE, feature, 0, NULL, 0,
- USB_CTRL_SET_TIMEOUT);
+ return usbnet_write_cmd_nopm(dev, USB_REQ_CLEAR_FEATURE
[PATCH v4 4/5] USB: ehci-s5p: Add phy driver support
Adding the phy driver to ehci-s5p. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
---
drivers/usb/host/ehci-s5p.c | 70 ++-
1 files changed, 49 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 0cd0c7b..14f01c6 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -33,6 +34,8 @@ struct s5p_ehci_hcd {
struct device *dev;
struct usb_hcd *hcd;
struct clk *clk;
+ struct usb_phy *phy;
+ struct s5p_ehci_platdata *pdata;
};
static const struct hc_driver s5p_ehci_hc_driver = {
@@ -66,6 +69,30 @@ static const struct hc_driver s5p_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci->dev);
+
+ if (s5p_ehci->phy) {
+ samsung_usbphy_set_type(s5p_ehci->phy, USB_PHY_TYPE_HOST);
+ usb_phy_init(s5p_ehci->phy);
+ } else if (s5p_ehci->pdata->phy_init) {
+ s5p_ehci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
+ }
+}
+
+static void s5p_ehci_phy_disable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci->dev);
+
+ if (s5p_ehci->phy) {
+ samsung_usbphy_set_type(s5p_ehci->phy, USB_PHY_TYPE_HOST);
+ usb_phy_shutdown(s5p_ehci->phy);
+ } else if (s5p_ehci->pdata->phy_exit) {
+ s5p_ehci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
+ }
+}
+
static void s5p_setup_vbus_gpio(struct platform_device *pdev)
{
int err;
@@ -88,20 +115,15 @@ static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
static int __devinit s5p_ehci_probe(struct platform_device *pdev)
{
- struct s5p_ehci_platdata *pdata;
+ struct s5p_ehci_platdata *pdata = pdev->dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
+ struct usb_phy *phy;
int irq;
int err;
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "No platform data defined\n");
- return -EINVAL;
- }
-
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
@@ -119,6 +141,19 @@ static int __devinit s5p_ehci_probe(struct platform_device
*pdev)
if (!s5p_ehci)
return -ENOMEM;
+ phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
+ return -EPROBE_DEFER;
+ } else {
+ s5p_ehci->pdata = pdata;
+ }
+ } else {
+ s5p_ehci->phy = phy;
+ }
+
s5p_ehci->dev = &pdev->dev;
hcd = usb_create_hcd(&s5p_ehci_hc_driver, &pdev->dev,
@@ -164,8 +199,7 @@ static int __devinit s5p_ehci_probe(struct platform_device
*pdev)
goto fail_io;
}
- if (pdata->phy_init)
- pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
+ s5p_ehci_phy_enable(s5p_ehci);
ehci = hcd_to_ehci(hcd);
ehci->caps = hcd->regs;
@@ -176,13 +210,15 @@ static int __devinit s5p_ehci_probe(struct
platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(&pdev->dev, "Failed to add USB HCD\n");
- goto fail_io;
+ goto fail_add_hcd;
}
platform_set_drvdata(pdev, s5p_ehci);
return 0;
+fail_add_hcd:
+ s5p_ehci_phy_disable(s5p_ehci);
fail_io:
clk_disable_unprepare(s5p_ehci->clk);
fail_clk:
@@ -192,14 +228,12 @@ fail_clk:
static int __devexit s5p_ehci_remove(struct platform_device *pdev)
{
- struct s5p_ehci_platdata *pdata = pdev->dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci = platform_get_drvdata(pdev);
struct usb_hcd *hcd = s5p_ehci->hcd;
usb_remove_hcd(hcd);
- if (pdata && pdata->phy_exit)
- pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
+ s5p_ehci_phy_disable(s5p_ehci);
clk_disable_unprepare(s5p_ehci->clk);
@@ -223,14 +257,11 @@ static int s5p_ehci_suspend(struct device *dev)
struct s5p_ehci_hcd *s5p_ehci = dev_get_drvdata(dev);
struct usb_hcd *hcd = s5p_ehci->hcd;
bool do_wakeup = device_may_wakeup(dev);
- struct platform_device *pdev = to_platform_device(dev);
-
[PATCH v4 3/5] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend
This patch fixes memory leak in smsc95xx_suspend.
Also, it isn't necessary to bother mm to allocate 8bytes/16byte,
and we can use stack variable safely.
Acked-By: Steve Glendinning
Signed-off-by: Ming Lei
---
drivers/net/usb/smsc95xx.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 34f2e78..f69560c 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1070,11 +1070,15 @@ static int smsc95xx_suspend(struct usb_interface *intf,
pm_message_t message)
if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST))
{
u32 *filter_mask = kzalloc(32, GFP_KERNEL);
- u32 *command = kzalloc(2, GFP_KERNEL);
- u32 *offset = kzalloc(2, GFP_KERNEL);
- u32 *crc = kzalloc(4, GFP_KERNEL);
+ u32 command[2];
+ u32 offset[2];
+ u32 crc[4];
int i, filter = 0;
+ memset(command, 0, sizeof(command));
+ memset(offset, 0, sizeof(offset));
+ memset(crc, 0, sizeof(crc));
+
if (pdata->wolopts & WAKE_BCAST) {
const u8 bcast[] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
netdev_info(dev->net, "enabling broadcast detection");
@@ -1128,8 +1132,11 @@ static int smsc95xx_suspend(struct usb_interface *intf,
pm_message_t message)
for (i = 0; i < (pdata->wuff_filter_count * 4); i++) {
ret = smsc95xx_write_reg(dev, WUFF, filter_mask[i]);
+ if (ret < 0)
+ kfree(filter_mask);
check_warn_return(ret, "Error writing WUFF");
}
+ kfree(filter_mask);
for (i = 0; i < (pdata->wuff_filter_count / 4); i++) {
ret = smsc95xx_write_reg(dev, WUFF, command[i]);
--
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 v4 4/5] usbnet: smsc95xx: apply the introduced usbnet_{read|write}_cmd_nopm
This patch applies the introduced usbnet_read_cmd_nopm() and
usbnet_write_cmd_nopm() in the callback of resume and suspend
to avoid deadlock if USB runtime PM is considered into
usbnet_read_cmd() and usbnet_write_cmd().
Cc: Steve Glendinning
Signed-off-by: Ming Lei
---
drivers/net/usb/smsc95xx.c | 134
1 file changed, 85 insertions(+), 49 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index f69560c..e07f70b 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -73,20 +73,26 @@ static bool turbo_mode = true;
module_param(turbo_mode, bool, 0644);
MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction");
-static int __must_check smsc95xx_read_reg(struct usbnet *dev, u32 index,
- u32 *data)
+static int __must_check __smsc95xx_read_reg(struct usbnet *dev, u32 index,
+ u32 *data, int in_pm)
{
u32 buf;
int ret;
+ int (*fn)(struct usbnet *, u8, u8, u16, u16, void *, u16);
BUG_ON(!dev);
- ret = usbnet_read_cmd(dev, USB_VENDOR_REQUEST_READ_REGISTER,
- USB_DIR_IN | USB_TYPE_VENDOR |
- USB_RECIP_DEVICE,
- 0, index, &buf, 4);
+ if (!in_pm)
+ fn = usbnet_read_cmd;
+ else
+ fn = usbnet_read_cmd_nopm;
+
+ ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN
+| USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+0, index, &buf, 4);
if (unlikely(ret < 0))
- netdev_warn(dev->net, "Failed to read register index 0x%08x\n",
index);
+ netdev_warn(dev->net,
+ "Failed to read reg index 0x%08x: %d", index, ret);
le32_to_cpus(&buf);
*data = buf;
@@ -94,35 +100,64 @@ static int __must_check smsc95xx_read_reg(struct usbnet
*dev, u32 index,
return ret;
}
-static int __must_check smsc95xx_write_reg(struct usbnet *dev, u32 index,
- u32 data)
+static int __must_check __smsc95xx_write_reg(struct usbnet *dev, u32 index,
+u32 data, int in_pm)
{
u32 buf;
int ret;
+ int (*fn)(struct usbnet *, u8, u8, u16, u16, const void *, u16);
BUG_ON(!dev);
+ if (!in_pm)
+ fn = usbnet_write_cmd;
+ else
+ fn = usbnet_write_cmd_nopm;
+
buf = data;
cpu_to_le32s(&buf);
-
- ret = usbnet_write_cmd(dev, USB_VENDOR_REQUEST_WRITE_REGISTER,
- USB_DIR_OUT | USB_TYPE_VENDOR |
- USB_RECIP_DEVICE,
- 0, index, &buf, 4);
+ ret = fn(dev, USB_VENDOR_REQUEST_WRITE_REGISTER, USB_DIR_OUT
+| USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+0, index, &buf, 4);
if (unlikely(ret < 0))
- netdev_warn(dev->net, "Failed to write register index
0x%08x\n", index);
+ netdev_warn(dev->net,
+ "Failed to write reg index 0x%08x: %d", index, ret);
return ret;
}
+static int __must_check smsc95xx_read_reg_nopm(struct usbnet *dev, u32 index,
+ u32 *data)
+{
+ return __smsc95xx_read_reg(dev, index, data, 1);
+}
+
+static int __must_check smsc95xx_write_reg_nopm(struct usbnet *dev, u32 index,
+ u32 data)
+{
+ return __smsc95xx_write_reg(dev, index, data, 1);
+}
+
+static int __must_check smsc95xx_read_reg(struct usbnet *dev, u32 index,
+ u32 *data)
+{
+ return __smsc95xx_read_reg(dev, index, data, 0);
+}
+
+static int __must_check smsc95xx_write_reg(struct usbnet *dev, u32 index,
+ u32 data)
+{
+ return __smsc95xx_write_reg(dev, index, data, 0);
+}
static int smsc95xx_set_feature(struct usbnet *dev, u32 feature)
{
if (WARN_ON_ONCE(!dev))
return -EINVAL;
- return usbnet_write_cmd(dev, USB_REQ_SET_FEATURE,
- USB_RECIP_DEVICE, feature, 0, NULL, 0);
+ return usbnet_write_cmd_nopm(dev, USB_REQ_SET_FEATURE,
+USB_RECIP_DEVICE, feature, 0,
+NULL, 0);
}
static int smsc95xx_clear_feature(struct usbnet *dev, u32 feature)
@@ -130,8 +165,9 @@ static int smsc95xx_clear_feature(struct usbnet *dev, u32
feature)
if (WARN_ON_ONCE(!dev))
return -EINVAL;
- return usbnet_write_cmd(dev, USB_REQ_CLEAR_FEATURE,
- USB_RECIP_DEVICE, feature, 0, NULL, 0);
+ return usbnet_write_cmd_nopm(dev, USB_REQ_CLEAR_FEATURE,
+USB_RECIP_DEVICE, feature,
[PATCH v4 5/5] usbnet: runtime wake up device before calling usbnet_{read|write}_cmd
This patch gets the runtime PM reference count before calling
usbnet_{read|write}_cmd, and puts it after completion of the
usbnet_{read|write}_cmd, so that the usb control message can always
be sent to one active device in the non-PM context.
Signed-off-by: Ming Lei
---
drivers/net/usb/usbnet.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index a7fb074..08c4759 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1673,8 +1673,14 @@ out:
int usbnet_read_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, void *data, u16 size)
{
- return __usbnet_read_cmd(dev, cmd, reqtype, value, index,
-data, size);
+ int ret;
+
+ if (usb_autopm_get_interface(dev->intf) < 0)
+ return -ENODEV;
+ ret = __usbnet_read_cmd(dev, cmd, reqtype, value, index,
+ data, size);
+ usb_autopm_put_interface(dev->intf);
+ return ret;
}
EXPORT_SYMBOL_GPL(usbnet_read_cmd);
@@ -1685,8 +1691,14 @@ EXPORT_SYMBOL_GPL(usbnet_read_cmd);
int usbnet_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
u16 value, u16 index, const void *data, u16 size)
{
- return __usbnet_write_cmd(dev, cmd, reqtype, value, index,
- data, size);
+ int ret;
+
+ if (usb_autopm_get_interface(dev->intf) < 0)
+ return -ENODEV;
+ ret = __usbnet_write_cmd(dev, cmd, reqtype, value, index,
+data, size);
+ usb_autopm_put_interface(dev->intf);
+ return ret;
}
EXPORT_SYMBOL_GPL(usbnet_write_cmd);
--
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 v4 5/5] USB: ohci-exynos: Add phy driver support
Adding the phy-driver to ohci-exynos. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
---
drivers/usb/host/ohci-exynos.c | 70
1 files changed, 49 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 1f46898..97d5aa5 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -22,8 +23,34 @@ struct exynos_ohci_hcd {
struct device *dev;
struct usb_hcd *hcd;
struct clk *clk;
+ struct usb_phy *phy;
+ struct exynos4_ohci_platdata *pdata;
};
+static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+
+ if (exynos_ohci->phy) {
+ samsung_usbphy_set_type(exynos_ohci->phy, USB_PHY_TYPE_HOST);
+ usb_phy_init(exynos_ohci->phy);
+ } else if (exynos_ohci->pdata->phy_init) {
+ exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
+ }
+}
+
+static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+{
+ struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+
+ if (exynos_ohci->phy) {
+ samsung_usbphy_set_type(exynos_ohci->phy, USB_PHY_TYPE_HOST);
+ usb_phy_shutdown(exynos_ohci->phy);
+ } else if (exynos_ohci->pdata->phy_exit) {
+ exynos_ohci->pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
+ }
+}
+
static int ohci_exynos_reset(struct usb_hcd *hcd)
{
return ohci_init(hcd_to_ohci(hcd));
@@ -79,20 +106,15 @@ static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
static int __devinit exynos_ohci_probe(struct platform_device *pdev)
{
- struct exynos4_ohci_platdata *pdata;
+ struct exynos4_ohci_platdata *pdata = pdev->dev.platform_data;
struct exynos_ohci_hcd *exynos_ohci;
struct usb_hcd *hcd;
struct ohci_hcd *ohci;
struct resource *res;
+ struct usb_phy *phy;
int irq;
int err;
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "No platform data defined\n");
- return -EINVAL;
- }
-
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
@@ -108,6 +130,19 @@ static int __devinit exynos_ohci_probe(struct
platform_device *pdev)
if (!exynos_ohci)
return -ENOMEM;
+ phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
+ return -EPROBE_DEFER;
+ } else {
+ exynos_ohci->pdata = pdata;
+ }
+ } else {
+ exynos_ohci->phy = phy;
+ }
+
exynos_ohci->dev = &pdev->dev;
hcd = usb_create_hcd(&exynos_ohci_hc_driver, &pdev->dev,
@@ -153,8 +188,7 @@ static int __devinit exynos_ohci_probe(struct
platform_device *pdev)
goto fail_io;
}
- if (pdata->phy_init)
- pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
+ exynos_ohci_phy_enable(exynos_ohci);
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
@@ -162,13 +196,15 @@ static int __devinit exynos_ohci_probe(struct
platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(&pdev->dev, "Failed to add USB HCD\n");
- goto fail_io;
+ goto fail_add_hcd;
}
platform_set_drvdata(pdev, exynos_ohci);
return 0;
+fail_add_hcd:
+ exynos_ohci_phy_disable(exynos_ohci);
fail_io:
clk_disable_unprepare(exynos_ohci->clk);
fail_clk:
@@ -178,14 +214,12 @@ fail_clk:
static int __devexit exynos_ohci_remove(struct platform_device *pdev)
{
- struct exynos4_ohci_platdata *pdata = pdev->dev.platform_data;
struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
struct usb_hcd *hcd = exynos_ohci->hcd;
usb_remove_hcd(hcd);
- if (pdata && pdata->phy_exit)
- pdata->phy_exit(pdev, USB_PHY_TYPE_HOST);
+ exynos_ohci_phy_disable(exynos_ohci);
clk_disable_unprepare(exynos_ohci->clk);
@@ -209,8 +243,6 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = dev_get_drvdata(dev);
struct usb_hcd *hcd = exynos_ohci->hcd;
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos4_ohc
[PATCH/RESEND 0/2] usb: musb: am335x support part-2
Hi Balbi, This is a resend of remaining changes to get am335x usb working. These were sent on 31 Oct with subject, "usb: musb: dsps: fixes for -rc. First one restores capability to support at least one instance of musb. Without it, even a single instance can't be supported as change which is reverted by it was made along with multi phy changes and nop transciever dt support, both other changes didn't make it to mainline. Second one corrects binding document; changes were made in driver as per review comments, but documentation was not updated. This is made on top of your "musb" branch. To get USB0 functional on am335x based boards like beagle bone, first one is required. Regards Afzal Afzal Mohammed (2): Revert "usb: musb: dsps: remove explicit NOP device creation" usb: musb: dsps: document dt bindings properly Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 drivers/usb/musb/musb_dsps.c | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) -- 1.7.12 -- 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/RESEND 1/2] Revert "usb: musb: dsps: remove explicit NOP device creation"
This reverts commit d8c3ef256f88b7c6ecd673d03073b5645be9c5e4. Above mentioned change was made along with multi usb phy change and adding DT support for nop transceiver. But other two changes did not make it to mainline. This in effect makes dsps musb wrapper unusable even for single instance. Hence revert it so that at least single instance can be supported. Signed-off-by: Afzal Mohammed --- drivers/usb/musb/musb_dsps.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 6053af1..e770f79 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -411,7 +411,8 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb->mregs += wrp->musb_core_offset; - /* Get the NOP PHY */ + /* NOP driver needs change if supporting dual instance */ + usb_nop_xceiv_register(); musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.12 -- 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/RESEND 2/2] usb: musb: dsps: document dt bindings properly
DT bindings normally use '-' (hyphens) instead of '_' (underscore), driver has it the proper way, but binding documentation does not reflect it, fix it. Signed-off-by: Afzal Mohammed --- Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index ca8fa56..a922505 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -3,12 +3,12 @@ AM33XX MUSB GLUE - ti,hwmods : must be "usb_otg_hs" - multipoint : Should be "1" indicating the musb controller supports multipoint. This is a MUSB configuration-specific setting. - - num_eps : Specifies the number of endpoints. This is also a + - num-eps : Specifies the number of endpoints. This is also a MUSB configuration-specific setting. Should be set to "16" - - ram_bits : Specifies the ram address size. Should be set to "12" - - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2" + - ram-bits : Specifies the ram address size. Should be set to "12" + - port0-mode : Should be "3" to represent OTG. "1" signifies HOST and "2" represents PERIPHERAL. - - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2" + - port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2" represents PERIPHERAL. - power : Should be "250". This signifies the controller can supply upto 500mA when operating in host mode. -- 1.7.12 -- 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] ARM: EXYNOS5250: Add support for USB 3.0 dwc3 controller
Here we add the required support for device tree and further clocks and device reigster base address. Based on 'for-next' branch of linux-samsung tree. Tested with required driver DT patches for dwc3-exynos: http://www.spinics.net/lists/linux-usb/msg73857.html and USB 3.0 phy support patches: https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-November/021915.html Vivek Gautam (1): ARM: Exynos5250: Enabling dwc3-exynos driver arch/arm/boot/dts/exynos5250.dtsi |6 ++ arch/arm/mach-exynos/clock-exynos5.c| 24 arch/arm/mach-exynos/include/mach/map.h |1 + arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++ drivers/usb/Kconfig |1 + 5 files changed, 34 insertions(+), 0 deletions(-) -- 1.7.6.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] ARM: Exynos5250: Enabling dwc3-exynos driver
Adding DWC3 device tree node for Exynos5250 along with the
device address and clock support needed for the controller.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch/arm/mach-exynos/clock-exynos5.c| 24
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
drivers/usb/Kconfig |1 +
5 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index cf6a02d..52bca54 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -68,6 +68,12 @@
interrupts = <0 96 0>;
};
+ dwc3 {
+ compatible = "samsung,exynos-dwc3";
+ reg = <0x1200 0x1>;
+ interrupts = <0 72 0>;
+ };
+
rtc {
compatible = "samsung,s3c6410-rtc";
reg = <0x101E 0x100>;
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index a88e0d9..ee094ee 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -740,6 +740,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_fsys_ctrl ,
.ctrlbit= (1 << 18),
}, {
+ .name = "usbdrd30",
+ .parent = &exynos5_clk_aclk_200.clk,
+ .enable = exynos5_clk_ip_fsys_ctrl,
+ .ctrlbit= (1 << 19),
+ }, {
.name = "usbotg",
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 << 7),
@@ -1004,6 +1009,16 @@ struct clksrc_sources exynos5_clkset_group = {
.nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
};
+struct clk *exynos5_clkset_usbdrd30_list[] = {
+ [0] = &exynos5_clk_mout_mpll.clk,
+ [1] = &exynos5_clk_mout_cpll.clk,
+};
+
+struct clksrc_sources exynos5_clkset_usbdrd30 = {
+ .sources= exynos5_clkset_usbdrd30_list,
+ .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
+};
+
/* Possible clock sources for aclk_266_gscl_sub Mux */
static struct clk *clk_src_gscl_266_list[] = {
[0] = &clk_ext_xtal_mux,
@@ -1288,6 +1303,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.parent = &exynos5_clk_mout_cpll.clk,
},
.reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3 },
+ }, {
+ .clk= {
+ .name = "sclk_usbdrd30",
+ .enable = exynos5_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 << 28),
+ },
+ .sources = &exynos5_clkset_usbdrd30,
+ .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size = 1
},
+ .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size =
4 },
},
};
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index ef4958b..397fb9d 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -197,6 +197,7 @@
#define EXYNOS4_PA_EHCI0x1258
#define EXYNOS4_PA_OHCI0x1259
#define EXYNOS4_PA_HSPHY 0x125B
+#define EXYNOS5_PA_DRD 0x1200
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART0x1380
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ed37273..8896926 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -86,6 +86,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
"exynos5-hdmi", NULL),
OF_DEV_AUXDATA("samsung,exynos5-mixer", 0x1445,
"exynos5-mixer", NULL),
+ OF_DEV_AUXDATA("samsung,exynos-dwc3", EXYNOS5_PA_DRD,
+ "exynos-dwc3", NULL),
{},
};
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 4c90b51..0454b8a 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -53,6 +53,7 @@ config USB_ARCH_HAS_EHCI
# some non-PCI HCDs implement xHCI
config USB_ARCH_HAS_XHCI
boolean
+ default y if ARCH_EXYNOS5
default PCI
menuconfig USB_SUPPORT
--
1.7.6.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 1/3] USB: EHCI: prepare to make ehci-hcd a library module
On Tue, 6 Nov 2012, Felipe Balbi wrote:
> On Thu, Nov 01, 2012 at 11:12:58AM -0400, Alan Stern wrote:
> > This patch (as1624) prepares ehci-hcd for being split up into a core
> > library and separate platform driver modules. A generic
> > ehci_hc_driver structure is created, containing all the "standard"
> > values, and a new mechanism is added whereby a driver module can
> > specify a set of overrides to those values. In addition the
> > ehci_setup(), ehci_suspend(), and ehci_resume() routines need to be
> > EXPORTed for use by the drivers.
> > +/* Declarations of things exported for use by ehci platform drivers */
> > +
> > +struct ehci_driver_overrides {
> > + const char *product_desc;
>
> just one question: do we really need to allow for product_desc override?
> Isn't it enough to just call it "EHCI Host Controller" or "Enhanced Host
> Controller Interface"
It's not a big issue, as far as I can see. This value appears as the
Product string in the root hub's device descriptor, and it appears in
the system log each time a new host controller is added, but it doesn't
affect anything else.
If you think it shouldn't be overridden, I'm willing to change the new
code.
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 0/2] Adding USB 3.0 DRD-phy support for exynos5250
This patchset is based on the work for USB 2.0 host phy support for exynos5250 https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-November/021915.html Based on 'usb-next' branch. Tested on smdk5250 with following patch-series: https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-November/021923.html http://www.spinics.net/lists/linux-usb/msg73857.html Vivek Gautam (2): USB: PHY: Add support for USB 3.0 phy for exynos5250 ARM: Exynos5250: Enabling USB 3.0 phy for samsung-usbphy driver arch/arm/boot/dts/exynos5250.dtsi|3 +- arch/arm/mach-exynos/include/mach/regs-pmu.h |4 + arch/arm/mach-exynos/setup-usb-phy.c |9 + drivers/usb/phy/samsung-usbphy.c | 337 ++ include/linux/usb/samsung_usb_phy.h |1 + 5 files changed, 353 insertions(+), 1 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] USB: PHY: Add support for USB 3.0 phy for exynos5250
Adding support for USB3.0 phy for dwc3 controller on
exynso5250 SOC.
Signed-off-by: Vivek Gautam
---
drivers/usb/phy/samsung-usbphy.c| 337 +++
include/linux/usb/samsung_usb_phy.h |1 +
2 files changed, 338 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 3b4863d..e3b5fb1 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -167,6 +167,99 @@
#define EXYNOS5_PHY_OTG_TUNE (0x40)
+/* USB 3.0: DRD */
+#define EXYNOS5_DRD_LINKSYSTEM (0x04)
+
+#define LINKSYSTEM_FLADJ_MASK (0x3f << 1)
+#define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
+#define LINKSYSTEM_XHCI_VERSION_CONTROL(1 << 27)
+
+#define EXYNOS5_DRD_PHYUTMI(0x08)
+
+#define PHYUTMI_OTGDISABLE (1 << 6)
+#define PHYUTMI_FORCESUSPEND (1 << 1)
+#define PHYUTMI_FORCESLEEP (1 << 0)
+
+#define EXYNOS5_DRD_PHYPIPE(0x0C)
+
+#define EXYNOS5_DRD_PHYCLKRST (0x10)
+
+#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
+#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23)
+
+#define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
+#define PHYCLKRST_SSC_RANGE(_x)((_x) << 21)
+
+#define PHYCLKRST_SSC_EN (1 << 20)
+#define PHYCLKRST_REF_SSP_EN (1 << 19)
+#define PHYCLKRST_REF_CLKDIV2 (1 << 18)
+
+#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
+#define PHYCLKRST_MPLL_MULTIPLIER(_x) ((_x) << 11)
+#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF \
+ PHYCLKRST_MPLL_MULTIPLIER(0x19)
+#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF \
+ PHYCLKRST_MPLL_MULTIPLIER(0x02)
+#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF\
+ PHYCLKRST_MPLL_MULTIPLIER(0x68)
+#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF\
+ PHYCLKRST_MPLL_MULTIPLIER(0x7d)
+#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF \
+ PHYCLKRST_MPLL_MULTIPLIER(0x02)
+
+#define PHYCLKRST_FSEL_MASK(0x3f << 5)
+#define PHYCLKRST_FSEL(_x) ((_x) << 5)
+#define PHYCLKRST_FSEL_PAD_100MHZ \
+ PHYCLKRST_FSEL(0x27)
+#define PHYCLKRST_FSEL_PAD_24MHZ \
+ PHYCLKRST_FSEL(0x2a)
+#define PHYCLKRST_FSEL_PAD_20MHZ \
+ PHYCLKRST_FSEL(0x31)
+#define PHYCLKRST_FSEL_PAD_19_2MHZ \
+ PHYCLKRST_FSEL(0x38)
+
+#define PHYCLKRST_RETENABLEN (1 << 4)
+
+#define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
+#define PHYCLKRST_REFCLKSEL(_x)((_x) << 2)
+#define PHYCLKRST_REFCLKSEL_PAD_REFCLK \
+ PHYCLKRST_REFCLKSEL(2)
+#define PHYCLKRST_REFCLKSEL_EXT_REFCLK \
+ PHYCLKRST_REFCLKSEL(3)
+
+#define PHYCLKRST_PORTRESET(1 << 1)
+#define PHYCLKRST_COMMONONN(1 << 0)
+
+#define EXYNOS5_DRD_PHYREG0(0x14)
+#define EXYNOS5_DRD_PHYREG1(0x18)
+
+#define EXYNOS5_DRD_PHYPARAM0 (0x1C)
+
+#define PHYPARAM0_REF_USE_PAD (0x1 << 31)
+#define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26)
+#define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
+
+#define EXYNOS5_DRD_PHYPARAM1 (0x20)
+
+#define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0)
+#define PHYPARAM1_PCS_TXDEEMPH (0x1C)
+
+#define EXYNOS5_DRD_PHYTERM(0x24)
+
+#define EXYNOS5_DRD_PHYTEST(0x28)
+
+#define PHYTEST_POWERDOWN_SSP (1 << 3)
+#define PHYTEST_POWERDOWN_HSP (1 << 2)
+
+#define EXYNOS5_DRD_PHYADP (0x2C)
+
+#define EXYNOS5_DRD_PHYBATCHG (0x30)
+
+#define PHYBATCHG_UTMI_CLKSEL (0x1 << 2)
+
+#define EXYNOS5_DRD_PHYRESUME (0x34)
+#define EXYNOS5_DRD_LINKPORT (0x44)
+
#ifndef MHZ
#define MHZ (1000*1000)
#endif
@@ -180,10 +273,12 @@ enum samsung_cpu_type {
/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
+ * @phy3: transceiver structure for USB 3.0
* @plat: platform data
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
* @regs: usb phy register memory base
+ * @regs_phy3: usb 3.0 phy register memory base
* @ref_clk_freq: reference clock frequency selection
* @cpu_type: machine identifier
* @phy_type: It keeps track of the PHY type.
@@ -191,10 +286,12 @@ enum samsung_cpu_type {
*/
struct samsung_usbphy {
struct usb_phy phy;
+ struct usb_phy phy3;
struct samsung_usbphy_data *plat;
struct device *dev;
struct clk
[PATCH 2/2] ARM: Exynos5250: Enabling USB 3.0 phy for samsung-usbphy driver
Adding base address information and required platform data
support for enabling USB DRD phy on exynos5250 SOC.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5250.dtsi|3 ++-
arch/arm/mach-exynos/include/mach/regs-pmu.h |4
arch/arm/mach-exynos/setup-usb-phy.c |9 +
3 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 82bf042..51693af 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -220,7 +220,8 @@
usbphy {
compatible = "samsung,exynos5250-usbphy";
- reg = <0x1213 0x100>;
+ reg = <0x1213 0x100>,
+ <0x1210 0x100>;
};
amba {
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h
b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index d4e392b..67132b4 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -39,6 +39,10 @@
#define S5P_HDMI_PHY_CONTROL S5P_PMUREG(0x0700)
#define S5P_HDMI_PHY_ENABLE(1 << 0)
+/* only for EXYNOS5250*/
+#define S5P_USBDRD_PHY_CONTROL S5P_PMUREG(0x0704)
+#define S5P_USBDRD_PHY_ENABLE (1 << 0)
+
#define S5P_DAC_PHY_CONTROLS5P_PMUREG(0x070C)
#define S5P_DAC_PHY_ENABLE (1 << 0)
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index 6c768e0..5e46fdd 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -238,6 +238,15 @@ void s5p_usb_phy_pmu_isolation(int on, int type)
writel(readl(S5P_USBHOST_PHY_CONTROL)
| S5P_USBHOST_PHY_ENABLE,
S5P_USBHOST_PHY_CONTROL);
+ } else if (type == USB_PHY_TYPE_DRD) {
+ if (on)
+ writel(readl(S5P_USBDRD_PHY_CONTROL)
+ & ~S5P_USBDRD_PHY_ENABLE,
+ S5P_USBDRD_PHY_CONTROL);
+ else
+ writel(readl(S5P_USBDRD_PHY_CONTROL)
+ | S5P_USBDRD_PHY_ENABLE,
+ S5P_USBDRD_PHY_CONTROL);
} else {
if (on)
writel(readl(S5P_USBDEVICE_PHY_CONTROL)
--
1.7.6.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: 3TB Hard Drive in USB Enclosure Resetting
On Mon, 5 Nov 2012, Jason J. Herne wrote: > I have a Seagate ST3000DM 3.0TB Sata Drive enclosed in a Vantec > NexStar CX USB 3.0/2.0 Enclosure. This enclosure/drive is not > properly recognized by Linux when plugged in via a USB 2.0 port. My > dmesg output, at first, seems like all is well. but then the drive > activity light starts flashing rapidly and never stops. After 20-30 > seconds I see a "reset high-speed USB device" message. The /dev/sdx > device node is created for the drive, but no sdxN nodes are created > and any program accessing the /dev/sdx node hangs. I have tried this > drive with 3 different computers all running Ubuntu 12.04 (kernel > 3.2.0-30-generic-pae) or Ubuntu 11.10 (kernel 3.0.0-12). I have also > tried the 3.7.0-rc4-next kernel. The problem persists on all of the > above kernels. > > It is worth noting that the drive is properly recognized by Windows 7 > running on the same hardware as my Ubuntu install. > > I am providing some output that I hope is useful for diagnosing the > problem. I can collect more if needed. I can also provide the raw > tcpdump capture file as saved by Wireshark. I don't understand much > of the trace I collected, but it seems to get interesting around Frame > 108: URB status: Remote I/O error (-EREMOTEIO) (-121). > Wireshark trace converted to text: > http://pastebin.com/aF845HY2 Wireshark's text format is very difficult to read and doesn't contain all the information. Could you post the raw pcap file? 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
Re: 3TB Hard Drive in USB Enclosure Resetting
Here is the pcap file, as captured from Wireshark. On Tue, Nov 6, 2012 at 10:46 AM, Alan Stern wrote: > On Mon, 5 Nov 2012, Jason J. Herne wrote: > >> I have a Seagate ST3000DM 3.0TB Sata Drive enclosed in a Vantec >> NexStar CX USB 3.0/2.0 Enclosure. This enclosure/drive is not >> properly recognized by Linux when plugged in via a USB 2.0 port. My >> dmesg output, at first, seems like all is well. but then the drive >> activity light starts flashing rapidly and never stops. After 20-30 >> seconds I see a "reset high-speed USB device" message. The /dev/sdx >> device node is created for the drive, but no sdxN nodes are created >> and any program accessing the /dev/sdx node hangs. I have tried this >> drive with 3 different computers all running Ubuntu 12.04 (kernel >> 3.2.0-30-generic-pae) or Ubuntu 11.10 (kernel 3.0.0-12). I have also >> tried the 3.7.0-rc4-next kernel. The problem persists on all of the >> above kernels. >> >> It is worth noting that the drive is properly recognized by Windows 7 >> running on the same hardware as my Ubuntu install. >> >> I am providing some output that I hope is useful for diagnosing the >> problem. I can collect more if needed. I can also provide the raw >> tcpdump capture file as saved by Wireshark. I don't understand much >> of the trace I collected, but it seems to get interesting around Frame >> 108: URB status: Remote I/O error (-EREMOTEIO) (-121). > >> Wireshark trace converted to text: >> http://pastebin.com/aF845HY2 > > Wireshark's text format is very difficult to read and doesn't contain > all the information. Could you post the raw pcap file? > > 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 -- - Jason J. Herne (hern...@gmail.com) usb-3tb-problem.cap Description: Binary data
Re: [PATCH 1/3] USB: EHCI: prepare to make ehci-hcd a library module
Hi
On Tue, Nov 06, 2012 at 10:25:40AM -0500, Alan Stern wrote:
> On Tue, 6 Nov 2012, Felipe Balbi wrote:
>
> > On Thu, Nov 01, 2012 at 11:12:58AM -0400, Alan Stern wrote:
> > > This patch (as1624) prepares ehci-hcd for being split up into a core
> > > library and separate platform driver modules. A generic
> > > ehci_hc_driver structure is created, containing all the "standard"
> > > values, and a new mechanism is added whereby a driver module can
> > > specify a set of overrides to those values. In addition the
> > > ehci_setup(), ehci_suspend(), and ehci_resume() routines need to be
> > > EXPORTed for use by the drivers.
>
> > > +/* Declarations of things exported for use by ehci platform drivers */
> > > +
> > > +struct ehci_driver_overrides {
> > > + const char *product_desc;
> >
> > just one question: do we really need to allow for product_desc override?
> > Isn't it enough to just call it "EHCI Host Controller" or "Enhanced Host
> > Controller Interface"
>
> It's not a big issue, as far as I can see. This value appears as the
> Product string in the root hub's device descriptor, and it appears in
> the system log each time a new host controller is added, but it doesn't
> affect anything else.
>
> If you think it shouldn't be overridden, I'm willing to change the new
> code.
I think it's best. A bit nit-picky, but at least it's one less member on
the override structure. It also gives a much more 'standard' user
experience where EHCI will be called EHCI on all architectures no matter
if it rus on PCI, AHB, AXI, OCP, etc... ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 0/4] Adding usb2.0 host-phy support for exynos5250
Hi, On Tue, Nov 06, 2012 at 07:23:12PM +0530, Vivek Gautam wrote: > Hi Balbi, > > > On Tue, Nov 6, 2012 at 6:44 PM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Oct 29, 2012 at 07:12:36PM +0530, Vivek Gautam wrote: > >> This patchset is based on the work by Praveen Paneri for > >> samsung-usbphy driver: > >> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/12653 > >> > >> Changes from v2: > >> - Using "EXYNOS5_PHY_" as common prefix along with exact names for > >>PHY SFRs for register definitions > >> - Using register names with bit macros to make things more clear. > >> - Removed parentheses around 0x230 in definition for EXYNOS5_USB_CFG > >>in [patch 2/4 v2]. > >> > >> Tested on smdk5250 target with usb-next branch along with arch patches > >> for exynos5250: > >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13042 > >> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/13048 > >> > >> Vivek Gautam (4): > >> usb: phy: samsung: Add host phy support to samsung-phy driver > >> ARM: Exynos5250: Enabling samsung-usbphy driver > >> USB: ehci-s5p: Add phy driver support > >> USB: ohci-exynos: Add phy driver support > > > > I really don't know what to do with this series. I know it depends on > > the other PHY changes which I have in my queue, but it touches too much > > arch specific code, plus the USB Host code which I don't maintain. > > > > True, that it has dependency on the work by Praveen Paneri for samsung-usbphy > driver plus the arch support patches. > > This is based on usb-next branch, so the host-code can be taken care of ? > > > On top of all that, I have no platform to test these patches, which > > makes me even more worried about signing off under this series ;-) > > > The patches have however been tested. The two patches: > "USB: ehci-s5p: Add phy driver support", > "USB: ohci-exynos: Add phy driver support" have been acked by Jingoo Han > based on the patch-series. > > Possibly Kukjin Kim can help on this one. > > Kukjin, > Can we have a thought on this please. > > > Would it be ok if we delay this to v3.9 ? At least the dependency with > > other PHY changes would be dropped by then. > > > This changes are almost in shape ;-) and i am updating the next patchset soon. > If possible can we try to get this in 3.8 please. :-) we can try, but I'd like to minimize the amount of code outside of drivers/usb/ I take in my tree. If there's any way to split the series so it makes my life easier, I'd be really glad. Also, I can't apply arch/* patches without proper Acked-bys, so Kukjin would need to help us out there too :-) cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: Exynos5250: Enabling dwc3-exynos driver
On Tue, Nov 06, 2012 at 08:58:49PM +0530, Vivek Gautam wrote:
> Adding DWC3 device tree node for Exynos5250 along with the
> device address and clock support needed for the controller.
>
> Signed-off-by: Vivek Gautam
> ---
> arch/arm/boot/dts/exynos5250.dtsi |6 ++
> arch/arm/mach-exynos/clock-exynos5.c| 24
> arch/arm/mach-exynos/include/mach/map.h |1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
> drivers/usb/Kconfig |1 +
> 5 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index cf6a02d..52bca54 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -68,6 +68,12 @@
> interrupts = <0 96 0>;
> };
>
> + dwc3 {
shouldn't this be usb@1200 ??
> + compatible = "samsung,exynos-dwc3";
> + reg = <0x1200 0x1>;
> + interrupts = <0 72 0>;
> + };
> +
> rtc {
> compatible = "samsung,s3c6410-rtc";
> reg = <0x101E 0x100>;
> diff --git a/arch/arm/mach-exynos/clock-exynos5.c
> b/arch/arm/mach-exynos/clock-exynos5.c
> index a88e0d9..ee094ee 100644
> --- a/arch/arm/mach-exynos/clock-exynos5.c
> +++ b/arch/arm/mach-exynos/clock-exynos5.c
> @@ -740,6 +740,11 @@ static struct clk exynos5_init_clocks_off[] = {
> .enable = exynos5_clk_ip_fsys_ctrl ,
> .ctrlbit= (1 << 18),
> }, {
> + .name = "usbdrd30",
> + .parent = &exynos5_clk_aclk_200.clk,
> + .enable = exynos5_clk_ip_fsys_ctrl,
> + .ctrlbit= (1 << 19),
> + }, {
> .name = "usbotg",
> .enable = exynos5_clk_ip_fsys_ctrl,
> .ctrlbit= (1 << 7),
> @@ -1004,6 +1009,16 @@ struct clksrc_sources exynos5_clkset_group = {
> .nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
> };
>
> +struct clk *exynos5_clkset_usbdrd30_list[] = {
> + [0] = &exynos5_clk_mout_mpll.clk,
> + [1] = &exynos5_clk_mout_cpll.clk,
looks like [0] and [1] indexes are unnecessary ?!? Not sure about
mach-exynos' preferred array initialization style, though ;-)
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 4c90b51..0454b8a 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -53,6 +53,7 @@ config USB_ARCH_HAS_EHCI
> # some non-PCI HCDs implement xHCI
> config USB_ARCH_HAS_XHCI
> boolean
> + default y if ARCH_EXYNOS5
NAK, this should be done on your arch/arm/mach-exynos/Kconfig. Just
select USB_ARCH_HAS_XHCI.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
Hi,
On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
> OMAP2+ family of devices are now obtaining resources via DT, earlier
> it was obtained from hwmod. Update binding document accrodingly, while
> at it add example.
>
> Signed-off-by: Afzal Mohammed
this looks fine to me:
Reviewed-by: Felipe Balbi
Benoit, do you take Documentation patches too ?
> ---
>
> v2: node name changed to "usb"
>
> .../devicetree/bindings/usb/am33xx-usb.txt | 21
> +
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> index a922505..ea840f7 100644
> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> @@ -1,5 +1,7 @@
> AM33XX MUSB GLUE
> - compatible : Should be "ti,musb-am33xx"
> + - reg : offset and length of register sets, first usbss, then for musb
> instances
> + - interrupts : usbss, musb instance interrupts in order
> - ti,hwmods : must be "usb_otg_hs"
> - multipoint : Should be "1" indicating the musb controller supports
> multipoint. This is a MUSB configuration-specific setting.
> @@ -12,3 +14,22 @@ AM33XX MUSB GLUE
> represents PERIPHERAL.
> - power : Should be "250". This signifies the controller can supply upto
> 500mA when operating in host mode.
> +
> +Example:
> +
> +usb@4740 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x4740 0x1000/* usbss */
> +0x47401000 0x800 /* musb instance 0 */
> +0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17/* usbss */
> + 18/* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> +};
> --
> 1.7.12
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
On 11/06/2012 05:44 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
>> OMAP2+ family of devices are now obtaining resources via DT, earlier
>> it was obtained from hwmod. Update binding document accrodingly, while
>> at it add example.
>>
>> Signed-off-by: Afzal Mohammed
>
> this looks fine to me:
>
> Reviewed-by: Felipe Balbi
>
> Benoit, do you take Documentation patches too ?
Well, ideally it should go with the driver change. But if this is a
simple change related to generic attribute I can take it.
Regards,
Benoit
>
>> ---
>>
>> v2: node name changed to "usb"
>>
>> .../devicetree/bindings/usb/am33xx-usb.txt | 21
>> +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> index a922505..ea840f7 100644
>> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
>> @@ -1,5 +1,7 @@
>> AM33XX MUSB GLUE
>> - compatible : Should be "ti,musb-am33xx"
>> + - reg : offset and length of register sets, first usbss, then for musb
>> instances
>> + - interrupts : usbss, musb instance interrupts in order
>> - ti,hwmods : must be "usb_otg_hs"
>> - multipoint : Should be "1" indicating the musb controller supports
>> multipoint. This is a MUSB configuration-specific setting.
>> @@ -12,3 +14,22 @@ AM33XX MUSB GLUE
>> represents PERIPHERAL.
>> - power : Should be "250". This signifies the controller can supply upto
>> 500mA when operating in host mode.
>> +
>> +Example:
>> +
>> +usb@4740 {
>> +compatible = "ti,musb-am33xx";
>> +reg = <0x4740 0x1000/* usbss */
>> + 0x47401000 0x800 /* musb instance 0 */
>> + 0x47401800 0x800>; /* musb instance 1 */
>> +interrupts = <17/* usbss */
>> + 18/* musb instance 0 */
>> + 19>; /* musb instance 1 */
>> +multipoint = <1>;
>> +num-eps = <16>;
>> +ram-bits = <12>;
>> +port0-mode = <3>;
>> +port1-mode = <3>;
>> +power = <250>;
>> +ti,hwmods = "usb_otg_hs";
>> +};
>> --
>> 1.7.12
>>
>
--
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: Fresco Logic Problem
On Tue, Nov 06, 2012 at 11:03:10AM +0330, A Sh wrote: > > So you patched 3.2 with the patch I sent you, and it worked? > > yes, I did. Ok, great, I will send that patch upstream. > > You mean this one? > > >> I had also a suggestion: > >> make xhci module work in three mode: > >> 1. without msi/msi-X > >> 2. with msi and without msi-x > >> 3. with both msi and msi-x > > > That is basically what the driver does (aside from the fact that MSI and > > MSI-X cannot be enabled at the same time, you can only have one or the > > other). The driver tries to enable MSI-X, and falls back to MSI if that > > fails. If MSI enabling fails, it falls back to legacy IRQ (no MSI or > > MSI-X). Your hardware is just broken because it reports that it can > > provide MSI, and then fails to do so. > > Yes I was referring to that part, but I mean it can be possible to > implement something (module modes for instance) by which user can force > module to stop using for example MSI-X with these commands: > > # sudo rmmod xhci-hcd > # cd /lib/module/ 'kernel version' /kernel/drivers/usb/host > # sudo insmod xhci.ko interrupt_mode=1 (I don't know which module we should > implement this for as I see no xhci.ko! ) It's drivers/usb/host/xhci-hcd.ko. > where interrupt_mode can be 0,1,2 and each one is one of explained > conditions. We try to avoid module parameters, because it's confusing. Also, distros will always leave them at the default, which means you might as well not have them at all. Any module parameter besides the default isn't going to be well-tested either. I know it's a pain to recompile a kernel, but it doesn't make sense to expose every single option to userspace. So we pick a sane default, and work around any quirks in the kernel driver. Sarah Sharp > > On Mon, Nov 5, 2012 at 9:13 PM, Sarah Sharp > wrote: > > > On Sat, Nov 03, 2012 at 09:42:18AM +0330, A Sh wrote: > > > Hello Ms.Sharp, > > > > > > I checked with 3.2 kernel(provided with my official distribution repos) > > and > > > it worked. > > > > So you patched 3.2 with the patch I sent you, and it worked? > > > > > Do you have any idea when it will be available in official distro repos? > > > > I have no control over *when* it gets in, but the patch will be marked > > for stable, and distros will be notified to pick it up. > > > > > By the way what about making the module work in three modes as I told > > > before, this way we don't have to apply patches everytime there is such > > > hardwares. > > > > You mean this one? > > > > > I had also a suggestion: > > > make xhci module work in three mode: > > > 1. without msi/msi-X > > > 2. with msi and without msi-x > > > 3. with both msi and msi-x > > > > That is basically what the driver does (aside from the fact that MSI and > > MSI-X cannot be enabled at the same time, you can only have one or the > > other). The driver tries to enable MSI-X, and falls back to MSI if that > > fails. If MSI enabling fails, it falls back to legacy IRQ (no MSI or > > MSI-X). Your hardware is just broken because it reports that it can > > provide MSI, and then fails to do so. > > > > Sarah Sharp > > > > > On Fri, Oct 19, 2012 at 12:59 AM, Sarah Sharp < > > sarah.a.sh...@linux.intel.com > > > > wrote: > > > > > > > On Thu, Oct 18, 2012 at 08:15:57AM +0330, A Sh wrote: > > > > > You told you will send me directions to compile a custom kernel. > > > > > > > > Ok, here's some instructions for how to compile a custom kernel: > > > > > > > > http://kernelnewbies.org/KernelBuild > > > > > > > > Please download the latest stable kernel (currently v3.6.2), patch it > > > > with the attached patch, compile, and reboot. Let me know if you have > > > > any questions about the directions. > > > > > > > > > Is it necessary to compile the whole kernel or it's possible to only > > > > build > > > > > related modules and parts? > > > > > > > > Unfortunately, for the first time, you'll need to re-compile the whole > > > > kernel. Later on, you can use the directions in the "Tips and Tricks" > > > > sections to just compile one module, like the xHCI driver. > > > > > > > > > By the way my notebook isn't with me I won't be able to try this > > perhaps > > > > in > > > > > two weeks so sorry for delay in advance. > > > > > > > > Ok. Let me know how it goes. > > > > > > > > Sarah Sharp > > > > > > > > > On Thu, Oct 18, 2012 at 12:30 AM, Sarah Sharp < > > > > sarah.a.sh...@linux.intel.com > > > > > > wrote: > > > > > > > > > > > Hi Ali, > > > > > > > > > > > > Sorry for the long response time! Can you try to apply the > > attached > > > > > > patch, recompile your kernel, and see if it fixes your issues? > > > > > > > > > > > > Thanks, > > > > > > Sarah Sharp > > > > > > > > > > > > On Wed, Oct 17, 2012 at 03:51:30PM +0330, A Sh wrote: > > > > > > > Excuse me Ms.Sharp, > > > > > > > did you recieve my message. > > > > > > > > > > > > > > I had also a suggestion: > > > > > > > make xhci module work in three mode: > > > > > > > 1. withou
Re: Force usb to use same port number for re/boot or re insert
Ok, I don't understand what you're trying to do, and it doesn't really
sound like a kernel question. Why not ask on Stack Overflow or some
other Android forum?
Sarah Sharp
On Fri, Nov 02, 2012 at 07:55:27AM +0530, $rik@nth wrote:
> Server will run on the device port only. so that's why i wanted to create a
> dev rule to solve me problem temporarily. More over I have tried with
>
> SUBSYSTEMS=="usb", ATTRS{busnum}=="1",ACTION=="add",SYMLINK+="myphone"
>
>
> But the problem is when the devices goes into BP mode it is mounting all
> partitions and i am unable to handle this situation.
>
>
> On Fri, Nov 2, 2012 at 1:02 AM, Sarah Sharp
> wrote:
>
> > On Thu, Nov 01, 2012 at 10:10:07PM +0530, $rik@nth wrote:
> > > Android is not giving any abstract layer for this kind of scenarios.
> > >
> > > I heard that using udev rule we can solve the problem. But that is also
> > not
> > > the right way to do it, so thought of asking for experts thoughts.
> >
> > What problem are you trying to solve?
> >
> > And if you're trying to write a udev rule, why not just trigger off the
> > device vendor and product ID, rather than some random device address?
> >
> > Sarah Sharp
> >
> > > On Thu, Nov 1, 2012 at 9:56 PM, Sarah Sharp
> > > wrote:
> > >
> > > > On Wed, Oct 31, 2012 at 02:27:04PM +0530, $rik@nth wrote:
> > > > > Hi Sarah,
> > > > >
> > > > > I need some help regarding the usb devices(Android based mobiles).,
> > > > >
> > > > > I am having some trouble in automating the task. I am testing some
> > > > android
> > > > > based mobiles in linux machine. The automation script uses the
> > device id
> > > > > under "/dev/bus/usb/001/"053" it will be always under bus 001 only..
> > But
> > > > > the dev id will be random like if i insert one mobile then the dev id
> > > > will
> > > > > be 053, if remove and insert it again then the dev id will be 054..
> > > >
> > > > That's the device address, not the device ID.
> > > >
> > > > And note that if there are two host controllers (which is probably not
> > > > likely with a smart phone, but may be possible with a tablet), then the
> > > > bus numbers might change as well across reboots. One bus may be
> > > > enumerated before the other for one boot, and get bus number 1, while
> > on
> > > > the next boot it gets bus number 2.
> > > >
> > > > > The problem is, when some tests runs on the device and if device gets
> > > > > rebooted then new dev id is showing for the rebooted one and my
> > scripts
> > > > > failing due to new dev id..
> > > > >
> > > > > Is there any way to force usb devices to use same dev id instead of
> > new
> > > > > one. So that there will be no issues to my tests even after device
> > > > reboots.
> > > >
> > > > No, there isn't. The USB core goes through device addresses
> > > > incrementally, and that's not something you can change.
> > > >
> > > > The bigger question here is *why* you need to dig around in the sysfs
> > > > files. Doesn't Android give you some higher level abstraction that you
> > > > should be using instead?
> > > >
> > > > Sarah Sharp
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks & Regards,
> > > M.Srikanth Kumar.
> >
>
>
>
> --
> Thanks & Regards,
> M.Srikanth Kumar.
--
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: 3TB Hard Drive in USB Enclosure Resetting
On Tue, 6 Nov 2012, Jason J. Herne wrote: > Here is the pcap file, as captured from Wireshark. > > On Tue, Nov 6, 2012 at 10:46 AM, Alan Stern wrote: > > On Mon, 5 Nov 2012, Jason J. Herne wrote: > > > >> I have a Seagate ST3000DM 3.0TB Sata Drive enclosed in a Vantec > >> NexStar CX USB 3.0/2.0 Enclosure. This enclosure/drive is not > >> properly recognized by Linux when plugged in via a USB 2.0 port. My > >> dmesg output, at first, seems like all is well. but then the drive > >> activity light starts flashing rapidly and never stops. After 20-30 > >> seconds I see a "reset high-speed USB device" message. The /dev/sdx > >> device node is created for the drive, but no sdxN nodes are created > >> and any program accessing the /dev/sdx node hangs. I have tried this > >> drive with 3 different computers all running Ubuntu 12.04 (kernel > >> 3.2.0-30-generic-pae) or Ubuntu 11.10 (kernel 3.0.0-12). I have also > >> tried the 3.7.0-rc4-next kernel. The problem persists on all of the > >> above kernels. > >> > >> It is worth noting that the drive is properly recognized by Windows 7 > >> running on the same hardware as my Ubuntu install. > >> > >> I am providing some output that I hope is useful for diagnosing the > >> problem. I can collect more if needed. I can also provide the raw > >> tcpdump capture file as saved by Wireshark. I don't understand much > >> of the trace I collected, but it seems to get interesting around Frame > >> 108: URB status: Remote I/O error (-EREMOTEIO) (-121). The trace shows that everything works perfectly up until the first READ command sent to the drive. The computer tries to read the first 8 blocks (4096 bytes) from the drive, but the drive sends no data back at all. After 30 seconds the computer gives up and tries to reset the drive. There's no easy way to tell what's different about Windows. Maybe a USB log of the Windows interaction would show something, maybe not. 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
Re: [PATCH v2] usb: musb: dsps: dt binding - add resources, example
Hi, On Tue, Nov 06, 2012 at 05:58:57PM +0100, Benoit Cousson wrote: > On 11/06/2012 05:44 PM, Felipe Balbi wrote: > > Hi, > > > > On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote: > >> OMAP2+ family of devices are now obtaining resources via DT, earlier > >> it was obtained from hwmod. Update binding document accrodingly, while > >> at it add example. > >> > >> Signed-off-by: Afzal Mohammed > > > > this looks fine to me: > > > > Reviewed-by: Felipe Balbi > > > > Benoit, do you take Documentation patches too ? > > Well, ideally it should go with the driver change. But if this is a > simple change related to generic attribute I can take it. ok, cool. Please take this via your tree. thanks -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Felipe Balbi [121106 03:40]: > Hi, > > On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: > > From: Michal Nazarewicz > > > > The File-backed Storage Gadget (g_file_storage) is being removed, since > > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit > > changes defconfigs point to the new gadget. > > > > Signed-off-by: Michal Nazarewicz > > I need more Acks here. Only got one from Nicolas. Anyone else ? For omaps: Acked-by: Tony Lindgren -- 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: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Tony Lindgren [121106 10:41]: > * Felipe Balbi [121106 03:40]: > > Hi, > > > > On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: > > > From: Michal Nazarewicz > > > > > > The File-backed Storage Gadget (g_file_storage) is being removed, since > > > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit > > > changes defconfigs point to the new gadget. > > > > > > Signed-off-by: Michal Nazarewicz > > > > I need more Acks here. Only got one from Nicolas. Anyone else ? > > For omaps: > > Acked-by: Tony Lindgren Heh I guess no omap changes there, so probably not worth adding then. Tony -- 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] HID: Ignore D-WAV/eGalax devices handled by usbtouchscreen
From: Forest Bond
Previously, both usbhid and usbtouchscreen would bind to D-WAV devices
with class HID and protocol None, so they would be claimed by whichever
driver was loaded first. Some of these devices do in fact work with
usbhid, but not all of them do. OTOH they all work with usbtouchscreen
as of commit 037a833ed05a86d01ea27a2c32043b86c549be1b ("Input:
usbtouchscreen - initialize eGalax devices"). So we ignore them in
usbhid to prevent getting in the way of usbtouchscreen and claiming an
interface that we may not be able to do anything useful with.
Signed-off-by: Forest Bond
---
drivers/hid/hid-core.c | 11 ++-
drivers/hid/hid-ids.h |1 +
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f4109fd..f2d614e 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2188,7 +2188,16 @@ static bool hid_ignore(struct hid_device *hdev)
if (hdev->product == USB_DEVICE_ID_JESS_YUREX &&
hdev->type == HID_TYPE_USBNONE)
return true;
- break;
+ break;
+ case USB_VENDOR_ID_DWAV:
+ /* These are handled by usbtouchscreen. hdev->type is probably
+* HID_TYPE_USBNONE, but we say !HID_TYPE_USBMOUSE to match
+* usbtouchscreen. */
+ if ((hdev->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER ||
+hdev->product == USB_DEVICE_ID_DWAV_TOUCHCONTROLLER) &&
+ hdev->type != HID_TYPE_USBMOUSE)
+ return true;
+ break;
}
if (hdev->type == HID_TYPE_USBMOUSE &&
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9d7a428..3d73774 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -257,6 +257,7 @@
#define USB_VENDOR_ID_DWAV 0x0eef
#define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER 0x0001
+#define USB_DEVICE_ID_DWAV_TOUCHCONTROLLER 0x0002
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_480D 0x480d
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_480E 0x480e
#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_7207 0x7207
--
1.7.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 1/3] usb: musb: drop useless board_mode usage
Hello. On 08/09/2012 12:47 PM, Felipe Balbi wrote: >>> we are compiling the driver always with full OTG >>> capabilities, so that board_mode trick becomes >>> useless. >>> Signed-off-by: Felipe Balbi >>> --- >>> I would like to get Acks from blackfin, da8xx and davinci guys, please. >>After having looked thru the patch, I have a few questions... Heh, only noticed this reply and the recast patch now. By incident, August 9th was the day I entered the hospital and was cut off from email. :-) Thanks for resuming the work on the patch, and finally committing it. 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
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
Hi, On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote: > * Tony Lindgren [121106 10:41]: > > * Felipe Balbi [121106 03:40]: > > > Hi, > > > > > > On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: > > > > From: Michal Nazarewicz > > > > > > > > The File-backed Storage Gadget (g_file_storage) is being removed, since > > > > it has been replaced by Mass Storage Gadget (g_mass_storage). This > > > > commit > > > > changes defconfigs point to the new gadget. > > > > > > > > Signed-off-by: Michal Nazarewicz > > > > > > I need more Acks here. Only got one from Nicolas. Anyone else ? > > > > For omaps: > > > > Acked-by: Tony Lindgren > > Heh I guess no omap changes there, so probably not > worth adding then. omap1 is old, but it's still omap :-) arch/arm/configs/omap1_defconfig |3 +-- -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
* Felipe Balbi [121106 12:40]: > Hi, > > On Tue, Nov 06, 2012 at 10:42:27AM -0800, Tony Lindgren wrote: > > * Tony Lindgren [121106 10:41]: > > > * Felipe Balbi [121106 03:40]: > > > > Hi, > > > > > > > > On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: > > > > > From: Michal Nazarewicz > > > > > > > > > > The File-backed Storage Gadget (g_file_storage) is being removed, > > > > > since > > > > > it has been replaced by Mass Storage Gadget (g_mass_storage). This > > > > > commit > > > > > changes defconfigs point to the new gadget. > > > > > > > > > > Signed-off-by: Michal Nazarewicz > > > > > > > > I need more Acks here. Only got one from Nicolas. Anyone else ? > > > > > > For omaps: > > > > > > Acked-by: Tony Lindgren > > > > Heh I guess no omap changes there, so probably not > > worth adding then. > > omap1 is old, but it's still omap :-) > > arch/arm/configs/omap1_defconfig |3 +-- Oh OK so it was not a spurious ack after all :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
cdc_eem USB host driver and gadget driver both are broken in 1500 MTU case when using 802.1Q VLANs. In both cases, this is due to incomplete assumptions of Ethernet frame size. Ian Coolidge (2): usb: gadget: g_ether: fix frame size check net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs drivers/net/usb/cdc_eem.c|4 drivers/usb/gadget/u_ether.c |3 ++- 2 files changed, 6 insertions(+), 1 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: gadget: g_ether: fix frame size check
Checking skb->len against ETH_FRAME_LEN assumes a 1514
ethernet frame size. With an 802.1Q VLAN header, ethernet
frame length can now be 1518. Validate frame length against that.
Signed-off-by: Ian Coolidge
---
drivers/usb/gadget/u_ether.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 29c854b..ff2c70b 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "u_ether.h"
@@ -301,7 +302,7 @@ static void rx_complete(struct usb_ep *ep, struct
usb_request *req)
while (skb2) {
if (status < 0
|| ETH_HLEN > skb2->len
- || skb2->len > ETH_FRAME_LEN) {
+ || skb2->len > VLAN_ETH_FRAME_LEN) {
dev->net->stats.rx_errors++;
dev->net->stats.rx_length_errors++;
DBG(dev, "rx length %d\n", skb2->len);
--
1.7.6.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 2/2] net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
cdc_eem frames might need to contain 802.1Q VLAN Ethernet frames. Provide this information as an override to usbnet->rx_urb_size Signed-off-by: Ian Coolidge --- drivers/net/usb/cdc_eem.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c index 439690b..63c38dc 100644 --- a/drivers/net/usb/cdc_eem.c +++ b/drivers/net/usb/cdc_eem.c @@ -31,6 +31,7 @@ #include #include #include +#include /* @@ -94,6 +95,9 @@ static int eem_bind(struct usbnet *dev, struct usb_interface *intf) dev->net->hard_header_len += EEM_HEAD + ETH_FCS_LEN; + /* octets we need to rx for a single ethernet frame */ + dev->rx_urb_size = EEM_HEAD + ETH_FCS_LEN + VLAN_ETH_FRAME_LEN; + return 0; } -- 1.7.6.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
[PATCHv3 0/6] Some USB gadget cleanups
From: Michal Nazarewicz v2 has the first patch fixed as pointed by Alan. This patchset remove the following: - the File-backed Storage Gadget (g_file_storage), and - is_dualspeed file and line referenced in sysfs. Once g_file_storage is removed, it also does some cleanup inside of the storage_common.c file. Based on top of felipe/gadget (b100a2f34dc160502bf7d3006cd8294303bbfacb). Previous version compile tested with allmodconfig on x86_64. Michal Nazarewicz (6): arch: Change defconfigs to point to g_mass_storage. usb: gadget: Remove File-backed Storage Gadget (g_file_storage). usb: gadget: storage_common: Remove FSG specific definitions. usb: gadget: storage_common: Drop #ifdefs used for the sake of FSG. usb: gadget: storage_common: Make fsg_lun_is_open() a function. usb: gadget: Remove reference to is_dualspeed from sysfs. Documentation/DocBook/gadget.tmpl |2 +- Documentation/usb/mass-storage.txt | 15 +- arch/arm/configs/afeb9260_defconfig|2 +- arch/arm/configs/at91sam9260_defconfig |2 +- arch/arm/configs/at91sam9261_defconfig |2 +- arch/arm/configs/at91sam9263_defconfig |2 +- arch/arm/configs/at91sam9g20_defconfig |2 +- arch/arm/configs/corgi_defconfig |2 +- arch/arm/configs/davinci_all_defconfig |2 +- arch/arm/configs/h7202_defconfig |3 +- arch/arm/configs/magician_defconfig|2 +- arch/arm/configs/mini2440_defconfig|2 +- arch/arm/configs/omap1_defconfig |3 +- arch/arm/configs/prima2_defconfig |1 - arch/arm/configs/spitz_defconfig |2 +- arch/arm/configs/stamp9g20_defconfig |2 +- arch/arm/configs/viper_defconfig |2 +- arch/arm/configs/zeus_defconfig|2 +- arch/avr32/configs/atngw100_defconfig |2 +- arch/avr32/configs/atngw100_evklcd100_defconfig|2 +- arch/avr32/configs/atngw100_evklcd101_defconfig|2 +- arch/avr32/configs/atngw100_mrmt_defconfig |2 +- arch/avr32/configs/atngw100mkii_defconfig |2 +- .../avr32/configs/atngw100mkii_evklcd100_defconfig |2 +- .../avr32/configs/atngw100mkii_evklcd101_defconfig |2 +- arch/avr32/configs/atstk1002_defconfig |2 +- arch/avr32/configs/atstk1003_defconfig |2 +- arch/avr32/configs/atstk1004_defconfig |2 +- arch/avr32/configs/atstk1006_defconfig |2 +- arch/avr32/configs/favr-32_defconfig |2 +- arch/avr32/configs/hammerhead_defconfig|2 +- arch/blackfin/configs/CM-BF527_defconfig |2 +- arch/blackfin/configs/CM-BF548_defconfig |2 +- arch/blackfin/configs/CM-BF561_defconfig |2 +- arch/mips/configs/bcm47xx_defconfig|2 +- arch/mips/configs/mtx1_defconfig |2 +- arch/sh/configs/ecovec24_defconfig |2 +- arch/sh/configs/se7724_defconfig |2 +- drivers/usb/chipidea/debug.c |3 - drivers/usb/gadget/Kconfig | 29 +- drivers/usb/gadget/Makefile|2 - drivers/usb/gadget/f_mass_storage.c|4 - drivers/usb/gadget/file_storage.c | 3656 drivers/usb/gadget/net2280.c |2 +- drivers/usb/gadget/pxa27x_udc.h|2 +- drivers/usb/gadget/storage_common.c| 165 +- drivers/usb/gadget/udc-core.c | 11 - 47 files changed, 52 insertions(+), 3912 deletions(-) delete mode 100644 drivers/usb/gadget/file_storage.c -- 1.7.7.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
[PATCHv3 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Michal Nazarewicz The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz Acked-by: Nicolas Ferre (fort AT91) Acked-by: Tony Lindgren (for omap1) --- arch/arm/configs/afeb9260_defconfig|2 +- arch/arm/configs/at91sam9260_defconfig |2 +- arch/arm/configs/at91sam9261_defconfig |2 +- arch/arm/configs/at91sam9263_defconfig |2 +- arch/arm/configs/at91sam9g20_defconfig |2 +- arch/arm/configs/corgi_defconfig |2 +- arch/arm/configs/davinci_all_defconfig |2 +- arch/arm/configs/h7202_defconfig |3 +-- arch/arm/configs/magician_defconfig|2 +- arch/arm/configs/mini2440_defconfig|2 +- arch/arm/configs/omap1_defconfig |3 +-- arch/arm/configs/prima2_defconfig |1 - arch/arm/configs/spitz_defconfig |2 +- arch/arm/configs/stamp9g20_defconfig |2 +- arch/arm/configs/viper_defconfig |2 +- arch/arm/configs/zeus_defconfig|2 +- arch/avr32/configs/atngw100_defconfig |2 +- arch/avr32/configs/atngw100_evklcd100_defconfig|2 +- arch/avr32/configs/atngw100_evklcd101_defconfig|2 +- arch/avr32/configs/atngw100_mrmt_defconfig |2 +- arch/avr32/configs/atngw100mkii_defconfig |2 +- .../avr32/configs/atngw100mkii_evklcd100_defconfig |2 +- .../avr32/configs/atngw100mkii_evklcd101_defconfig |2 +- arch/avr32/configs/atstk1002_defconfig |2 +- arch/avr32/configs/atstk1003_defconfig |2 +- arch/avr32/configs/atstk1004_defconfig |2 +- arch/avr32/configs/atstk1006_defconfig |2 +- arch/avr32/configs/favr-32_defconfig |2 +- arch/avr32/configs/hammerhead_defconfig|2 +- arch/blackfin/configs/CM-BF527_defconfig |2 +- arch/blackfin/configs/CM-BF548_defconfig |2 +- arch/blackfin/configs/CM-BF561_defconfig |2 +- arch/mips/configs/bcm47xx_defconfig|2 +- arch/mips/configs/mtx1_defconfig |2 +- arch/sh/configs/ecovec24_defconfig |2 +- arch/sh/configs/se7724_defconfig |2 +- 36 files changed, 35 insertions(+), 38 deletions(-) diff --git a/arch/arm/configs/afeb9260_defconfig b/arch/arm/configs/afeb9260_defconfig index c285a9d..a8dbc1e 100644 --- a/arch/arm/configs/afeb9260_defconfig +++ b/arch/arm/configs/afeb9260_defconfig @@ -79,7 +79,7 @@ CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_RTC_CLASS=y CONFIG_RTC_DEBUG=y diff --git a/arch/arm/configs/at91sam9260_defconfig b/arch/arm/configs/at91sam9260_defconfig index 505b376..0ea5d2c 100644 --- a/arch/arm/configs/at91sam9260_defconfig +++ b/arch/arm/configs/at91sam9260_defconfig @@ -75,7 +75,7 @@ CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_AT91SAM9=y diff --git a/arch/arm/configs/at91sam9261_defconfig b/arch/arm/configs/at91sam9261_defconfig index 1e8712e..c87beb9 100644 --- a/arch/arm/configs/at91sam9261_defconfig +++ b/arch/arm/configs/at91sam9261_defconfig @@ -125,7 +125,7 @@ CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_ETH=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_MMC=y CONFIG_MMC_ATMELMCI=m diff --git a/arch/arm/configs/at91sam9263_defconfig b/arch/arm/configs/at91sam9263_defconfig index d2050ca..c5212f4 100644 --- a/arch/arm/configs/at91sam9263_defconfig +++ b/arch/arm/configs/at91sam9263_defconfig @@ -133,7 +133,7 @@ CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_ETH=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_MMC=y CONFIG_SDIO_UART=m diff --git a/arch/arm/configs/at91sam9g20_defconfig b/arch/arm/configs/at91sam9g20_defconfig index e1b0e80..3b18810 100644 --- a/arch/arm/configs/at91sam9g20_defconfig +++ b/arch/arm/configs/at91sam9g20_defconfig @@ -96,7 +96,7 @@ CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_MMC=y CONFIG_MMC_ATMELMCI=m diff --git a/arch/arm/configs/corgi_defconfig b/arch/arm/configs/corgi_defconfig index 4b8a25d..1fd1d1d 100644 --- a/arch/arm/configs/corgi_defconfig +++ b/arch/arm/configs/corgi_defconfig @@ -218,7 +218,7 @@ CONFIG_USB_GADGET=y
[PATCHv3 3/6] usb: gadget: storage_common: Remove FSG specific definitions.
From: Michal Nazarewicz Since g_file_storage has been removed, this commit removes code from the storage_common.c file which has been used by file_storage.c only (and not by f_mass_storage.c). Signed-off-by: Michal Nazarewicz --- drivers/usb/gadget/storage_common.c | 28 1 files changed, 0 insertions(+), 28 deletions(-) diff --git a/drivers/usb/gadget/storage_common.c b/drivers/usb/gadget/storage_common.c index 14199d7..b381e0c 100644 --- a/drivers/usb/gadget/storage_common.c +++ b/drivers/usb/gadget/storage_common.c @@ -78,34 +78,6 @@ #define LWARN(lun, fmt, args...) dev_warn(&(lun)->dev, fmt, ## args) #define LINFO(lun, fmt, args...) dev_info(&(lun)->dev, fmt, ## args) -/* - * Keep those macros in sync with those in - * include/linux/usb/composite.h or else GCC will complain. If they - * are identical (the same names of arguments, white spaces in the - * same places) GCC will allow redefinition otherwise (even if some - * white space is removed or added) warning will be issued. - * - * Those macros are needed here because File Storage Gadget does not - * include the composite.h header. For composite gadgets those macros - * are redundant since composite.h is included any way. - * - * One could check whether those macros are already defined (which - * would indicate composite.h had been included) or not (which would - * indicate we were in FSG) but this is not done because a warning is - * desired if definitions here differ from the ones in composite.h. - * - * We want the definitions to match and be the same in File Storage - * Gadget as well as Mass Storage Function (and so composite gadgets - * using MSF). If someone changes them in composite.h it will produce - * a warning in this file when building MSF. - */ -#define DBG(d, fmt, args...) dev_dbg(&(d)->gadget->dev , fmt , ## args) -#define VDBG(d, fmt, args...)dev_vdbg(&(d)->gadget->dev , fmt , ## args) -#define ERROR(d, fmt, args...) dev_err(&(d)->gadget->dev , fmt , ## args) -#define WARNING(d, fmt, args...) dev_warn(&(d)->gadget->dev , fmt , ## args) -#define INFO(d, fmt, args...)dev_info(&(d)->gadget->dev , fmt , ## args) - - #ifdef DUMP_MSGS -- 1.7.7.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
[PATCHv3 4/6] usb: gadget: storage_common: Drop #ifdefs used for the sake of FSG.
From: Michal Nazarewicz
storage_common.c has been used by both file_storage.c and f_mass_storage.c
which had some different requirements in a few places. To accomodate for
that, storage_common.c provided configuratian macros which were to be
defined (or not) prior to the file #inclusion. Because now
file_storage.c is no longer with us, we can remove support for those
macros and thus simplify the code slightly.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/f_mass_storage.c |4 -
drivers/usb/gadget/storage_common.c | 130 ---
2 files changed, 0 insertions(+), 134 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 3433e43..5d027b3 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -228,10 +228,6 @@
static const char fsg_string_interface[] = "Mass Storage";
-#define FSG_NO_DEVICE_STRINGS1
-#define FSG_NO_OTG 1
-#define FSG_NO_INTR_EP 1
-
#include "storage_common.c"
diff --git a/drivers/usb/gadget/storage_common.c
b/drivers/usb/gadget/storage_common.c
index b381e0c..1b5bc69 100644
--- a/drivers/usb/gadget/storage_common.c
+++ b/drivers/usb/gadget/storage_common.c
@@ -11,30 +11,10 @@
* (at your option) any later version.
*/
-
/*
* This file requires the following identifiers used in USB strings to
* be defined (each of type pointer to char):
- * - fsg_string_manufacturer -- name of the manufacturer
- * - fsg_string_product -- name of the product
- * - fsg_string_config -- name of the configuration
* - fsg_string_interface-- name of the interface
- * The first four are only needed when FSG_DESCRIPTORS_DEVICE_STRINGS
- * macro is defined prior to including this file.
- */
-
-/*
- * When FSG_NO_INTR_EP is defined fsg_fs_intr_in_desc and
- * fsg_hs_intr_in_desc objects as well as
- * FSG_FS_FUNCTION_PRE_EP_ENTRIES and FSG_HS_FUNCTION_PRE_EP_ENTRIES
- * macros are not defined.
- *
- * When FSG_NO_DEVICE_STRINGS is defined FSG_STRING_MANUFACTURER,
- * FSG_STRING_PRODUCT, FSG_STRING_SERIAL and FSG_STRING_CONFIG are not
- * defined (as well as corresponding entries in string tables are
- * missing) and FSG_STRING_INTERFACE has value of zero.
- *
- * When FSG_NO_OTG is defined fsg_otg_desc won't be defined.
*/
/*
@@ -280,26 +260,10 @@ static inline u32 get_unaligned_be24(u8 *buf)
enum {
-#ifndef FSG_NO_DEVICE_STRINGS
- FSG_STRING_MANUFACTURER = 1,
- FSG_STRING_PRODUCT,
- FSG_STRING_SERIAL,
- FSG_STRING_CONFIG,
-#endif
FSG_STRING_INTERFACE
};
-#ifndef FSG_NO_OTG
-static struct usb_otg_descriptor
-fsg_otg_desc = {
- .bLength = sizeof fsg_otg_desc,
- .bDescriptorType = USB_DT_OTG,
-
- .bmAttributes = USB_OTG_SRP,
-};
-#endif
-
/* There is only one interface. */
static struct usb_interface_descriptor
@@ -339,37 +303,10 @@ fsg_fs_bulk_out_desc = {
/* wMaxPacketSize set by autoconfiguration */
};
-#ifndef FSG_NO_INTR_EP
-
-static struct usb_endpoint_descriptor
-fsg_fs_intr_in_desc = {
- .bLength = USB_DT_ENDPOINT_SIZE,
- .bDescriptorType = USB_DT_ENDPOINT,
-
- .bEndpointAddress = USB_DIR_IN,
- .bmAttributes = USB_ENDPOINT_XFER_INT,
- .wMaxPacketSize = cpu_to_le16(2),
- .bInterval =32, /* frames -> 32 ms */
-};
-
-#ifndef FSG_NO_OTG
-# define FSG_FS_FUNCTION_PRE_EP_ENTRIES 2
-#else
-# define FSG_FS_FUNCTION_PRE_EP_ENTRIES 1
-#endif
-
-#endif
-
static struct usb_descriptor_header *fsg_fs_function[] = {
-#ifndef FSG_NO_OTG
- (struct usb_descriptor_header *) &fsg_otg_desc,
-#endif
(struct usb_descriptor_header *) &fsg_intf_desc,
(struct usb_descriptor_header *) &fsg_fs_bulk_in_desc,
(struct usb_descriptor_header *) &fsg_fs_bulk_out_desc,
-#ifndef FSG_NO_INTR_EP
- (struct usb_descriptor_header *) &fsg_fs_intr_in_desc,
-#endif
NULL,
};
@@ -403,37 +340,11 @@ fsg_hs_bulk_out_desc = {
.bInterval =1, /* NAK every 1 uframe */
};
-#ifndef FSG_NO_INTR_EP
-
-static struct usb_endpoint_descriptor
-fsg_hs_intr_in_desc = {
- .bLength = USB_DT_ENDPOINT_SIZE,
- .bDescriptorType = USB_DT_ENDPOINT,
-
- /* bEndpointAddress copied from fs_intr_in_desc during fsg_bind() */
- .bmAttributes = USB_ENDPOINT_XFER_INT,
- .wMaxPacketSize = cpu_to_le16(2),
- .bInterval =USB_MS_TO_HS_INTERVAL(32), /* 32 ms */
-};
-
-#ifndef FSG_NO_OTG
-# define FSG_HS_FUNCTION_PRE_EP_ENTRIES 2
-#else
-# define FSG_HS_FUNCTION_PRE_EP_ENTRIES 1
-#endif
-
-#endif
static struct usb_descriptor_header *fsg_hs_function[] = {
-#ifndef FSG_NO_OTG
- (struct usb_descriptor_header *) &fsg_otg_desc,
-#endif
(struct usb_descriptor_header *) &fsg_intf_desc,
(struct usb_
[PATCHv3 5/6] usb: gadget: storage_common: Make fsg_lun_is_open() a function.
From: Michal Nazarewicz
Since function-line macros are to be avoided, this commit replaces
the fsg_lun_is_open() macro with a static inline function.
While at it, this commit also adds “inline” modifier to the
fsg_lun_from_dev() function.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/storage_common.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/storage_common.c
b/drivers/usb/gadget/storage_common.c
index 1b5bc69..0e3ae43 100644
--- a/drivers/usb/gadget/storage_common.c
+++ b/drivers/usb/gadget/storage_common.c
@@ -155,9 +155,12 @@ struct fsg_lun {
struct device dev;
};
-#define fsg_lun_is_open(curlun)((curlun)->filp != NULL)
+static inline bool fsg_lun_is_open(struct fsg_lun *curlun)
+{
+ return curlun->filp != NULL;
+}
-static struct fsg_lun *fsg_lun_from_dev(struct device *dev)
+static inline struct fsg_lun *fsg_lun_from_dev(struct device *dev)
{
return container_of(dev, struct fsg_lun, dev);
}
--
1.7.7.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
[PATCHv3 6/6] usb: gadget: Remove reference to is_dualspeed from sysfs.
From: Michal Nazarewicz
This commit removes the /sys/devices/platform//udc//is_dualspeed
file and is_dualspeeed line from /sys/devices/platform/ci13xxx_*/udc/device
file.
The is_dualspeed file is superseded by maximum_speed in the same directory
and is_dualspeed line in device file is superseded by max_speed line in
the same file.
The maximum_speed/max_speed specifies maximum speed supported by UDC.
To check if dualspeeed is supported, check if the value is >= 3.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/chipidea/debug.c |3 ---
drivers/usb/gadget/udc-core.c | 11 ---
2 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index c6f50a2..3bc244d 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -160,9 +160,6 @@ static ssize_t show_device(struct device *dev, struct
device_attribute *attr,
gadget->speed);
n += scnprintf(buf + n, PAGE_SIZE - n, "max_speed = %d\n",
gadget->max_speed);
- /* TODO: Scheduled for removal in 3.8. */
- n += scnprintf(buf + n, PAGE_SIZE - n, "is_dualspeed = %d\n",
- gadget_is_dualspeed(gadget));
n += scnprintf(buf + n, PAGE_SIZE - n, "is_otg= %d\n",
gadget->is_otg);
n += scnprintf(buf + n, PAGE_SIZE - n, "is_a_peripheral = %d\n",
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index f3cd969..4d90a80 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -439,16 +439,6 @@ static DEVICE_ATTR(name, S_IRUSR, usb_udc_##param##_show,
NULL)
static USB_UDC_SPEED_ATTR(current_speed, speed);
static USB_UDC_SPEED_ATTR(maximum_speed, max_speed);
-/* TODO: Scheduled for removal in 3.8. */
-static ssize_t usb_udc_is_dualspeed_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct usb_udc *udc = container_of(dev, struct usb_udc, dev);
- return snprintf(buf, PAGE_SIZE, "%d\n",
- gadget_is_dualspeed(udc->gadget));
-}
-static DEVICE_ATTR(is_dualspeed, S_IRUSR, usb_udc_is_dualspeed_show, NULL);
-
#define USB_UDC_ATTR(name) \
ssize_t usb_udc_##name##_show(struct device *dev, \
struct device_attribute *attr, char *buf) \
@@ -472,7 +462,6 @@ static struct attribute *usb_udc_attrs[] = {
&dev_attr_current_speed.attr,
&dev_attr_maximum_speed.attr,
- &dev_attr_is_dualspeed.attr,
&dev_attr_is_otg.attr,
&dev_attr_is_a_peripheral.attr,
&dev_attr_b_hnp_enable.attr,
--
1.7.7.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
Re: generic wireless mouse not working
Is that sufficient? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021019/comments/42 Em 05-09-2012 04:23, Oliver Neukum escreveu: On Tuesday 04 September 2012 20:01:33 Marco Biscaro wrote: Hello all, I've opened a bug report about a wireless mouse problem [1], and Greg Kroah-Hartman told me to post the link on this list. Could anyone take a look on the bug? The problem was originally reported in Launchpad [2], and there is a patch [3], proposed by draekko (the original downstream reporter, which is CC'd). Hi, we need a patch with a "Signed-off-by" line of the original autor as documented in Documentation/SubmittingPatches Thank you Oliver -- 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: HDD spins up to slow for USB and/or Mass-Storage Driver
On Fri, Nov 02, 2012 at 10:42:19AM -0400, Alan Stern wrote: > On Thu, 1 Nov 2012, Matthias Schniedermeyer wrote: > > > > Okay, Matthias, here's an updated version of that patch. The only > > > difference is that it puts the usb_hcd_alloc_bandwidth() call _before_ > > > the usb_disable_interface() calls. > > > > This time it worked. The HDD showed up after the echo. > > Great! Alan, would you submit this patch and mark it for stable, if you haven't already done so? Thanks, Sarah Sharp -- 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: autodetect USB MTP device characteristics without libusb_open()
On Mon, Nov 5, 2012 at 11:31 PM, Bjørn Mork wrote:
> Linus Walleij writes:
> Excuse my lack of knowlegde here, but I have to ask why that is?
>
> I looked briefly at the MTP v1.1 spec from
So all MTP devices manufactured before that spec, and numerous produced
after that spec came out, and several still being produced don't use the
class code, i.e. they violate the spec. But we still have to detect them
somehow.
Here are some device logs I've been collecting:
http://libmtp.git.sourceforge.net/git/gitweb.cgi?p=libmtp/libmtp;a=tree;f=logs;hb=HEAD
Early devices look like this:
9Interface has a kernel driver attached.
10bcdUSB: 512
11bDeviceClass: 255
12bDeviceSubClass: 0
13bDeviceProtocol: 0
14idVendor: 041e
15idProduct: 4130
16IN endpoint maxpacket: 512 bytes
17OUT endpoint maxpacket: 512 bytes
18Raw device info:
19 Bus location: 2
20 Device number: 12
21 Device entry info:
22 Vendor: Creative
23 Vendor id: 0x041e
24 Product: ZEN Micro (MTP mode)
25 Vendor id: 0x4130
26 Device flags: 0x2001
This is the lsusb -v:
Bus 003 Device 004: ID 041e:4130 Creative Technology, Ltd Zen Micro (mtp)
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x041e Creative Technology, Ltd
idProduct 0x4130 Zen Micro (mtp)
bcdDevice1.00
iManufacturer 1 Creative Technology Ltd
iProduct2 Creative Zen Micro
iSerial 3 01052551C6038F82
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 16 Configuration 1
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 33 MTP Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 4
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x128a
(Bus Powered)
Remote Wakeup Enabled
The story goes that Microsoft was not allowed to use the scheme
in the specification before publication, so they stuck a custom
scheme in there and fallback methods to figure out if a
device is MTP.
And since device manufacturers only test their devices against
Windows, and since the Windows MTP stack is *very* tolerant
all kinds of weird stuff exist out there. And we get to deal with
it...
So for not-so-bad behaved devices this question is relevant:
> I realize that you still have to probe to find out whether it supports
> MTP or just PTP, but won't it help if this probing could be limited to
> only 06/01/01 interfaces?
So in the current device rule we have to match:
ATTR{bDeviceClass}=="00|02|06|ef|ff"
00 = unspecified, check interfaces, which cannot currently be done by udev
rules, I think, so we need to perform libusb_open() which will
screw up some devices...
02 = comms device class, a lot of phones use this
06 = yay! PTP yes among others...
ef = no idea why this is used, but it is
ff = as per above
While this cuts out a num
Re: problem with Roseweil eusb3 enclosure
On Sat, Nov 03, 2012 at 02:51:36AM -0400, cov...@ccs.covici.com wrote:
> OK, increasing the buffer size gives me the full syslog, which is
> enclosed. I am not sending the dmesg because I think we have it all
> now.
Thanks, that helped. Your port is coming up in compliance mode shortly
after it's powered on, which is kind of odd. The host controller seems
to need a longer-than-normal warm reset timeout in this case. I'm not
sure if the longer timeout will actually help, so I've also added code
to try a different method of bringing the port out of Compliance Mode
(disabling the port and re-enabling it).
Can you try the attached patch? I've only compile-tested it, so I'm not
sure if it will work.
Please send me dmesg from the start of the log with the patch applied,
even if it does work. I'd like to figure out which of the two solutions
helped.
Sarah Sharp
>From 6c11c297263ec4c87d226b30755da24bdae87fe4 Mon Sep 17 00:00:00 2001
From: Sarah Sharp
Date: Mon, 5 Nov 2012 17:46:55 -0800
Subject: [PATCH] USB: Disable and re-enable port on Compliance Mode.
The xHCI 1.0 spec says in section 4.19.1.2.7 that software can
transition a port from Compliance Mode to Reset by setting the Warm Port
Reset bit. However, the same section in the xHCI 0.96 spec does not
mention that state transition, even though the transition is shown in
the USB 3.0 roothub port status diagram.
When John Covici boots with a USB 3.0 device attached to his 0.96 xHCI
host controller, the port goes into Compliance Mode during host
controller initialization. The USB core sets the warm port reset bit,
but the WPR change bit is not set until much later. The port bounces
between RxDetect, Polling, and Compliance Mode continuously.
First, extend the port reset timeout to see if the host just needs a
longer timeout. The USB 3.0 spec says that the warm port reset should
complete within 200ms, or the link state should transition to the
Disconnected state. Two seconds should be more than enough.
If warm reset fails, try using a different method to get the port out of
Compliance Mode. Set the port into the Disabled state, and then into
the RxDetect state. Set the hub->removed_bits so that the USB core will
ignore the port until it sees a device disconnect and reconnect.
Signed-off-by: Sarah Sharp
---
drivers/usb/core/hub.c | 69 +-
drivers/usb/host/xhci-hub.c | 22 +-
2 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 2dd3586..93c8806 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -876,6 +876,61 @@ static int hub_hub_status(struct usb_hub *hub,
return ret;
}
+static int hub_set_port_link_state(struct usb_hub *hub, int port1,
+ unsigned int link_status)
+{
+ return set_port_feature(hub->hdev,
+ port1 | (link_status << 3),
+ USB_PORT_FEAT_LINK_STATE);
+}
+
+/*
+ * If USB 3.0 ports are placed into the Disabled state, they will no longer
+ * detect any device connects or disconnects. This is generally not what the
+ * USB core wants, since it expects a disabled port to produce a port status
+ * change event when a new device connects.
+ *
+ * Instead, set the link state to Disabled, wait for the link to settle into
+ * that state, and then put the port into the RxDetect state.
+ */
+static int hub_usb3_port_disable(struct usb_hub *hub, int port1)
+{
+ int ret;
+ int total_time;
+ u16 portchange, portstatus;
+
+ if (!hub_is_superspeed(hub->hdev))
+ return -EINVAL;
+
+ ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
+ if (ret) {
+ dev_err(hub->intfdev, "cannot disable port %d (err = %d)\n",
+port1, ret);
+ return ret;
+ }
+
+ /* Wait for the link to enter the disabled state. */
+ for (total_time = 0; ; total_time += HUB_DEBOUNCE_STEP) {
+ ret = hub_port_status(hub, port1, &portstatus, &portchange);
+ if (ret < 0)
+ return ret;
+
+ if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
+USB_SS_PORT_LS_SS_DISABLED)
+ break;
+ if (total_time >= HUB_DEBOUNCE_TIMEOUT)
+ break;
+ msleep(HUB_DEBOUNCE_STEP);
+ }
+ if (total_time >= HUB_DEBOUNCE_TIMEOUT) {
+ dev_warn(hub->intfdev, "Could not disable port %d after %dms\n",
+port1, total_time);
+ return -ETIMEDOUT;
+ }
+
+ return hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_RX_DETECT);
+}
+
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
{
struct usb_device *hdev = hub->hdev;
@@ -2401,7 +2456,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
#define HUB_SHORT_RESET_TIME 10
#define HUB_BH_RESET_TIME 50
#define HUB_LONG_RESET_TIME 200
-#define HUB_RESET_TIMEOUT 500
+#define HUB_RESET_TIMEOUT 2000
static int hub_port_reset(struct usb_hub *hub, int port1,
struct usb_device *udev, unsigned int delay, bool warm);
@@ -4589,11 +4644,21 @@ static void hub_events(void)
* SS.Inactive state.
*/
if (hub_port_warm_reset_required(hub, portstatus)) {
+
Re: [PATCH v4 0/6] solve deadlock caused by memory allocation with I/O
On Sat, 3 Nov 2012 16:35:08 +0800 Ming Lei wrote: > This patchset try to solve one deadlock problem which might be caused > by memory allocation with block I/O during runtime PM and block device > error handling path. Traditionly, the problem is addressed by passing > GFP_NOIO statically to mm, but that is not a effective solution, see > detailed description in patch 1's commit log. It generally looks OK to me. I have a few comments and I expect to grab v5. Rafael, your thoughts? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] mm: teach mm by current context info to not do I/O during memory allocation
On Sat, 3 Nov 2012 16:35:09 +0800
Ming Lei wrote:
> This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
> 'struct task_struct'), so that the flag can be set by one task
> to avoid doing I/O inside memory allocation in the task's context.
>
> The patch trys to solve one deadlock problem caused by block device,
> and the problem may happen at least in the below situations:
>
> - during block device runtime resume, if memory allocation with
> GFP_KERNEL is called inside runtime resume callback of any one
> of its ancestors(or the block device itself), the deadlock may be
> triggered inside the memory allocation since it might not complete
> until the block device becomes active and the involed page I/O finishes.
> The situation is pointed out first by Alan Stern. It is not a good
> approach to convert all GFP_KERNEL[1] in the path into GFP_NOIO because
> several subsystems may be involved(for example, PCI, USB and SCSI may
> be involved for usb mass stoarage device, network devices involved too
> in the iSCSI case)
>
> - during block device runtime suspend, because runtime resume need
> to wait for completion of concurrent runtime suspend.
>
> - during error handling of usb mass storage deivce, USB bus reset
> will be put on the device, so there shouldn't have any
> memory allocation with GFP_KERNEL during USB bus reset, otherwise
> the deadlock similar with above may be triggered. Unfortunately, any
> usb device may include one mass storage interface in theory, so it
> requires all usb interface drivers to handle the situation. In fact,
> most usb drivers don't know how to handle bus reset on the device
> and don't provide .pre_set() and .post_reset() callback at all, so
> USB core has to unbind and bind driver for these devices. So it
> is still not practical to resort to GFP_NOIO for solving the problem.
>
> Also the introduced solution can be used by block subsystem or block
> drivers too, for example, set the PF_MEMALLOC_NOIO flag before doing
> actual I/O transfer.
>
> It is not a good idea to convert all these GFP_KERNEL in the
> affected path into GFP_NOIO because these functions doing that may be
> implemented as library and will be called in many other contexts.
>
> In fact, memalloc_noio() can convert some of current static GFP_NOIO
> allocation into GFP_KERNEL back in other non-affected contexts, at least
> almost all GFP_NOIO in USB subsystem can be converted into GFP_KERNEL
> after applying the approach and make allocation with GFP_IO
> only happen in runtime resume/bus reset/block I/O transfer contexts
> generally.
It's unclear from the description why we're also clearing __GFP_FS in
this situation.
If we can avoid doing this then there will be a very small gain: there
are some situations in which a filesystem can clean pagecache without
performing I/O.
It doesn't appear that the patch will add overhead to the alloc/free
hotpaths, which is good.
>
> ...
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1805,6 +1805,7 @@ extern void thread_group_times(struct task_struct *p,
> cputime_t *ut, cputime_t *
> #define PF_FROZEN0x0001 /* frozen for system suspend */
> #define PF_FSTRANS 0x0002 /* inside a filesystem transaction */
> #define PF_KSWAPD0x0004 /* I am kswapd */
> +#define PF_MEMALLOC_NOIO 0x0008 /* Allocating memory without IO
> involved */
> #define PF_LESS_THROTTLE 0x0010 /* Throttle me less: I clean memory */
> #define PF_KTHREAD 0x0020 /* I am a kernel thread */
> #define PF_RANDOMIZE 0x0040 /* randomize virtual address space */
> @@ -1842,6 +1843,15 @@ extern void thread_group_times(struct task_struct *p,
> cputime_t *ut, cputime_t *
> #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
> #define used_math() tsk_used_math(current)
>
> +#define memalloc_noio() (current->flags & PF_MEMALLOC_NOIO)
> +#define memalloc_noio_save(flag) do { \
> + (flag) = current->flags & PF_MEMALLOC_NOIO; \
> + current->flags |= PF_MEMALLOC_NOIO; \
> +} while (0)
> +#define memalloc_noio_restore(flag) do { \
> + current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flag; \
> +} while (0)
> +
Again with the ghastly macros. Please, do this properly in regular old
C, as previously discussed. It really doesn't matter what daft things
local_irq_save() did 20 years ago. Just do it right!
Also, you can probably put the unlikely() inside memalloc_noio() and
avoid repeating it at all the callsites.
And it might be neater to do:
/*
* Nice comment goes here
*/
static inline gfp_t memalloc_noio_flags(gfp_t flags)
{
if (unlikely(current->flags & PF_MEMALLOC_NOIO))
flags &= ~GFP_IOFS;
return flags;
}
> * task->jobctl flags
> */
>
> ...
>
> @@ -2304,6 +2304,12 @@ unsigned long try_to_free_pages(struct zonelist
> *zonelist, int order,
> .gfp_mask = sc.gfp_mask,
> };
>
> + if (unlikely(memalloc_noio())) {
Re: [PATCH v4 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
On Sat, 3 Nov 2012 16:35:10 +0800
Ming Lei wrote:
> The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
> to help PM core to teach mm not allocating memory with GFP_KERNEL
> flag for avoiding probable deadlock.
>
> As explained in the comment, any GFP_KERNEL allocation inside
> runtime_resume() or runtime_suspend() on any one of device in
> the path from one block or network device to the root device
> in the device tree may cause deadlock, the introduced
> pm_runtime_set_memalloc_noio() sets or clears the flag on
> device in the path recursively.
>
checkpatch finds a number of problems with this patch, all of which
should be fixed. Please always use checkpatch.
> index 3148b10..d477924 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -124,6 +124,63 @@ unsigned long pm_runtime_autosuspend_expiration(struct
> device *dev)
> }
> EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);
>
> +static int dev_memalloc_noio(struct device *dev, void *data)
> +{
> + return dev->power.memalloc_noio;
> +}
> +
> +/*
> + * pm_runtime_set_memalloc_noio - Set a device's memalloc_noio flag.
> + * @dev: Device to handle.
> + * @enable: True for setting the flag and False for clearing the flag.
> + *
> + * Set the flag for all devices in the path from the device to the
> + * root device in the device tree if @enable is true, otherwise clear
> + * the flag for devices in the path whose siblings don't set the flag.
> + *
> + * The function should only be called by block device, or network
> + * device driver for solving the deadlock problem during runtime
> + * resume/suspend:
> + * if memory allocation with GFP_KERNEL is called inside runtime
> + * resume/suspend callback of any one of its ancestors(or the
> + * block device itself), the deadlock may be triggered inside the
> + * memory allocation since it might not complete until the block
> + * device becomes active and the involed page I/O finishes. The
> + * situation is pointed out first by Alan Stern. Network device
> + * are involved in iSCSI kind of situation.
> + *
> + * The lock of dev_hotplug_mutex is held in the function for handling
> + * hotplug race because pm_runtime_set_memalloc_noio() may be called
> + * in async probe().
> + *
> + * The function should be called between device_add() and device_del()
> + * on the affected device(block/network device).
> + */
> +void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
> +{
> + static DEFINE_MUTEX(dev_hotplug_mutex);
> +
> + mutex_lock(&dev_hotplug_mutex);
> + for(;;) {
> + /* hold power lock since bitfield is not SMP-safe. */
> + spin_lock_irq(&dev->power.lock);
> + dev->power.memalloc_noio = enable;
> + spin_unlock_irq(&dev->power.lock);
> +
> + dev = dev->parent;
> +
> + /* only clear the flag for one device if all
> + * children of the device don't set the flag.
> + */
Such a comment is usually laid out as
/*
* Only ...
More significantly, the comment describes what the code is doing but
not why the code is doing it. The former is (usually) obvious from
reading the C, and the latter is what good code comments address.
And it's needed in this case. Why does the code do this?
Also, can a device have more than one child? If so, the code doesn't
do what the comment says it does.
> + if (!dev || (!enable &&
> + device_for_each_child(dev, NULL,
> +dev_memalloc_noio)))
> + break;
> + }
> + mutex_unlock(&dev_hotplug_mutex);
> +}
> +EXPORT_SYMBOL_GPL(pm_runtime_set_memalloc_noio);
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] block/genhd.c: apply pm_runtime_set_memalloc_noio on block devices
On Sat, 3 Nov 2012 16:35:11 +0800 Ming Lei wrote: > This patch applyes the introduced pm_runtime_set_memalloc_noio on > block device so that PM core will teach mm to not allocate memory with > GFP_IOFS when calling the runtime_resume and runtime_suspend callback > for block devices and its ancestors. > > ... > > @@ -532,6 +533,13 @@ static void register_disk(struct gendisk *disk) > return; > } > } > + > + /* avoid probable deadlock caused by allocating memory with Again, please fix the comment style. Take a look at the rest of this file! > + * GFP_KERNEL in runtime_resume callback of its all ancestor > + * deivces typo > + */ -- 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: autodetect USB MTP device characteristics without libusb_open()
Linus Walleij writes:
> On Mon, Nov 5, 2012 at 11:31 PM, Bjørn Mork wrote:
>> Linus Walleij writes:
>
>> Excuse my lack of knowlegde here, but I have to ask why that is?
>>
>> I looked briefly at the MTP v1.1 spec from
>
> So all MTP devices manufactured before that spec, and numerous produced
> after that spec came out, and several still being produced don't use the
> class code, i.e. they violate the spec. But we still have to detect them
> somehow.
Yes, I feared so. But it still seemed likely that the non conforming
ones could be managed as a whitelist, if only most of the new ones were
using the standard class codes.
> Here are some device logs I've been collecting:
> http://libmtp.git.sourceforge.net/git/gitweb.cgi?p=libmtp/libmtp;a=tree;f=logs;hb=HEAD
Thanks. That looks somewhat useful, except that you only seem to
collect the device codes and not the interface codes. I am wondering if
that is much of the problem here? You seem to only look at the device
when in fact most of the new MTP devices are composite devices (phones)?
> This is the lsusb -v:
>
> Bus 003 Device 004: ID 041e:4130 Creative Technology, Ltd Zen Micro (mtp)
> Device Descriptor:
> bLength18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 255 Vendor Specific Class
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize064
> idVendor 0x041e Creative Technology, Ltd
> idProduct 0x4130 Zen Micro (mtp)
> bcdDevice1.00
> iManufacturer 1 Creative Technology Ltd
> iProduct2 Creative Zen Micro
> iSerial 3 01052551C6038F82
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 39
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 16 Configuration 1
> bmAttributes 0xc0
> Self Powered
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 0 (Defined at Interface level)
> bInterfaceSubClass 0
> bInterfaceProtocol 0
> iInterface 33 MTP Interface
Ouch. Yes, not much else to do there than using vid:pid or probing.
> The story goes that Microsoft was not allowed to use the scheme
> in the specification before publication, so they stuck a custom
> scheme in there and fallback methods to figure out if a
> device is MTP.
>
> And since device manufacturers only test their devices against
> Windows, and since the Windows MTP stack is *very* tolerant
> all kinds of weird stuff exist out there. And we get to deal with
> it...
Do you know if these early devices support the typical Microsoft
descriptors? I.e. the 0xee string descriptor with "MSFT100"
and its friends?
I assume even the most buggy devices will survive asking for a string
descriptor...
> So for not-so-bad behaved devices this question is relevant:
>
>> I realize that you still have to probe to find out whether it supports
>> MTP or just PTP, but won't it help if this probing could be limited to
>> only 06/01/01 interfaces?
>
> So in the current device rule we have to match:
>
> ATTR{bDeviceClass}=="00|02|06|ef|ff"
>
> 00 = unspecified, check interfaces, which cannot currently be done by udev
> rules, I think, so we need to perform libusb_open() which will
> screw up some devices...
Sure you can and should check the interface class. Do a
grep bInterfaceClass /lib/udev/rules.d/*
and you will hopefully see a couple of examples.
And I still wonder about the libusb_open screwing up devices. It does
not touch the device at all. And you can get the configuration
descriptor without communicating with the device. The OS has already
cached that for you. So how come you think libusb_open screws up
anything? If it did, then the device would already be dead when the
Linux USB core enumerated it.
> 02 = comms device class, a lot of phones use this
> 06 = yay! PTP yes among others...
> ef = no idea why this is used, but it is
I assume that is in combination with subclass 02 and protocol 01, which
specifies "Interface Association Descriptor" and will be common for
phones and modems. See
http://www.usb.org/developers/whitepapers/iadclasscode_r10.pdf
It's just another "unspecified, check interfaces" really.
> ff = as per above
Those are always going to be a problem. But I was hoping they were only
older devices. The rest of your list of device classes should have
meaningful interface class/subclass/protocol codes. Don't they?
But no, you cannot do device class matching. That will naturally not
work on any composite device, as they by definiton support more than one
set of codes.
> Wh
Re: [PATCH 1/2] USB: PHY: Add support for USB 3.0 phy for exynos5250
Hi,
I have a few comments. Please see below...
On 11/06/2012 04:36 PM, Vivek Gautam wrote:
Adding support for USB3.0 phy for dwc3 controller on
exynso5250 SOC.
exynso -> exynos
Signed-off-by: Vivek Gautam
---
drivers/usb/phy/samsung-usbphy.c| 337 +++
include/linux/usb/samsung_usb_phy.h |1 +
2 files changed, 338 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 3b4863d..e3b5fb1 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -167,6 +167,99 @@
#define EXYNOS5_PHY_OTG_TUNE (0x40)
+/* USB 3.0: DRD */
+#define EXYNOS5_DRD_LINKSYSTEM (0x04)
+
+#define LINKSYSTEM_FLADJ_MASK (0x3f<< 1)
+#define LINKSYSTEM_FLADJ(_x) ((_x)<< 1)
+#define LINKSYSTEM_XHCI_VERSION_CONTROL(1<< 27)
+
+#define EXYNOS5_DRD_PHYUTMI(0x08)
+
+#define PHYUTMI_OTGDISABLE (1<< 6)
+#define PHYUTMI_FORCESUSPEND (1<< 1)
+#define PHYUTMI_FORCESLEEP (1<< 0)
+
+#define EXYNOS5_DRD_PHYPIPE(0x0C)
Would be nice to put all hex numbers in lower case.
+
+#define EXYNOS5_DRD_PHYCLKRST (0x10)
+
+#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff<< 23)
+#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x)<< 23)
+
+#define PHYCLKRST_SSC_RANGE_MASK (0x03<< 21)
+#define PHYCLKRST_SSC_RANGE(_x)((_x)<< 21)
+
+#define PHYCLKRST_SSC_EN (1<< 20)
+#define PHYCLKRST_REF_SSP_EN (1<< 19)
+#define PHYCLKRST_REF_CLKDIV2 (1<< 18)
+
+#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f<< 11)
+#define PHYCLKRST_MPLL_MULTIPLIER(_x) ((_x)<< 11)
Is this macro-definition going to be used anywhere else except the
5 definitions below ? Is this really helpful ? In anything else than
forcing you to use questionable line breaking below ?
+#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF \
How about simply defining it as
#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF(0x19 << 11)
?
+ PHYCLKRST_MPLL_MULTIPLIER(0x19)
+#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF \
+ PHYCLKRST_MPLL_MULTIPLIER(0x02)
+#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF\
+ PHYCLKRST_MPLL_MULTIPLIER(0x68)
+#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF\
+ PHYCLKRST_MPLL_MULTIPLIER(0x7d)
+#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF \
+ PHYCLKRST_MPLL_MULTIPLIER(0x02)
+
+#define PHYCLKRST_FSEL_MASK(0x3f<< 5)
+#define PHYCLKRST_FSEL(_x) ((_x)<< 5)
Ditto.
+#define PHYCLKRST_FSEL_PAD_100MHZ \
+ PHYCLKRST_FSEL(0x27)
+#define PHYCLKRST_FSEL_PAD_24MHZ \
+ PHYCLKRST_FSEL(0x2a)
+#define PHYCLKRST_FSEL_PAD_20MHZ \
+ PHYCLKRST_FSEL(0x31)
+#define PHYCLKRST_FSEL_PAD_19_2MHZ \
+ PHYCLKRST_FSEL(0x38)
+
+#define PHYCLKRST_RETENABLEN (1<< 4)
+
+#define PHYCLKRST_REFCLKSEL_MASK (0x03<< 2)
+#define PHYCLKRST_REFCLKSEL(_x)((_x)<< 2)
Ditto.
+#define PHYCLKRST_REFCLKSEL_PAD_REFCLK \
+ PHYCLKRST_REFCLKSEL(2)
+#define PHYCLKRST_REFCLKSEL_EXT_REFCLK \
+ PHYCLKRST_REFCLKSEL(3)
+
+#define PHYCLKRST_PORTRESET(1<< 1)
+#define PHYCLKRST_COMMONONN(1<< 0)
+
+#define EXYNOS5_DRD_PHYREG0(0x14)
+#define EXYNOS5_DRD_PHYREG1(0x18)
+
+#define EXYNOS5_DRD_PHYPARAM0 (0x1C)
+
+#define PHYPARAM0_REF_USE_PAD (0x1<< 31)
+#define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f<< 26)
+#define PHYPARAM0_REF_LOSLEVEL (0x9<< 26)
+
+#define EXYNOS5_DRD_PHYPARAM1 (0x20)
+
+#define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f<< 0)
+#define PHYPARAM1_PCS_TXDEEMPH (0x1C)
+
+#define EXYNOS5_DRD_PHYTERM(0x24)
+
+#define EXYNOS5_DRD_PHYTEST(0x28)
+
+#define PHYTEST_POWERDOWN_SSP (1<< 3)
+#define PHYTEST_POWERDOWN_HSP (1<< 2)
+
+#define EXYNOS5_DRD_PHYADP (0x2C)
+
+#define EXYNOS5_DRD_PHYBATCHG (0x30)
+
+#define PHYBATCHG_UTMI_CLKSEL (0x1<< 2)
+
+#define EXYNOS5_DRD_PHYRESUME (0x34)
+#define EXYNOS5_DRD_LINKPORT (0x44)
+
#ifndef MHZ
#define MHZ (1000*1000)
#endif
@@ -180,10 +273,12 @@ enum samsung_cpu_type {
/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
+ * @phy3: transceiver structure for USB 3.0
* @plat: platform data
* @dev: The parent device supplied to th
How-to start reverse engineering serial communication
Hello, I've a bike computer SIGMA ROX 9.1 which can be connected via a small USB docking station to retrieve the collected data. However there is a proprietary software called "Data Center" (DaCe) which is not available for Linux and doesn't run with Wine. At least it doesn't find the connected device via com port in Wine. I'd like to write my own software for Linux to collect the training data. In Windows the Data Center (DaCe) software uses a virtual serial port driver with "com3". Now my problem is that I've no idea about the communication with the device. I've tried to use some serial port sniffer. But this didn't work. If the software sniffs the DaCe doesn't find the device. If the DaCe has connected to the device, the sniffers denies to sniff on the serial port. I've tried multiple sniffers without success. Of course it is possible to sniff on USB with usbmon and wireshark. But I've no idea how to go on with the collected jumble of data. The Data Center is an Adobe AIR application. In Windows the usbser.sys is used and Linux detects it as USB ACM device: [12302.367098] usb 6-1: new full-speed USB device number 3 using uhci_hcd [12302.600240] usb 6-1: New USB device found, idVendor=1d9d, idProduct=1030 [12302.600251] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [12302.600259] usb 6-1: Product: SIGMA DS ROX 11 [12302.600265] usb 6-1: Manufacturer: STMicroelectronics [12302.602292] usbserial_generic 6-1:1.0: Generic device with no bulk out, not allowed. [12302.602310] usbserial_generic: probe of 6-1:1.0 failed with error -5 [12302.602330] cdc_acm 6-1:1.0: This device cannot do calls on its own. It is not a modem. [12302.602373] cdc_acm 6-1:1.0: ttyACM0: USB ACM device I've the 2 books USB Complete - http://www.amazon.de/gp/product/1931448086 Serial Port Complete - http://www.amazon.de/gp/product/193144806X where I can get more knowledge from ;-) E.g. if I retrieve battery status of 4 units I currently get this data 05:33:64:50:64:41:50:01:00:02:10:40:17:70:04:01:01:06:32:32:32:1e:1e:50:55:55:55:5f:c0:33:21:33:21:96:12:89:53:20:90:49:17:96:09:00:37:15:56:21:10:12:21:42:75:00:28:36:07:00:21:04:79:19:50:06:be:69:86:98:be:00:01:00:02:00:03:95:24:82:17:74:20:23:10:65:37:00:15:17:23:20:32:38:00:30:16:27:00:07:29:05:00:01:15:13:00:02:10:01:00:11:47:21:79:04:40:75:93:67:04:00:55:62:75:01:05:70:37:95:29:03:00:39:03:02:27:13:00:40:20:0c:88:15:af:52:0a:04:02:62:61:5b:ac:a4:6c:03:11:1f:30:29:33:31:43:0f:04:43:be:20:d4:74:94:35 and the DaCe says the batteries of the 4 units (bike computer, chest belt, speed transmitter and cadence transmitter) are fine. But I don't see how to interpret the data. So do you have any idea how to go on? Thanks Markus -- 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: 3TB Hard Drive in USB Enclosure Resetting
I was comparing the two USB captures and I noticed the Windows capture uses a READ(16) and Linux is using a READ(10). I'm not sure how the kernel determines which read command to use, but I'm wondering if this could be the problem here? I was way wrong about the first read being in the 700's btw :) Window's first READ(16) is at frame 291. Linux first READ(1) is at 161. Hope this is useful. I'll keep digging. -- - Jason J. Herne (hern...@gmail.com) -- 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/3 v2] usb: renesas_usbhs: use transfer counter if IN direction bulk pipe
received data will break if it was bulk pipe and large data size,
because pipe kept BUF PID even though it doesn't have enough buffer.
To avoid this issue, renesas_usbhs can use transfer counter.
Pipe PID will be NAK if it didn't have enough buffer by this patch.
renesas_usbhs has strange address mapping.
Thus, it is difficult to calculate transfer counter setting address.
This patch use fixed table for it.
Signed-off-by: Kuninori Morimoto
---
>> Felipe
This patch is based on felipe/gadget branch.
But you will get conflict when you merged with felipe/master branch.
1cb60156defa4f23d5318ea1ddd400f25b2d0ce5
(usb: renesas_usbhs: fixup dma transfer stall)
Then, please fix it as
-> usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->trans);
-> usbhs_pipe_enable(pipe);
usbhsf_dma_start(pipe, fifo);
dma_async_issue_pending(chan);
drivers/usb/renesas_usbhs/fifo.c |4 ++
drivers/usb/renesas_usbhs/pipe.c | 101 ++
drivers/usb/renesas_usbhs/pipe.h |1 +
3 files changed, 106 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 77f1adc..72ad375 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -488,6 +488,8 @@ static int usbhsf_pio_try_push(struct usbhs_pkt *pkt, int
*is_done)
usbhs_pipe_data_sequence(pipe, pkt->sequence);
pkt->sequence = -1; /* -1 sequence will be ignored */
+ usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->length);
+
ret = usbhsf_fifo_select(pipe, fifo, 1);
if (ret < 0)
return 0;
@@ -594,6 +596,7 @@ static int usbhsf_prepare_pop(struct usbhs_pkt *pkt, int
*is_done)
usbhs_pipe_data_sequence(pipe, pkt->sequence);
pkt->sequence = -1; /* -1 sequence will be ignored */
+ usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->length);
usbhs_pipe_enable(pipe);
usbhsf_rx_irq_ctrl(pipe, 1);
@@ -795,6 +798,7 @@ static void xfer_work(struct work_struct *work)
dev_dbg(dev, " %s %d (%d/ %d)\n",
fifo->name, usbhs_pipe_number(pipe), pkt->length, pkt->zero);
+ usbhs_pipe_set_trans_count_if_bulk(pipe, pkt->trans);
usbhsf_dma_start(pipe, fifo);
dma_async_issue_pending(chan);
}
diff --git a/drivers/usb/renesas_usbhs/pipe.c b/drivers/usb/renesas_usbhs/pipe.c
index 122526c..7926e1c 100644
--- a/drivers/usb/renesas_usbhs/pipe.c
+++ b/drivers/usb/renesas_usbhs/pipe.c
@@ -93,6 +93,82 @@ static void usbhsp_pipe_cfg_set(struct usbhs_pipe *pipe, u16
mask, u16 val)
}
/*
+ * PIPEnTRN/PIPEnTRE functions
+ */
+static void usbhsp_pipe_trn_set(struct usbhs_pipe *pipe, u16 mask, u16 val)
+{
+ struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
+ struct device *dev = usbhs_priv_to_dev(priv);
+ int num = usbhs_pipe_number(pipe);
+ u16 reg;
+
+ /*
+* It is impossible to calculate address,
+* since PIPEnTRN addresses were mapped randomly.
+*/
+#define CASE_PIPExTRN(a) \
+ case 0x ## a: \
+ reg = PIPE ## a ## TRN; \
+ break;
+
+ switch (num) {
+ CASE_PIPExTRN(1);
+ CASE_PIPExTRN(2);
+ CASE_PIPExTRN(3);
+ CASE_PIPExTRN(4);
+ CASE_PIPExTRN(5);
+ CASE_PIPExTRN(B);
+ CASE_PIPExTRN(C);
+ CASE_PIPExTRN(D);
+ CASE_PIPExTRN(E);
+ CASE_PIPExTRN(F);
+ CASE_PIPExTRN(9);
+ CASE_PIPExTRN(A);
+ default:
+ dev_err(dev, "unknown pipe (%d)\n", num);
+ return;
+ }
+ __usbhsp_pipe_xxx_set(pipe, 0, reg, mask, val);
+}
+
+static void usbhsp_pipe_tre_set(struct usbhs_pipe *pipe, u16 mask, u16 val)
+{
+ struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
+ struct device *dev = usbhs_priv_to_dev(priv);
+ int num = usbhs_pipe_number(pipe);
+ u16 reg;
+
+ /*
+* It is impossible to calculate address,
+* since PIPEnTRE addresses were mapped randomly.
+*/
+#define CASE_PIPExTRE(a) \
+ case 0x ## a: \
+ reg = PIPE ## a ## TRE; \
+ break;
+
+ switch (num) {
+ CASE_PIPExTRE(1);
+ CASE_PIPExTRE(2);
+ CASE_PIPExTRE(3);
+ CASE_PIPExTRE(4);
+ CASE_PIPExTRE(5);
+ CASE_PIPExTRE(B);
+ CASE_PIPExTRE(C);
+ CASE_PIPExTRE(D);
+ CASE_PIPExTRE(E);
+ CASE_PIPExTRE(F);
+ CASE_PIPExTRE(9);
+ CASE_PIPExTRE(A);
+ default:
+ dev_err(dev, "unknown pipe (%d)\n", num);
+ return;
+ }
+
+ __usbhsp_pipe_xxx_set(pipe, 0, reg, mask, val);
+}
+
+/*
* PIPEBUF
*/
static void usbhsp_pipe_buf_set(struct usbhs_pipe *pipe, u16 mask, u16 val)
@@ -264,6 +340,31 @@ int usbhs_pipe_is_stall(struct usbhs_pipe *pipe)
return (int)(pid == PID_STALL10 || pid == PID_STALL11);
Re: How-to start reverse engineering serial communication
Markus Kolb writes: > I've a bike computer SIGMA ROX 9.1 which can be connected via a small > USB docking station to retrieve the collected data. [snip] > But I don't see how to interpret the data. > > So do you have any idea how to go on? Not really, but googling the device brought me this: http://www.freakysoft.de/rox_sigma/ Looks like someone beat you to it :-) Bjørn -- 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: problem with Roseweil eusb3 enclosure
Thanks much -- should I leave the previous patch in? Sarah Sharp wrote: > On Sat, Nov 03, 2012 at 02:51:36AM -0400, cov...@ccs.covici.com wrote: > > OK, increasing the buffer size gives me the full syslog, which is > > enclosed. I am not sending the dmesg because I think we have it all > > now. > > Thanks, that helped. Your port is coming up in compliance mode shortly > after it's powered on, which is kind of odd. The host controller seems > to need a longer-than-normal warm reset timeout in this case. I'm not > sure if the longer timeout will actually help, so I've also added code > to try a different method of bringing the port out of Compliance Mode > (disabling the port and re-enabling it). > > Can you try the attached patch? I've only compile-tested it, so I'm not > sure if it will work. > > Please send me dmesg from the start of the log with the patch applied, > even if it does work. I'd like to figure out which of the two solutions > helped. > > Sarah Sharp -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com -- 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: [PATCHv3 1/6] arch: Change defconfigs to point to g_mass_storage.
Around Tue 06 Nov 2012 22:52:35 +0100 or thereabout, Michal Nazarewicz wrote: > From: Michal Nazarewicz > > The File-backed Storage Gadget (g_file_storage) is being removed, since > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit > changes defconfigs point to the new gadget. > > Signed-off-by: Michal Nazarewicz > Acked-by: Nicolas Ferre (fort AT91) > Acked-by: Tony Lindgren (for omap1) > --- > arch/arm/configs/afeb9260_defconfig|2 +- > arch/arm/configs/at91sam9260_defconfig |2 +- > arch/arm/configs/at91sam9261_defconfig |2 +- > arch/arm/configs/at91sam9263_defconfig |2 +- > arch/arm/configs/at91sam9g20_defconfig |2 +- > arch/arm/configs/corgi_defconfig |2 +- > arch/arm/configs/davinci_all_defconfig |2 +- > arch/arm/configs/h7202_defconfig |3 +-- > arch/arm/configs/magician_defconfig|2 +- > arch/arm/configs/mini2440_defconfig|2 +- > arch/arm/configs/omap1_defconfig |3 +-- > arch/arm/configs/prima2_defconfig |1 - > arch/arm/configs/spitz_defconfig |2 +- > arch/arm/configs/stamp9g20_defconfig |2 +- > arch/arm/configs/viper_defconfig |2 +- > arch/arm/configs/zeus_defconfig|2 +- > arch/avr32/configs/atngw100_defconfig |2 +- > arch/avr32/configs/atngw100_evklcd100_defconfig|2 +- > arch/avr32/configs/atngw100_evklcd101_defconfig|2 +- > arch/avr32/configs/atngw100_mrmt_defconfig |2 +- > arch/avr32/configs/atngw100mkii_defconfig |2 +- > .../avr32/configs/atngw100mkii_evklcd100_defconfig |2 +- > .../avr32/configs/atngw100mkii_evklcd101_defconfig |2 +- > arch/avr32/configs/atstk1002_defconfig |2 +- > arch/avr32/configs/atstk1003_defconfig |2 +- > arch/avr32/configs/atstk1004_defconfig |2 +- > arch/avr32/configs/atstk1006_defconfig |2 +- > arch/avr32/configs/favr-32_defconfig |2 +- > arch/avr32/configs/hammerhead_defconfig|2 +- For all the AVR32 related changes +1 (-: Acked-by: Hans-Christian Egtvedt IMHO this patch is trivial and needed since you change all the users of a certain symbol. Thanks for doing the maintenance. -- mvh Hans-Christian Egtvedt -- 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: How-to start reverse engineering serial communication
Bjørn Mork wrote on 07.11.2012 01:17: Markus Kolb writes: I've a bike computer SIGMA ROX 9.1 which can be connected via a small USB docking station to retrieve the collected data. [snip] But I don't see how to interpret the data. So do you have any idea how to go on? Not really, but googling the device brought me this: http://www.freakysoft.de/rox_sigma/ Looks like someone beat you to it :-) Hey, cool... freakysoft sounds like a software search site with dubious results and so I have not read more about this link on my own search. My fault ;-) I think the code is for an older Sigma Rox but sure this is a nice starting point. -- 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: autodetect USB MTP device characteristics without libusb_open()
Hej Linus! Linus Walleij wrote: > - some devices bug out on libusb_open() Please send me a debug log from when this happens. Exact steps are at http://libusb.org/wiki/debug > I have added code like below to libmtp to instead inspect sysfs > *before* starting any libusb-based business. .. > - Is this a good idea? It's a horrible hack and I don't think it's a very good idea. I understand that you have some real broken devices to deal with, but let's just make libusb work for you instead. Also, look into scanf() and friends, they are highly underrated! :) > - What is the scary business that libusb_open() does that makes > a lot of substandard USB devices totally freak out? I can only confirm that opening does not talk to the device. Enumeration can. But really, I need to see the debug log, and usbmon output from when this happens would certainly also be nice. Linus Walleij wrote: > you cannot open a session to an MTP device in say a udev script, > then close it and open another session later Maybe don't do that. Open the session in the udev-driven program, and do not close it. Find a way to tell libmtp that a session is already open, and only OpenSession when one isn't. It isn't pretty, but.. //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 v4 1/6] mm: teach mm by current context info to not do I/O during memory allocation
On Wed, Nov 7, 2012 at 7:23 AM, Andrew Morton wrote:
>
> It's unclear from the description why we're also clearing __GFP_FS in
> this situation.
>
> If we can avoid doing this then there will be a very small gain: there
> are some situations in which a filesystem can clean pagecache without
> performing I/O.
Firstly, the patch follows the policy in the system suspend/resume situation,
in which the __GFP_FS is cleared, and basically the problem is very similar
with that in system PM path.
Secondly, inside shrink_page_list(), pageout() may be triggered on dirty anon
page if __GFP_FS is set.
IMO, if performing I/O can be completely avoided when __GFP_FS is set, the
flag can be kept, otherwise it is better to clear it in the situation.
>
> It doesn't appear that the patch will add overhead to the alloc/free
> hotpaths, which is good.
Thanks for previous Minchan's comment.
>
>>
>> ...
>>
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1805,6 +1805,7 @@ extern void thread_group_times(struct task_struct *p,
>> cputime_t *ut, cputime_t *
>> #define PF_FROZEN0x0001 /* frozen for system suspend */
>> #define PF_FSTRANS 0x0002 /* inside a filesystem transaction */
>> #define PF_KSWAPD0x0004 /* I am kswapd */
>> +#define PF_MEMALLOC_NOIO 0x0008 /* Allocating memory without IO
>> involved */
>> #define PF_LESS_THROTTLE 0x0010 /* Throttle me less: I clean memory */
>> #define PF_KTHREAD 0x0020 /* I am a kernel thread */
>> #define PF_RANDOMIZE 0x0040 /* randomize virtual address space */
>> @@ -1842,6 +1843,15 @@ extern void thread_group_times(struct task_struct *p,
>> cputime_t *ut, cputime_t *
>> #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
>> #define used_math() tsk_used_math(current)
>>
>> +#define memalloc_noio() (current->flags & PF_MEMALLOC_NOIO)
>> +#define memalloc_noio_save(flag) do { \
>> + (flag) = current->flags & PF_MEMALLOC_NOIO; \
>> + current->flags |= PF_MEMALLOC_NOIO; \
>> +} while (0)
>> +#define memalloc_noio_restore(flag) do { \
>> + current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flag; \
>> +} while (0)
>> +
>
> Again with the ghastly macros. Please, do this properly in regular old
> C, as previously discussed. It really doesn't matter what daft things
> local_irq_save() did 20 years ago. Just do it right!
OK, I will take inline function in -v5.
>
> Also, you can probably put the unlikely() inside memalloc_noio() and
> avoid repeating it at all the callsites.
>
> And it might be neater to do:
>
> /*
> * Nice comment goes here
> */
> static inline gfp_t memalloc_noio_flags(gfp_t flags)
> {
> if (unlikely(current->flags & PF_MEMALLOC_NOIO))
> flags &= ~GFP_IOFS;
> return flags;
> }
But without the check in callsites, some local variables will be write
two times,
so it is better to not do it.
>
>> * task->jobctl flags
>> */
>>
>> ...
>>
>> @@ -2304,6 +2304,12 @@ unsigned long try_to_free_pages(struct zonelist
>> *zonelist, int order,
>> .gfp_mask = sc.gfp_mask,
>> };
>>
>> + if (unlikely(memalloc_noio())) {
>> + gfp_mask &= ~GFP_IOFS;
>> + sc.gfp_mask = gfp_mask;
>> + shrink.gfp_mask = sc.gfp_mask;
>> + }
>
> We can avoid writing to shrink.gfp_mask twice. And maybe sc.gfp_mask
> as well. Unclear, I didn't think about it too hard ;)
Yes, we can do it by initializing 'shrink' local variable just after the branch,
so one writing is enough. Will do it in -v5.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
On Wed, Nov 7, 2012 at 7:24 AM, Andrew Morton wrote: > > checkpatch finds a number of problems with this patch, all of which > should be fixed. Please always use checkpatch. Sorry for missing the check. >> + /* only clear the flag for one device if all >> + * children of the device don't set the flag. >> + */ > > Such a comment is usually laid out as > > /* > * Only ... Will do it in -v5. > More significantly, the comment describes what the code is doing but > not why the code is doing it. The former is (usually) obvious from > reading the C, and the latter is what good code comments address. > > And it's needed in this case. Why does the code do this? Suppose both two usb scsi disks which share the same usb configuration(device) set the device memalloc_noio flag, and its ancestors' memalloc_noio flag should be cleared only after both the two usb scsi disk's flags have been cleared. OK, we'll add comment on clearing flag. > > Also, can a device have more than one child? If so, the code doesn't > do what the comment says it does. It should do that because device_for_each_child() returns true immediately only if dev_memalloc_noio() for one child returns true. > >> + if (!dev || (!enable && >> + device_for_each_child(dev, NULL, >> +dev_memalloc_noio))) >> + break; >> + } >> + mutex_unlock(&dev_hotplug_mutex); >> +} >> +EXPORT_SYMBOL_GPL(pm_runtime_set_memalloc_noio); Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/6] solve deadlock caused by memory allocation with I/O
On Wed, Nov 7, 2012 at 7:23 AM, Andrew Morton wrote: > > It generally looks OK to me. I have a few comments and I expect to grab > v5. Andrew, thanks for your review, and I will prepare -v5 later. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] mm: teach mm by current context info to not do I/O during memory allocation
On Wed, 7 Nov 2012 11:11:24 +0800 Ming Lei wrote:
> On Wed, Nov 7, 2012 at 7:23 AM, Andrew Morton
> wrote:
> >
> > It's unclear from the description why we're also clearing __GFP_FS in
> > this situation.
> >
> > If we can avoid doing this then there will be a very small gain: there
> > are some situations in which a filesystem can clean pagecache without
> > performing I/O.
>
> Firstly, the patch follows the policy in the system suspend/resume situation,
> in which the __GFP_FS is cleared, and basically the problem is very similar
> with that in system PM path.
I suspect that code is wrong. Or at least, suboptimal.
> Secondly, inside shrink_page_list(), pageout() may be triggered on dirty anon
> page if __GFP_FS is set.
pageout() should be called if GFP_FS is set or if GFP_IO is set and the
IO is against swap.
And that's what we want to happen: we want to enter the fs to try to
turn dirty pagecache into clean pagecache without doing IO. If we in
fact enter the device drivers when GFP_IO was not set then that's a bug
which we should fix.
> IMO, if performing I/O can be completely avoided when __GFP_FS is set, the
> flag can be kept, otherwise it is better to clear it in the situation.
yup.
> >
> > Also, you can probably put the unlikely() inside memalloc_noio() and
> > avoid repeating it at all the callsites.
> >
> > And it might be neater to do:
> >
> > /*
> > * Nice comment goes here
> > */
> > static inline gfp_t memalloc_noio_flags(gfp_t flags)
> > {
> > if (unlikely(current->flags & PF_MEMALLOC_NOIO))
> > flags &= ~GFP_IOFS;
> > return flags;
> > }
>
> But without the check in callsites, some local variables will be write
> two times,
> so it is better to not do it.
I don't see why - we just modify the incoming gfp_t at the start of the
function, then use it.
It gets a bit tricky with those struct initialisations. Things like
struct foo bar {
.a = a1,
.b = b1,
};
should not be turned into
struct foo bar {
.a = a1,
};
bar.b = b1;
and we don't want to do
struct foo bar { };
bar.a = a1;
bar.b = b1;
either, because these are indeed a double-write. But we can do
struct foo bar {
.flags = (flags = memalloc_noio_flags(flags)),
.b = b1,
};
which is a bit arcane but not t bad. Have a think about it...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] mm: teach mm by current context info to not do I/O during memory allocation
On Wed, Nov 7, 2012 at 11:48 AM, Andrew Morton
wrote:
>>
>> Firstly, the patch follows the policy in the system suspend/resume
>> situation,
>> in which the __GFP_FS is cleared, and basically the problem is very similar
>> with that in system PM path.
>
> I suspect that code is wrong. Or at least, suboptimal.
>
>> Secondly, inside shrink_page_list(), pageout() may be triggered on dirty anon
>> page if __GFP_FS is set.
>
> pageout() should be called if GFP_FS is set or if GFP_IO is set and the
> IO is against swap.
>
> And that's what we want to happen: we want to enter the fs to try to
> turn dirty pagecache into clean pagecache without doing IO. If we in
> fact enter the device drivers when GFP_IO was not set then that's a bug
> which we should fix.
OK, I got it, and I'll not clear GFP_FS in -v5.
>
>> IMO, if performing I/O can be completely avoided when __GFP_FS is set, the
>> flag can be kept, otherwise it is better to clear it in the situation.
>
> yup.
>
>> >
>> > Also, you can probably put the unlikely() inside memalloc_noio() and
>> > avoid repeating it at all the callsites.
>> >
>> > And it might be neater to do:
>> >
>> > /*
>> > * Nice comment goes here
>> > */
>> > static inline gfp_t memalloc_noio_flags(gfp_t flags)
>> > {
>> > if (unlikely(current->flags & PF_MEMALLOC_NOIO))
>> > flags &= ~GFP_IOFS;
>> > return flags;
>> > }
>>
>> But without the check in callsites, some local variables will be write
>> two times,
>> so it is better to not do it.
>
> I don't see why - we just modify the incoming gfp_t at the start of the
> function, then use it.
>
> It gets a bit tricky with those struct initialisations. Things like
>
> struct foo bar {
> .a = a1,
> .b = b1,
> };
>
> should not be turned into
>
> struct foo bar {
> .a = a1,
> };
>
> bar.b = b1;
>
> and we don't want to do
>
> struct foo bar { };
>
> bar.a = a1;
> bar.b = b1;
>
> either, because these are indeed a double-write. But we can do
>
> struct foo bar {
> .flags = (flags = memalloc_noio_flags(flags)),
> .b = b1,
> };
>
> which is a bit arcane but not t bad. Have a think about it...
Got it, looks memalloc_noio_flags() neater, and I will take it in v5.
Thanks,
--
Ming Lei
--
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: generic wireless mouse not working
On Tue, Nov 06, 2012 at 08:23:43PM -0200, Marco Biscaro wrote: > Is that sufficient? > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021019/comments/42 Not in the slightest. Especially as there is no such thing as "public domain". Please read Documentation/SubmittingPatches for what is needed here. 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
