Re: HP EC372S (Yuan DVB ExpressCard) crash in 3.18.3
On Mon, 2 Feb 2015, Jonas Jonsson wrote: Hi, I posted a bug on kernel.org (https://bugzilla.kernel.org/show_bug.cgi?id=92301 ) and was asked to sent it to this mail-address. Since this bug involves the dvb-usb driver, it should also be posted to the linux-media mailing list (CC-ed). Alan Stern Jan 29 21:26:51 plattpcn kernel: [ 17.322493] input: UVC Camera (05ca:1812) as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input10 Jan 29 21:26:51 plattpcn kernel: [ 17.322621] usbcore: registered new interface driver uvcvideo Jan 29 21:26:51 plattpcn kernel: [ 17.322623] USB Video Class driver (1.1.1) Jan 29 21:26:51 plattpcn kernel: [ 17.583002] input: HP WMI hotkeys as /devices/virtual/input/input11 Jan 29 21:26:51 plattpcn kernel: [ 18.108106] iwl4965 :02:00.0: loaded firmware version 228.61.2.24 Jan 29 21:26:51 plattpcn kernel: [ 18.360154] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs' Jan 29 21:26:51 plattpcn kernel: [ 18.620404] dvb-usb: found a 'Yuan EC372S' in cold state, will try to load a firmware Jan 29 21:26:51 plattpcn kernel: [ 18.993039] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Jan 29 21:26:51 plattpcn kernel: [ 19.194634] dib0700: firmware started successfully. Jan 29 21:26:51 plattpcn kernel: [ 19.695174] dvb-usb: found a 'Yuan EC372S' in warm state. Jan 29 21:26:51 plattpcn kernel: [ 19.695448] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jan 29 21:26:51 plattpcn kernel: [ 19.695527] DVB: registering new adapter (Yuan EC372S) Jan 29 21:26:51 plattpcn kernel: [ 20.090809] BUG: unable to handle kernel NULL pointer dereference at 0080 Jan 29 21:26:51 plattpcn kernel: [ 20.090987] IP: [a057b061] dib7000p_attach+0x11/0xa0 [dib7000p] Jan 29 21:26:51 plattpcn kernel: [ 20.091007] PGD 36893067 PUD b95b0067 PMD 0 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Oops: 0002 [#1] SMP Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Modules linked in: dib7000p(E) dvb_usb_dib0700(E+) dib7000m(E) arc4(E) dib0090(E) dib0070(E) dib3000mc(E) dibx000_common(E) dvb_usb(E) dvb_core(E) coretemp(E) hp_wmi(E) rc_core(E) sparse_keymap(E) uvcvideo(E) iwl4965(E) videobuf2_vmalloc(E) snd_hda_codec_si3054(E) kvm(E) iwlegacy(E) snd_hda_codec_realtek(E) videobuf2_memops(E) mac80211(E) videobuf2_core(E) snd_hda_codec_generic(E) v4l2_common(E) videodev(E) snd_hda_intel(E) joydev(E) snd_hda_controller(E) serio_raw(E) snd_hda_codec(E) snd_hwdep(E) r852(E) cfg80211(E) snd_pcm(E) sm_common(E) btusb(E) nand(E) snd_seq_midi(E) nand_ecc(E) snd_seq_midi_event(E) bluetooth(E) snd_rawmidi(E) nand_bch(E) snd_seq(E) bch(E) r592(E) snd_seq_device(E) nand_ids(E) snd_timer(E) mtd(E) memstick(E) drm(E) snd(E) soundcore(E) lpc_ich(E) wmi(E) video(E) mac_hid(E) parport_pc(E) ppdev(E) lp(E) parport(E) psmouse(E) ahci(E) libahci(E) firewire_ohci(E) firewire_core(E) sdhci_pci(E) crc_itu_t(E) sdhci(E) r8169(E) mii(E) Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CPU: 0 PID: 442 Comm: systemd-udevd Tainted: GE 3.18.3jonas #1 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Hardware name: Hewlett-Packard HP Pavilion dv9700 Notebook PC/30CB, BIOS F.59 11/25/2008 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] task: 8800b8f68000 ti: 8800b9148000 task.ti: 8800b9148000 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RIP: 0010:[a057b061] [a057b061] dib7000p_attach+0x11/0xa0 [dib7000p] Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RSP: 0018:8800b914ba88 EFLAGS: 00010202 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RAX: 0010 RBX: 8800ba9d1278 RCX: a0581040 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RDX: a0581040 RSI: a0581c2b RDI: 0010 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RBP: 8800b914ba88 R08: 810e47a0 R09: 0001802a0029 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] R10: ea0002ed9fc0 R11: 8107cf84 R12: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] R13: 0010 R14: 8800ba9d1278 R15: 8800ba9d1398 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] FS: 7fd441492880() GS:88013fc0() knlGS: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CS: 0010 DS: ES: CR0: 8005003b Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CR2: 0080 CR3: 36892000 CR4: 07f0 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Stack: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800b914bab8 a055adab 8800ba9d1278 8800ba9d1278 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800ba9d1278 8800b914baf8 a04776b8 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800ba9d
Re: [PATCH v2] usb: gadget: OS desc type unicode multi
Hi Andrzej,
thank you for the comment.
2015-02-02 11:33 GMT+01:00 Andrzej Pietrasiewicz andrze...@samsung.com:
Hi Mario,
W dniu 01.02.2015 o 21:07, Mario Schuknecht pisze:
A popular proprietary operating system expects that USB devices provide
extra
information via OS descriptors. An introduction to the subject can be
found
here:
snip
This patch adds support for property data type 0x7 multiple NUL-terminated
unicode strings.
This suggests that you mean
#define USB_EXT_PROP_UNICODE_MULTI 7
Add case USB_EXT_PROP_UNICODE_MULTI in function fill_ext_prop()
And you do.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
Changes in v2:
- improve commit log
drivers/usb/gadget/composite.c | 5 +
drivers/usb/gadget/u_os_desc.h | 28
2 files changed, 33 insertions(+)
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c
index 6178353..bf30b73 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1422,6 +1422,11 @@ static int fill_ext_prop(struct usb_configuration
*c, int interface, u8 *buf)
ext_prop-data,
ext_prop-data_len);
break;
+ case USB_EXT_PROP_UNICODE_LINK_MULTI:
Does it compile? I mean the _LINK_ infix - didn't you mean
+ case USB_EXT_PROP_UNICODE_MULTI:
instead?
You are right. Sorry.
+
usb_ext_prop_put_unicode_multi(buf, ret,
+ext_prop-data,
+
ext_prop-data_len);
+ break;
case USB_EXT_PROP_BINARY:
usb_ext_prop_put_binary(buf, ret,
ext_prop-data,
diff --git a/drivers/usb/gadget/u_os_desc.h
b/drivers/usb/gadget/u_os_desc.h
index 947b7dd..bee4274 100644
--- a/drivers/usb/gadget/u_os_desc.h
+++ b/drivers/usb/gadget/u_os_desc.h
@@ -120,4 +120,32 @@ static inline int usb_ext_prop_put_unicode(u8 *buf,
int pnl, const char *string,
return data_len;
}
I'm not sure I understand the logic of the below function well.
+static inline int usb_ext_prop_put_unicode_multi(u8 *buf, int pnl,
+ const char *string, int data_len)
+{
+ int outlen = 0;
+
+ put_unaligned_le32(data_len, usb_ext_prop_data_len_ptr(buf, pnl));
+
+ while (*string outlen data_len - 2) {
You keep looping as long as the source *string is not '\0'
and advance the string in each loop by adding (strlen() + 1) of
what is currently available starting at *string.
For example:
string: a\0b\0and this is past the end of your source buffer
first loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: b\0and this is past the end of your source
buffer */
second loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: and this is past the end of your source
buffer */
so effectively the first part of the while condition rarely ever becomes
false.
In other words when you process all the source strings from string you, by
design,
end up one byte past the terminating '\0' of the source buffer. The contents
of this memory can be anything, there is just 1/256 chance it is zero,
so the while (*string part does not make sense to me.
The assumtion is that the input string is also double Nul-terminated.
E.g. one\0two\0three\0\0
Should I add a parameter inlen which contains the input buffer length?
Or can I trust that the input string is double Nul-terminated?
Or is there a better way?
+ int len = strlen(string);
+ int result = utf8s_to_utf16s(string, len,
UTF16_LITTLE_ENDIAN,
+ (wchar_t *) usb_ext_prop_data_ptr(buf, pnl +
outlen),
+ data_len - outlen - 2);
+ if (result 0)
+ return result;
+ outlen += result 1;
+ string += len + 1;
+ put_unaligned_le16(0,
+ buf[USB_EXT_PROP_B_PROPERTY_DATA + pnl +
outlen]);
You put a terminating NUL two-byte after each destination, wide string.
+ outlen += 2;
Then you advance the outlen to reflect the above.
+ }
Suppose there is just one string in the source string, so the loop
terminates now.
Am I correct that at this point outlen is supposed to be equal data_len?
If it is, than please see below (*).
+
+ put_unaligned_le16(0,
+ buf[USB_EXT_PROP_B_PROPERTY_DATA + pnl +
outlen]);
Why again terminate the destination string? And, since outlen value was
incremented by 2 in the meantime there will be two terminators in a row?
+ outlen += 2;
It is supposed
[PATCH] net: usb: sr9700: Use 'SR_' prefix for the common register macros
The commone register macors (e.g. RSR) is too commont to drivers, it may
be conflict with the architectures (e.g. xtensa, sh).
The related warnings (with allmodconfig under xtensa):
CC [M] drivers/net/usb/sr9700.o
In file included from drivers/net/usb/sr9700.c:24:0:
drivers/net/usb/sr9700.h:65:0: warning: RSR redefined
#define RSR 0x06
^
In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/net/usb/sr9700.c:13:
./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of
the previous definition
#define RSR(v,sr) __asm__ __volatile__ (rsr %0,__stringify(sr) : =a(v));
^
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
drivers/net/usb/sr9700.c | 36 +-
drivers/net/usb/sr9700.h | 66
2 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 99b69af..4a1e9c4 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -77,7 +77,7 @@ static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
int ret;
udelay(1);
- ret = sr_read_reg(dev, EPCR, tmp);
+ ret = sr_read_reg(dev, SR_EPCR, tmp);
if (ret 0)
return ret;
@@ -98,15 +98,15 @@ static int sr_share_read_word(struct usbnet *dev, int phy,
u8 reg,
mutex_lock(dev-phy_mutex);
- sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
- sr_write_reg(dev, EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
+ sr_write_reg(dev, SR_EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, SR_EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
ret = wait_phy_eeprom_ready(dev, phy);
if (ret 0)
goto out_unlock;
- sr_write_reg(dev, EPCR, 0x0);
- ret = sr_read(dev, EPDR, 2, value);
+ sr_write_reg(dev, SR_EPCR, 0x0);
+ ret = sr_read(dev, SR_EPDR, 2, value);
netdev_dbg(dev-net, read shared %d 0x%02x returned 0x%04x, %d\n,
phy, reg, *value, ret);
@@ -123,19 +123,19 @@ static int sr_share_write_word(struct usbnet *dev, int
phy, u8 reg,
mutex_lock(dev-phy_mutex);
- ret = sr_write(dev, EPDR, 2, value);
+ ret = sr_write(dev, SR_EPDR, 2, value);
if (ret 0)
goto out_unlock;
- sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
- sr_write_reg(dev, EPCR, phy ? (EPCR_WEP | EPCR_EPOS | EPCR_ERPRW) :
+ sr_write_reg(dev, SR_EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, SR_EPCR, phy ? (EPCR_WEP | EPCR_EPOS | EPCR_ERPRW) :
(EPCR_WEP | EPCR_ERPRW));
ret = wait_phy_eeprom_ready(dev, phy);
if (ret 0)
goto out_unlock;
- sr_write_reg(dev, EPCR, 0x0);
+ sr_write_reg(dev, SR_EPCR, 0x0);
out_unlock:
mutex_unlock(dev-phy_mutex);
@@ -188,7 +188,7 @@ static int sr_mdio_read(struct net_device *netdev, int
phy_id, int loc)
if (loc == MII_BMSR) {
u8 value;
- sr_read_reg(dev, NSR, value);
+ sr_read_reg(dev, SR_NSR, value);
if (value NSR_LINKST)
rc = 1;
}
@@ -228,7 +228,7 @@ static u32 sr9700_get_link(struct net_device *netdev)
int rc = 0;
/* Get the Link Status directly */
- sr_read_reg(dev, NSR, value);
+ sr_read_reg(dev, SR_NSR, value);
if (value NSR_LINKST)
rc = 1;
@@ -281,8 +281,8 @@ static void sr9700_set_multicast(struct net_device *netdev)
}
}
- sr_write_async(dev, MAR, SR_MCAST_SIZE, hashes);
- sr_write_reg_async(dev, RCR, rx_ctl);
+ sr_write_async(dev, SR_MAR, SR_MCAST_SIZE, hashes);
+ sr_write_reg_async(dev, SR_RCR, rx_ctl);
}
static int sr9700_set_mac_address(struct net_device *netdev, void *p)
@@ -297,7 +297,7 @@ static int sr9700_set_mac_address(struct net_device
*netdev, void *p)
}
memcpy(netdev-dev_addr, addr-sa_data, netdev-addr_len);
- sr_write_async(dev, PAR, 6, netdev-dev_addr);
+ sr_write_async(dev, SR_PAR, 6, netdev-dev_addr);
return 0;
}
@@ -340,7 +340,7 @@ static int sr9700_bind(struct usbnet *dev, struct
usb_interface *intf)
mii-phy_id_mask = 0x1f;
mii-reg_num_mask = 0x1f;
- sr_write_reg(dev, NCR, NCR_RST);
+ sr_write_reg(dev, SR_NCR, NCR_RST);
udelay(20);
/* read MAC
@@ -348,17 +348,17 @@ static int sr9700_bind(struct usbnet *dev, struct
usb_interface *intf)
* EEPROM automatically to PAR. In case there is no EEPROM externally,
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
Looks good to me. Applied it on v3.21 queue.
Thanks,
Chanwoo Choi
On 02/02/2015 07:21 PM, Roger Quadros wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-HOST (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
- changed host cable name to USB-HOST
- use 'depends on' instead of 'select' GPIOLIB
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 237
+
4 files changed, 263 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID
pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
I add some description for example as following:
+Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
+ extcon_usb1 {
+ compatible = linux,extcon-usb-gpio;
+ id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+ }
+
+ omap_dwc3_1 {
+ extcon = extcon_usb1;
+ };
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe 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 v1] ehci-pci: disable for Intel MID platforms
How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return - ENODEV immediately. It is module_init(ehci_pci_init) in ehci-pci.c, so ehci_pci_init will always be called. 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
[PATCH RESEND] usb: dwc2: Fix a bug in reading the endpoint directions from reg.
According to the DWC2 datasheet, the HWCFG1 register stores
the configured endpoint directions for endpoints 0-15 in bit positions
0-31.
==
Endpoint Direction (EpDir)
This 32-bit field uses two bits per endpoint to determine the endpoint
direction.
Endpoint
Bits [31:30]: Endpoint 15 direction
Bits [29:28]: Endpoint 14 direction
Bits [3:2]: Endpoint 1 direction
Bits[1:0]: Endpoint 0 direction (always BIDIR)
==
The DWC2 driver is currently interpreting the contents of the register
as directions for endpoints 1-15 which leads to an error in determining
the configured endpoint directions in the core because the first 2 bits
determine the direction of endpoint 0 and not 1.
This is based on testing/next branch in Felipe's git.
Signed-off-by: Roshan Pius rp...@chromium.org
---
drivers/usb/dwc2/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 50ae096..706165c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3167,7 +3167,7 @@ static int s3c_hsotg_hw_cfg(struct dwc2_hsotg *hsotg)
hsotg-eps_out[0] = hsotg-eps_in[0];
cfg = readl(hsotg-regs + GHWCFG1);
- for (i = 1; i hsotg-num_of_eps; i++, cfg = 2) {
+ for (i = 1, cfg = 2; i hsotg-num_of_eps; i++, cfg = 2) {
ep_type = cfg 3;
/* Direction in or both */
if (!(ep_type 2)) {
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line unsubscribe 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: musb: core: add pm_runtime_irq_safe()
We need a pm_runtime_get_sync() call from within musb_gadget_pullup() to make sure registers are accessible at that time. The problem is that musb_gadget_pullup() is called with IRQs disabled and, because of that, we need to tell pm_runtime that this pm_runtime_get_sync() is IRQ safe. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/musb/musb_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 34cce3e38c49..15bbf577c8ce 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -1970,6 +1970,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl) pm_runtime_use_autosuspend(musb-controller); pm_runtime_set_autosuspend_delay(musb-controller, 200); + pm_runtime_irq_safe(musb-controller); pm_runtime_enable(musb-controller); spin_lock_init(musb-lock); -- 2.3.0-rc1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: musb: gadget: get rid of stop_activity()
that function is pretty close to a no-op by now,
all we need is a call to musb_stop().
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_gadget.c | 40 +---
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b2d9040c7685..4c481cd66c77 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1876,44 +1876,6 @@ err:
return retval;
}
-static void stop_activity(struct musb *musb, struct usb_gadget_driver *driver)
-{
- int i;
- struct musb_hw_ep *hw_ep;
-
- /* don't disconnect if it's not connected */
- if (musb-g.speed == USB_SPEED_UNKNOWN)
- driver = NULL;
- else
- musb-g.speed = USB_SPEED_UNKNOWN;
-
- /* deactivate the hardware */
- if (musb-softconnect) {
- musb-softconnect = 0;
- musb_pullup(musb, 0);
- }
- musb_stop(musb);
-
- /* killing any outstanding requests will quiesce the driver;
-* then report disconnect
-*/
- if (driver) {
- for (i = 0, hw_ep = musb-endpoints;
- i musb-nr_endpoints;
- i++, hw_ep++) {
- musb_ep_select(musb-mregs, i);
- if (hw_ep-is_shared_fifo /* || !epnum */) {
- nuke(hw_ep-ep_in, -ESHUTDOWN);
- } else {
- if (hw_ep-max_packet_sz_tx)
- nuke(hw_ep-ep_in, -ESHUTDOWN);
- if (hw_ep-max_packet_sz_rx)
- nuke(hw_ep-ep_out, -ESHUTDOWN);
- }
- }
- }
-}
-
/*
* Unregister the gadget driver. Used by gadget drivers when
* unregistering themselves from the controller.
@@ -1940,7 +1902,7 @@ static int musb_gadget_stop(struct usb_gadget *g)
(void) musb_gadget_vbus_draw(musb-g, 0);
musb-xceiv-otg-state = OTG_STATE_UNDEFINED;
- stop_activity(musb, NULL);
+ musb_stop(musb);
otg_set_peripheral(musb-xceiv-otg, NULL);
musb-is_active = 0;
--
2.3.0-rc1
--
To unsubscribe from this list: send the line unsubscribe 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: gadget: function: phonet: balance usb_ep_disable calls
f_phonet's -set_alt() method will call usb_ep_disable()
potentially on an endpoint which is already disabled. That's
something the gadget/function driver must guarantee that it's
always balanced.
In order to balance the calls, just make sure the endpoint
was enabled before by means of checking the validity of
driver_data.
Reported-by: Pali Rohár pali.ro...@gmail.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/function/f_phonet.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_phonet.c
b/drivers/usb/gadget/function/f_phonet.c
index c89e96cfa3e4..c0c3ef272714 100644
--- a/drivers/usb/gadget/function/f_phonet.c
+++ b/drivers/usb/gadget/function/f_phonet.c
@@ -417,7 +417,10 @@ static int pn_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
return -EINVAL;
spin_lock(port-lock);
- __pn_reset(f);
+
+ if (fp-in_ep-driver_data)
+ __pn_reset(f);
+
if (alt == 1) {
int i;
--
2.3.0-rc1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: musb: try a race-free wakeup
Sebastian, On Mon, Jan 26, 2015 at 2:57 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 01/21/2015 06:06 PM, Bin Liu wrote: Hi Sebastian, Hi Bin, With this patch, hubs stop working on TI AM335x EVMs when autosuspend is enabled. I booted the board, connected a hub to the USB1 host port, it got enumerated properly, then connected a thumb drive to the hub, but the drive was not enumerated, no any log from kernel. Removing the drive, no any kernel message either. Finally removed the hub, no disconnect for the hub. Now check MUSB1 DEVCTL register, it value is 0x5D. Reverted this patch, the issue disappeared. Or disable usbcore autosuspend, the issue did not happen. I tested 7+ hubs, all have the same issue. I tested on git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git, tag ti2014.10.01. have not tested with mainline kernel yet. Have you validated this test case? No, I had no USB-hub attached. It would be nice if you could figure out which part is responsible for the missing detection because otherwise suspend/resume is broken. I think I found the cause. Plugging a device behind a hub, this is related to runtime PM, so the finish_resume_work() should also be added in musb_runtime_resume(), also musb_host_resume_root_hub() should not be moved as did in your patch, this call is used to trigger the bus resume. A patch will be coming soon - tomorrow. Regards, -Bin. Thanks, -Bin. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: net2280 driver and gadgetfs?
Hello Ricardo,
It does build and I have verified that it works fine with g_mass_storage and
g_zero.
However it does not seem to work with gadgetfs. Here are the kernel messages I
get when I load udc-core.ko, net2280.ko and gadgetfs.ko and then
mkdir /dev/gadget
mount -t gadgetfs none /dev/gadget
[ 96.023408] net2280 :04:00.0: usb_reset_338x: Defect 7374 FsmValue
0xf000
[ 96.023436] net2280 :04:00.0: usb_reinit_338x: Defect 7374 FsmValue
f000
[ 96.023508] net2280 :04:00.0: irq 52 for MSI/MSI-X
[ 96.023587] net2280 :04:00.0: PLX NET228x/USB338x USB Peripheral
Controller
[ 96.023593] net2280 :04:00.0: irq 52, pci mem c90004e84000, chip rev
00ab
[ 96.023597] net2280 :04:00.0: version: 2005 Sept 27/v3.0; dma enabled
enhanced mode
[ 96.023601] usb_add_gadget_udc_release
[ 96.030691] gadgetfs: USB Gadget filesystem, version 24 Aug 2004
[ 96.034381] udc :04:00.0: registering UDC driver [(null)]
At that point gadgetfs is mounted and there is a 0 length /dev/gadget/net2280
file.
If I then run the gadgetfs example program (www.linux-usb.org/gadget/usb.c) I
get the following kernel messages
[ 109.846832] udc :04:00.0: registering UDC driver [USB Gadget filesystem]
[ 109.846865] gadgetfs: bound to net2280 driver
[ 109.846868] usb_gadget_udc_start
[ 109.846876] net2280 :04:00.0: Operate Defect 7374 workaround soft this
time
[ 109.846880] net2280 :04:00.0: It will operate on cold-reboot and SS
connect
[ 109.846975] net2280 :04:00.0: ep0_start_338x: Defect 7374 FsmValue
1000
At that point, there are the 0 length /dev/gadget/net2280 file as well as 0
length /dev/gadget/ep-a through /dev/gadget/ep-h files representing the
endpoints.
Then if I connect the gadget to a USB host, the example program terminates
because it gets a -EINVAL return from the read function call in ep0_thread.
There are the following kernel messages.
[ 917.671457] gadgetfs: connected
[ 917.671634] usb_gadget_remove_driver
[ 917.671647] gadgetfs :04:00.0: unregistering UDC driver [net2280]
[ 917.671693] gadgetfs: disconnected
[ 917.671732] usb_gadget_udc_stop
[ 917.671743] net2280 :04:00.0: usb_reset_338x: Defect 7374 FsmValue
0x2000
[ 917.671788] net2280 :04:00.0: usb_reinit_338x: Defect 7374 FsmValue
2000
Any ideas would be gratefully received.
Thank you,
Carolyn
-Original Message-
From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com]
Sent: Monday, February 02, 2015 1:47 AM
To: Smith, Carolyn J; Linux USB Mailing List
Subject: Re: net2280 driver and gadgetfs?
Hello Carolyn
I have tried using g_mass_storage and g_network, but I cannot see why it should
not work with gadgetfs.
What is exactly the issue? It does not build? it does not behave as expected?
I am putting the linux-usb mailing list on cc
Regards!
On Sat, Jan 31, 2015 at 12:06 AM, Smith, Carolyn J
carolyn.j.sm...@tektronix.com wrote:
Hello Ricardo,
I am working on a board with the PLX3380 chip on it. Thank you very
much for your work on integrating support for this chip into the Linux
net2280 driver.
Have you used the driver successfully with the gadgetfs filesystem at all?
Or do you know of anyone who has? I'm not having any luck getting the
gadgetfs example at www.linux-usb.org/gadget/usb.c working properly with it.
Thank you for any help or suggestions you can provide,
Carolyn Smith
Tektronix, Inc.
--
Ricardo Ribalda
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
[PATCH V7 RESEND 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Adding phy calibration sequence for USB 3.0 DRD PHY present on Exynos5420/5800 systems. This calibration facilitates setting certain PHY parameters viz. the Loss-of-Signal (LOS) Detector Threshold Level, as well as Tx-Vboost-Level for Super-Speed operations. Additionally we also set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/phy/phy-exynos5-usbdrd.c | 219 +++--- 1 file changed, 203 insertions(+), 16 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 0437401..5834529 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK (0x3f 1) #define LINKSYSTEM_FLADJ(_x) ((_x) 1) #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27) #define EXYNOS5_DRD_PHYUTMI0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE0x0c #define EXYNOS5_DRD_PHYCLKRST 0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #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 BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2 BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x32 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 8) #define PHYCLKRST_FSEL(_x) ((_x) 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2) - #define PHYCLKRST_PORTRESETBIT(1) #define PHYCLKRST_COMMONONNBIT(0) #define EXYNOS5_DRD_PHYREG00x14 +#define PHYREG0_SSC_REF_CLK_SELBIT(21) +#define PHYREG0_SSC_RANGE BIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READBIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) 2) +#define PHYREG0_CR_CAP_DATABIT(1) +#define PHYREG0_CR_CAP_ADDRBIT(0) + #define EXYNOS5_DRD_PHYREG10x18 +#define PHYREG1_CR_DATA_OUT(_x)((_x) 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM0 0x1c - #define PHYPARAM0_REF_USE_PAD BIT(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_PHYTERM0x24 #define EXYNOS5_DRD_PHYTEST0x28 - #define PHYTEST_POWERDOWN_SSP BIT(3) #define PHYTEST_POWERDOWN_HSP BIT(2) #define EXYNOS5_DRD_PHYADP 0x2c #define EXYNOS5_DRD_PHYUTMICLKSEL 0x30 - #define PHYUTMICLKSEL_UTMI_CLKSEL BIT(2) #define EXYNOS5_DRD_PHYRESUME 0x34
[PATCH 2/4] usb: gadget: net2280: remove fiforegs as it is unused
Remove fiforegs from struct net2280 and net2280_ep as it is unused.
By the way, ep-fiforegs = dev-fiforegs[i] assignment is incorrect.
It should be ep-fiforegs = dev-fiforegs[ne[i]], but it doesn't
matter now.
Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com
---
drivers/usb/gadget/udc/net2280.c | 4
drivers/usb/gadget/udc/net2280.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index b7024dc..d51430f 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1996,11 +1996,9 @@ static void usb_reinit_338x(struct net2280 *dev)
ep-regs = (struct net2280_ep_regs __iomem *)
(((void __iomem *)dev-epregs[ne[i]]) +
ep_reg_addr[i]);
- ep-fiforegs = dev-fiforegs[i];
} else {
ep-cfg = dev-epregs[i];
ep-regs = dev-epregs[i];
- ep-fiforegs = dev-fiforegs[i];
}
ep-fifo_size = (i != 0) ? 2048 : 512;
@@ -3380,8 +3378,6 @@ static int net2280_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
u32 usbstat;
dev-usb_ext = (struct usb338x_usb_ext_regs __iomem *)
(base + 0x00b4);
- dev-fiforegs = (struct usb338x_fifo_regs __iomem *)
- (base + 0x0500);
dev-llregs = (struct usb338x_ll_regs __iomem *)
(base + 0x0700);
dev-ll_lfps_regs = (struct usb338x_ll_lfps_regs __iomem *)
diff --git a/drivers/usb/gadget/udc/net2280.h b/drivers/usb/gadget/udc/net2280.h
index ac8d5a2..4dff60d 100644
--- a/drivers/usb/gadget/udc/net2280.h
+++ b/drivers/usb/gadget/udc/net2280.h
@@ -96,7 +96,6 @@ struct net2280_ep {
struct net2280_ep_regs __iomem *regs;
struct net2280_dma_regs __iomem *dma;
struct net2280_dma *dummy;
- struct usb338x_fifo_regs __iomem *fiforegs;
dma_addr_t td_dma; /* of dummy */
struct net2280 *dev;
unsigned long irqs;
@@ -181,7 +180,6 @@ struct net2280 {
struct net2280_dma_regs __iomem *dma;
struct net2280_dep_regs __iomem *dep;
struct net2280_ep_regs __iomem *epregs;
- struct usb338x_fifo_regs__iomem *fiforegs;
struct usb338x_ll_regs __iomem *llregs;
struct usb338x_ll_lfps_regs __iomem *ll_lfps_regs;
struct usb338x_ll_tsn_regs __iomem *ll_tsn_regs;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
Hi Roger, On 02/02/2015 06:09 PM, Roger Quadros wrote: Chanwoo, On 02/02/15 07:04, Chanwoo Choi wrote: Hi Roger, On 01/30/2015 11:05 PM, Roger Quadros wrote: Hi, On 30/01/15 13:04, Roger Quadros wrote: Felipe Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is USB-Host and not USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of USB-HOST to USB-Host. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. Hold on. Let's first decide what we really want to go ahead with USB-Host or USB-HOST. Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST) without any standard way. So, I have plan to define common cable name in extcon header file by using capital letter. OK. In that case, this patch is not required. I will resend patch 1 with cable name corrected to USB-HOST. If you possbile, I want to use 'USB-HOST' cable name in drivers related to extcon. If we use different cable name, this cause the confusion to control cable. Thanks, Chanwoo -- To unsubscribe from this list: send the line unsubscribe 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/4] usb: gadget: net2280: use ep_autoconfig compatible names in advance mode
Each struct usb_ep added for net2280 can be used in either direction.
Whereas, each struct usb_ep for usb3380 has fixed direction. Use
ep_autoconf compatible names so that endpoint with correct direction
can be selected.
Name sequence is due to the logic in usb_reinit_338x() in ne[] and
ep_reg_addr[].
Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com
---
drivers/usb/gadget/udc/net2280.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index d2c0bf6..b7024dc 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -80,6 +80,13 @@ static const char *const ep_name[] = {
ep-e, ep-f, ep-g, ep-h,
};
+/* Endpoint names for usb3380 advance mode */
+static const char *const ep_name_adv[] = {
+ ep0name,
+ ep1in, ep2out, ep3in, ep4out,
+ ep1out, ep2in, ep3out, ep4in,
+};
+
/* mode 0 == ep-{a,b,c,d} 1K fifo each
* mode 1 == ep-{a,b} 2K fifo each, ep-{c,d} unavailable
* mode 2 == ep-a 2K fifo, ep-{b,c} 1K each, ep-d unavailable
@@ -1977,7 +1984,7 @@ static void usb_reinit_338x(struct net2280 *dev)
for (i = 0; i dev-n_ep; i++) {
struct net2280_ep *ep = dev-ep[i];
- ep-ep.name = ep_name[i];
+ ep-ep.name = dev-enhanced_mode ? ep_name_adv[i] : ep_name[i];
ep-dev = dev;
ep-num = i;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] usb: gadget: net2280: print error in ep_ops error paths
Hopefully, these prints will help localize the problems faster.
Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com
---
drivers/usb/gadget/udc/net2280.c | 174 ---
1 file changed, 126 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index d51430f..510a0e0 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -145,31 +145,44 @@ net2280_enable(struct usb_ep *_ep, const struct
usb_endpoint_descriptor *desc)
u32 max, tmp;
unsigned long flags;
static const u32 ep_key[9] = { 1, 0, 1, 0, 1, 1, 0, 1, 0 };
+ int ret = 0;
ep = container_of(_ep, struct net2280_ep, ep);
if (!_ep || !desc || ep-desc || _ep-name == ep0name ||
- desc-bDescriptorType != USB_DT_ENDPOINT)
+ desc-bDescriptorType != USB_DT_ENDPOINT) {
+ pr_err(%s: failed at line=%d\n, __func__, __LINE__);
return -EINVAL;
+ }
dev = ep-dev;
- if (!dev-driver || dev-gadget.speed == USB_SPEED_UNKNOWN)
- return -ESHUTDOWN;
+ if (!dev-driver || dev-gadget.speed == USB_SPEED_UNKNOWN) {
+ ret = -ESHUTDOWN;
+ goto print_err;
+ }
/* erratum 0119 workaround ties up an endpoint number */
- if ((desc-bEndpointAddress 0x0f) == EP_DONTUSE)
- return -EDOM;
+ if ((desc-bEndpointAddress 0x0f) == EP_DONTUSE) {
+ ret = -EDOM;
+ goto print_err;
+ }
if (dev-quirks PLX_SUPERSPEED) {
- if ((desc-bEndpointAddress 0x0f) = 0x0c)
- return -EDOM;
+ if ((desc-bEndpointAddress 0x0f) = 0x0c) {
+ ret = -EDOM;
+ goto print_err;
+ }
ep-is_in = !!usb_endpoint_dir_in(desc);
- if (dev-enhanced_mode ep-is_in ep_key[ep-num])
- return -EINVAL;
+ if (dev-enhanced_mode ep-is_in ep_key[ep-num]) {
+ ret = -EINVAL;
+ goto print_err;
+ }
}
/* sanity check ep-e/ep-f since their fifos are small */
max = usb_endpoint_maxp(desc) 0x1fff;
- if (ep-num 4 max 64 (dev-quirks PLX_LEGACY))
- return -ERANGE;
+ if (ep-num 4 max 64 (dev-quirks PLX_LEGACY)) {
+ ret = -ERANGE;
+ goto print_err;
+ }
spin_lock_irqsave(dev-lock, flags);
_ep-maxpacket = max 0x7ff;
@@ -199,7 +212,8 @@ net2280_enable(struct usb_ep *_ep, const struct
usb_endpoint_descriptor *desc)
(dev-gadget.speed == USB_SPEED_HIGH max != 512) ||
(dev-gadget.speed == USB_SPEED_FULL max 64)) {
spin_unlock_irqrestore(dev-lock, flags);
- return -ERANGE;
+ ret = -ERANGE;
+ goto print_err;
}
}
ep-is_iso = (tmp == USB_ENDPOINT_XFER_ISOC);
@@ -278,7 +292,11 @@ net2280_enable(struct usb_ep *_ep, const struct
usb_endpoint_descriptor *desc)
/* pci writes may still be posted */
spin_unlock_irqrestore(dev-lock, flags);
- return 0;
+ return ret;
+
+print_err:
+ dev_err(ep-dev-pdev-dev, %s: error=%d\n, __func__, ret);
+ return ret;
}
static int handshake(u32 __iomem *ptr, u32 mask, u32 done, int usec)
@@ -433,9 +451,10 @@ static int net2280_disable(struct usb_ep *_ep)
unsigned long flags;
ep = container_of(_ep, struct net2280_ep, ep);
- if (!_ep || !ep-desc || _ep-name == ep0name)
+ if (!_ep || !ep-desc || _ep-name == ep0name) {
+ pr_err(%s: Invalid ep=%p or ep-desc\n, __func__, _ep);
return -EINVAL;
-
+ }
spin_lock_irqsave(ep-dev-lock, flags);
nuke(ep);
@@ -465,13 +484,18 @@ static struct usb_request
struct net2280_ep *ep;
struct net2280_request *req;
- if (!_ep)
+ if (!_ep) {
+ pr_err(%s: Invalid ep\n, __func__);
return NULL;
+ }
ep = container_of(_ep, struct net2280_ep, ep);
req = kzalloc(sizeof(*req), gfp_flags);
- if (!req)
+ if (!req) {
+ dev_err(ep-dev-pdev-dev,
+ %s: Unable to allocate memory for req\n, __func__);
return NULL;
+ }
INIT_LIST_HEAD(req-queue);
@@ -482,6 +506,9 @@ static struct usb_request
td = pci_pool_alloc(ep-dev-requests, gfp_flags,
req-td_dma);
if (!td) {
+ dev_err(ep-dev-pdev-dev,
+ %s: Unable to allocate dma memory\n,
+ __func__);
[PATCH 4/4] usb: gadget: net2280: don't connect from udc_start
net2280_start can be called with pullup disabled. Don't set softconnect flag in it. Let net2280_pullup handle the connection part. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com --- drivers/usb/gadget/udc/net2280.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c index 510a0e0..4195b83 100644 --- a/drivers/usb/gadget/udc/net2280.c +++ b/drivers/usb/gadget/udc/net2280.c @@ -2269,7 +2269,6 @@ static int net2280_start(struct usb_gadget *_gadget, dev-ep[i].irqs = 0; /* hook up the driver ... */ - dev-softconnect = 1; driver-driver.bus = NULL; dev-driver = driver; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
On 02/02/15 11:55, Chanwoo Choi wrote: Hi Roger, On 02/02/2015 06:09 PM, Roger Quadros wrote: Chanwoo, On 02/02/15 07:04, Chanwoo Choi wrote: Hi Roger, On 01/30/2015 11:05 PM, Roger Quadros wrote: Hi, On 30/01/15 13:04, Roger Quadros wrote: Felipe Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is USB-Host and not USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of USB-HOST to USB-Host. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. Hold on. Let's first decide what we really want to go ahead with USB-Host or USB-HOST. Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST) without any standard way. So, I have plan to define common cable name in extcon header file by using capital letter. OK. In that case, this patch is not required. I will resend patch 1 with cable name corrected to USB-HOST. If you possbile, I want to use 'USB-HOST' cable name in drivers related to extcon. If we use different cable name, this cause the confusion to control cable. Kernel tree shows following users of USB-Host that will have to be changed to USB-HOST. extcon-class.c: [EXTCON_USB_HOST] = USB-Host, extcon-max77693.c: [EXTCON_CABLE_USB_HOST] = USB-Host, extcon-max77693.c: extcon_set_cable_state(info-edev, USB-Host, attached); extcon-max8997.c: [EXTCON_CABLE_USB_HOST] = USB-Host, extcon-max8997.c: extcon_set_cable_state(info-edev, USB-Host, attached); extcon-rt8973a.c: [EXTCON_CABLE_USB_HOST] = USB-Host, extcon-sm5502.c:[EXTCON_CABLE_USB_HOST] = USB-Host, I'm not aware if any user space programs depend on this name. Do you know of any? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe 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: Kernel Ooops upon USB disconnect of a Western Digital My Passport 1TB drive
Hello again, I tried setting up netconsole (I don't have a null-modem serial cable with usb adaptor) and although it *does* capture some of the dump, it does not capture everything. The dump is from 3.18.5. Here goes (from the USB connection): [ 169.827703] usb 2-1.2: new high-speed USB device number 3 using ehci-pci [ 169.980222] usb-storage 2-1.2:1.0: USB Mass Storage device detected [ 169.982264] scsi host6: usb-storage 2-1.2:1.0 [ 169.984548] usbcore: registered new interface driver usb-storage [ 169.989296] usbcore: registered new interface driver uas [ 170.989458] scsi 6:0:0:0: Direct-Access WD My Passport 0748 1016 PQ: 0 ANSI: 6 [ 170.992673] scsi 6:0:0:1: Enclosure WD SES Device 1016 PQ: 0 ANSI: 6 [ 171.002766] sd 6:0:0:0: [sdb] Spinning up disk... [ 172.009278] .ready [ 173.012719] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) [ 173.016434] sd 6:0:0:0: [sdb] Write Protect is off [ 173.017780] ses 6:0:0:1: Attached Enclosure device [ 173.021519] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08 [ 173.024736] sd 6:0:0:0: [sdb] No Caching mode page found [ 173.026785] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 173.040339] sdb: sdb1 [ 173.045652] sd 6:0:0:0: [sdb] Attached SCSI disk [ 183.706124] usb 2-1.2: USB disconnect, device number 3 [ 183.725921] BUG: unable to handle kernel NULL pointer dereference at 01a0 [ 183.728560] IP: [812850d5] blk_post_runtime_resume+0x65/0x80 [ 183.730820] PGD 0 [ 183.733038] Oops: 0002 [#1] PREEMPT SMP [ 183.735285] Modules linked in: ses enclosure uas usb_storage netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic coretemp arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iwldvm kvm mac80211 crct10dif_pclmul crc32_pclmul crc32c_intel iTCO_wdt iTCO_vendor_support ghash_clmulni_intel aesni_intel iwlwifi aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd psmouse serio_raw i2c_i801 cfg80211 ip6t_REJECT nf_reject_ipv6 thinkpad_acpi wmi nvram xt_hl rfkill ip6t_rt hwmon battery ac snd_hda_intel tpm_tis snd_hda_controller tpm snd_hda_codec snd_hwdep nf_conntrack_ipv6 snd_pcm nf_defrag_ipv6 evdev snd_timer e1000e snd thermal mac_hid mei_me soundcore mei ptp ipt_REJECT lpc_ich nf_reject_ipv4 pps_core shpchp processor xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack e1000e snd thermal mac_hid mei_me soundcore mei ptp ipt_REJECT lpc_ich nf_reject_ipv4 pps_core shpchp processor xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables sch_fq_codel vboxdrv(O) usbnet mii tp_smapi(O) thinkpad_ec(O) nfs lockd grace sunrpc fscache cpufreq_powersave acpi_call(O) ext4 crc16 mbcache jbd2 sd_mod atkbd libps2 sdhci_pci sdhci led_class ahci libahci libata ehci_pci ehci_hcd scsi_mod mmc_core usbcore usb_common i8042 serio i915 button intel_gtt i2c_algo_bit video drm_kms_helper drm i2c_core [ 183.981709] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G UD O 3.18.5-1-ARCH #1 [ 183.985915] Hardware name: LENOVO 4177CTO/4177CTO, BIOS 83ET70WW (1.40 ) 06/12/2012 [ 183.990082] task: 880212941e30 ti: 88021296c000 task.ti: 88021296c000 [ 183.994203] RIP: 0010:[81091500] [81091500] kthread_data+0x10/0x20 [ 183.998426] RSP: 0018:88021296f3e8 EFLAGS: 00010092 [ 184.002645] RAX: RBX: RCX: [ 184.006893] RDX: 000f RSI: RDI: 880212941e30 [ 184.011063] RBP: 88021296f3e8 R08: R09: 880215803a00 [ 184.015247] R10: 88021e216480 R11: ea000846fc40 R12: 88021e213640 [ 184.019428] R13: 88021e213640 R14: 880212941e30 R15: [ 184.023591] FS: () GS:88021e20() knlGS: [ 184.027820] CS: 0010 DS: ES: CR0: 80050033 [ 184.032041] CR2: 0028 CR3: 01811000 CR4: 000407f0 [ 184.036227] Stack: [ 184.040518] 88021296f408 8108c275 88021296f408 [ 184.044910] 88021296f528 81550f55 880212941e30 00013640 [ 184.235199] [815552fc] ret_from_fork+0x7c/0xb0 [ 184.237699] [81090d50] ? kthread_create_on_node+0x1c0/0x1c0 [ 184.240179] Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 Is there anything I can do to make netconsole dump everything? -- To unsubscribe from this list: send the line unsubscribe 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: PD: [Bug 92341] xHCI USB driver, support for non-conformant HS USB devices with bulk endpoints of maxpacket size different than 512
Dear Alan, Your patch works like a charm. Tested both on my device and on a few standard MassStorageDevice class USB card-readers. Tests were conducted on Gigabyte GA-J1900N-D3V mainboard (with Intel#xAE; Celeron#x2122; J1900 quad-core processor onboard). dumps from running system follow. -bash-4.2# dmesg | grep -i xhci [2.325894] xhci_hcd :00:14.0: setting latency timer to 64 [2.325903] xhci_hcd :00:14.0: xHCI Host Controller [2.325917] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 1 [2.326058] xhci_hcd :00:14.0: cache line size of 64 is not supported [2.326082] xhci_hcd :00:14.0: irq 106 for MSI/MSI-X [2.326235] usb usb1: Product: xHCI Host Controller [2.326239] usb usb1: Manufacturer: Linux 3.12.17r2 xhci_hcd [2.327300] xhci_hcd :00:14.0: xHCI Host Controller [2.327309] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [2.327422] usb usb2: Product: xHCI Host Controller [2.327426] usb usb2: Manufacturer: Linux 3.12.17r2 xhci_hcd [2.537398] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd [2.721199] usb 1-1: new high-speed USB device number 2 using xhci_hcd [2.905195] usb 1-2: new high-speed USB device number 3 using xhci_hcd [3.025201] usb 1-1.2: new low-speed USB device number 4 using xhci_hcd [ 303.853145] usb 1-1.3: new high-speed USB device number 5 using xhci_hcd -bash-4.2# lsusb Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd Bus 001 Device 003: ID 03eb:0002 Atmel Corp. //MY DEVICE Bus 002 Device 002: ID 045b:0210 Hitachi, Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 046d:c31c Logitech, Inc. Keyboard K120 for Business Bus 001 Device 005: ID 1e3d:4083 Chipsbank Microelectronics Co., Ltd //standard MSD class USB reader details of my device: -bash-4.2# lsusb -v -d 03eb: Bus 001 Device 003: ID 03eb:0002 Atmel Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x03eb Atmel Corp. idProduct 0x0002 bcdDevice0.01 iManufacturer 1 webpage iProduct2 USB2boards bridge with MSD. iSerial 3 53303120313739343030372035323035 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 69 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0080 1x 128 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0100 1x 256 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 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 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes
Re: PD: [Bug 92341] xHCI USB driver, support for non-conformant HS USB devices with bulk endpoints of maxpacket size different than 512
Le Mon, 2 Feb 2015 15:39:47 +0200, Mathias Nyman mathias.ny...@linux.intel.com a écrit : So apparently there were some devices that started working after the 512byte was forced? I wasn't involved in this at the time so I don't know the details, perhaps Alan remembers? As the patch says, USB2 specs say HS bulk endpoints only supports 512 bytes max packet size. USB2 spec section 5.8.3 Bulk Transfer Packet Size Constraints: All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum packet sizes for full-speed bulk endpoints and 512 bytes for high-speed bulk endpoints. No Host Controller is required to support larger or smaller maximum packet sizes. Or maybe that can be interpreted as 8-, 16-, 32-, 64, AND 512 bytes supported for HS bulk endpoints? I'm otherwise ok with adding the other max packet sizes as well, just worried about the original patch. Are we going to break something that the original patch once fixed -Mathias If ehci driver allows to support others sizes, there may have some devices that use it for HS. Do you know if the windows driver allows this ? Looking from ehci driver [1] it seems to be the case. Instead of forbid value smaller than 512, can we have a list of controllers that can't handle it and make it works on others ? Does windows xhci driver allow value different of 512 for HS ? Matthieu [1] ehci-q.c: /* The USB spec says that high speed bulk endpoints * always use 512 byte maxpacket. But some device * vendors decided to ignore that, and MSFT is happy * to help them do so. So now people expect to use * such nonconformant devices with Linux too; sigh. */ -- To unsubscribe from this list: send the line unsubscribe 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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi David, What exactly are we breaking here? The USB on BYT-CR does not work yet with the mainline kernel, or does it? To enable it, I already suggested the BYT quirk (attached again). It used to work with mainline with minor restrictions. It stopped working (and I failed to catch it during patch review) when NOP phy enumeration was removed from dwc3-pci.c (but my understanding is that Felipe is expecting to add it back as default phy in case no phy is found by dwc3). BYT-CR worked well except for operations that needed to access phy's registers via ULPI bus (e.g. eye optimization). But to power on i.e. TUSB1210 all you need it to toggle GPIOs, which is done by generic phy. The need for ULPI bus was to complement this missing features, but instead we're breaking BYT-CR :/ So what you are saying that if I get one of those devices you mentioned and try vanilla kernel on it, the USB will work without any modifications to the kernel? You're misunderstanding BYT-CR SoC and external board components. The only reason that prevents most of BYT-CR boards' USB device work out-of-the-box is a switch device muxing D+/D- between host and device controllers (they depend on a single GPIO level to be toggled to get USB device working). I started discussion on how to upstream this case, but this is board related, not BYT-CR related. Some boards have also an i2c switch which requires extra i2c driver to get USB device working. But it doesn't mean the phy/otg controllers aren't fully functional with dwc3 + generic phy drivers. OK, so after we add driver for the mux, are you saying that USB device mode works without need for any patches to dwc3 or the nop phy driver for example with v3.18? In the code that we had in v3.18, the nop phy platform data had the reset gpio value set to -1 (invalid) by the dwc3-pci, so there was nothing toggling the reset gpio yet and the cs gpio was not handled at all. So unless you are saying we don't need to toggle the gpios before the USB became operational, you would have had to patch both dwc3-pci and phy-generic in order to get it operational. And of course if we didn't need to toggle them, there would not be any need for the nop phy at all. FWIW if you test a board without such switch (e.g. a reference BYT-T board called FFRD8 - BYT-CR is a derivation of BYT-T) it will work out-of-the-box. And it continues to work out-of-the-box even after we removed the creation of the PHY platform device because it does not need to toggle the gpios, right? BYT-T boards are actually one of the reason why we would really need the ulpi bus, because most them have tusb1211 (so not tusb1210) as the phy and they use it to detect the charger among other things. You missed my question. Have you tried to remove and reload dwc3 and phy modules with your test case? I do test unloading all the modules and reloading them back every time, and with the hack I suggested everything works just fine. We really can't go back to what we had. Please keep in mind that it tied us to the USB PHY framework, possibly forever, and we shouldn't have to depend on two different PHY frameworks. If we have to register the PHY device in dwc3-pci.c then you should create new nop phy for the generic phy framework and use that instead. But before you do that, we better be damn sure there is no way to make ulpi bus work, and we are not there yet. You have a point. But the transition should happen without creating regressions. You cannot remove previous design while we don't have the next one merged and functional. But I still don't see any regressions? Thanks, -- heikki -- To unsubscribe from this list: send the line unsubscribe 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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
You can't really compare a bus like i2c, which can't enumerate devices natively, to ULPI which can. why not ? The BIOS might not need to use the PHY (or USB) at all, it can very well decide to never turn it on, right ? If ULPI was seen as a bus, then no. BIOS would have definitely left the PHY on. In fact, if we would have just asked the BIOS writers to leave it on, they would not have any problem with that, even without the bus. That's a really wrong assumption. ULPI bus depends on dwc3 to be functional and dwc3 depends on phy to be functional to complete its power on sequence. We can't ask BIOS to let both up and running all the time. FWIW we *cannot* rely on ULPI bus enumeration to probe ULPI devices, because it requires the ULPI device to be previously functional which can't happen before the enumeration. Even if we ask BIOS to let phy functional after boot, what happens when we remove modules and load it again? Should we ask BIOS to power on the components again in order to probe and power it on? It's a circular dependency you're creating. I don't think the other boards we have which use TUSB1210, like the BYT-I ones and I think some Merrifield based boards, expect any less from PM efficiency then BYT-CR, but we don't need to do any tricks with them in order to use ULPI bus. That is what I mean when I say this is BYT-CR specific problem. perhaps because firmware on those other boards are powering up the PHY ? Yes. And that's wrong assumption. Not all fw will power on PHY. Maybe we should stop all of other discussions and concentrate on this one: BIOS will not guarantee phy will be functional after boot. And if we remove modules and load again, it won't be functional regardless what BIOS did during boot. I was wrong when I talked about BIOS powering the PHY before bootup. I admit it. I'm saying this again as a reminder to myself: We can't mix BIOS (or any FW) and ACPI. I mix them constantly. And I definitely need to stop talking about bootup. How this is handled is by letting the ACPI Power State methods of the dwc3 device take care of the toggling of the gpios. It is done with the help of something called GPIO OperationRegion. In case you are not familiar with ACPI, then if you send me ACPI dump of one of those devices (or just copy /sys/firmware/acpi/tables/DSDT), I can try to modify the DSDT for you so you can use to test it, and provide you with the ASL snippet. You will see that the PHY is indeed in reset after bootup like it is now (BIOS does nothing differently), but the gpios are automatically toggled by the DSDT code. So every time you load dwc3 module, the PHY will be operational when we need it, and when you unload dwc3, it will be left in reset again. The OS does not have to do anything. I really think that this BYT-CR case will be one of really rare exception we will see, especially if we manage to put together the ACPI table review that has been though about. I don't agree with PM arguments if it means that we should be ready to accept loosing possibility for a generic solution in OS with a single device like our PHY. I seriously doubt it would prevent the products using these boards of achieving their PM requirements. But this conversation is outside our topic. we're not loosing anything. We're just considering what's the best way to tackle that ulpi_read() inside probe(). TUSB1210 driver _has_ to cope with situations where reset_gpio/cs_gpio are in unexpected state. Saying we will just fix the firmware, as if that was a simple feat, is counter-productive. You know guys, we shouldn't always just lay down and say, we just have to accept it can be anything or we just have to try to prepare for everything. We can influence these things, and we should. We can influence these things inside our own companies before any products is launched using our SoCs, and since more and more companies are releasing their code into the public before their product are launched, we even have a change to influence others. Lack of standards does not mean we should not try to achieve consistency. For example, now I should probable write to Documentation that ULPI PHY needs to be in condition where it's register can be accessed before the interface is registered., and I'm pretty sure it would be enough to have an effect on many of the new platforms that use ULPI PHYs. In order for phy to be functional, it does not depend only on toggling GPIOs. It depends on DWC3 going to reset state, then phy executes power on sequence, then DWC3 going out of reset state to sync clocks with phy. You're saying we should tell BIOS is concurrently mess with dwc3 together with dwc3 driver? I don't understand what you are saying here? Because of the need to write to the ULPI registers, I don't think we should try anything else except to use ULPI bus
Re: PD: [Bug 92341] xHCI USB driver, support for non-conformant HS USB devices with bulk endpoints of maxpacket size different than 512
On 01.02.2015 04:05, Alan Stern wrote: On Sat, 31 Jan 2015, Kazimierz Marzec wrote: Good day, could You please take a look at https://bugzilla.kernel.org/show_bug.cgi?id=92341 Regards. Dnia Pi�tek, 30 Stycznia 2015 17:15 bugzilla-dae...@bugzilla.kernel.org napisa�(a) https://bugzilla.kernel.org/show_bug.cgi?id=92341 --- Comment #1 from Greg Kroah-Hartman g...@kroah.com --- On Fri, Jan 30, 2015 at 01:58:09PM +, bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=92341 Bug ID: 92341 Summary: xHCI USB driver, support for non-conformant HS USB devices with bulk endpoints of maxpacket size different than 512 Please send to the linux-usb@vger.kernel.org mailing list. You could try applying the patch below. I don't know if there's any reason why the xhci-hcd driver forces all bulk endpoints to use a maxpacket size of 512. MaxPacket was forced in: commit e4f47e3675e6f1f40906b785b934ce963e9f2eb3 USB: xHCI: override bogus bulk wMaxPacketSize values Patch descrition says: ...More importantly, it compensates for a common bug in high-speed bulk endpoint descriptors. In many devices there is a bulk endpoint having a wMaxPacketSize value smaller than 512, which is forbidden by the USB spec. Some xHCI controllers can't handle this and refuse to accept the endpoint. This patch changes the max_packet value to 512, which allows the controller to use the endpoint properly. So apparently there were some devices that started working after the 512byte was forced? I wasn't involved in this at the time so I don't know the details, perhaps Alan remembers? As the patch says, USB2 specs say HS bulk endpoints only supports 512 bytes max packet size. USB2 spec section 5.8.3 Bulk Transfer Packet Size Constraints: All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum packet sizes for full-speed bulk endpoints and 512 bytes for high-speed bulk endpoints. No Host Controller is required to support larger or smaller maximum packet sizes. Or maybe that can be interpreted as 8-, 16-, 32-, 64, AND 512 bytes supported for HS bulk endpoints? I'm otherwise ok with adding the other max packet sizes as well, just worried about the original patch. Are we going to break something that the original patch once fixed -Mathias -- To unsubscribe from this list: send the line unsubscribe 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] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages returned
On 01/30/2015, 10:54 PM, Tim Chen wrote: On Sat, 2015-01-31 at 00:03 +0300, Sergei Shtylyov wrote: On 01/30/2015 10:54 PM, Tim Chen wrote: return NULL; } + /* round up to full page size */ + size = (((size-1) PAGE_SHIFT) + 1) * PAGE_SIZE; This is quite suboptimal formula, we can do without shifts and multiplications (hopefully, still converted to shifts by gcc): size = (size + ~PAGE_MASK) PAGE_MASK; Agree. I've updated patch below Thanks. Tim ---8--- From: Tim Chen tim.c.c...@linux.intel.com Subject: [PATCH] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages returned Commit d92ef66c4f8f (x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled) changed the dma_alloc_coherent page clearance from using an __GFP_ZERO in page allocation to not setting the flag but doing an explicit memory clear at the end. However the memory clear only covered the memory size that was requested, but may not be up to the full extent of the last page, if the total pages returned exceed the memory size requested. This behavior has caused problem with XHCI and caused it to hang: kernel: xhci_hcd :00:14.0: Stopped the command ring failed, maybe the host is dead kernel: xhci_hcd :00:14.0: Abort command ring failed kernel: xhci_hcd :00:14.0: HC died; cleaning up kernel: xhci_hcd :00:14.0: Error while assigning device slot ID kernel: xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 64. Other drivers may have similar issue if it assumes that the pages allocated are completely zeroed. This patch ensures that the pages returned are fully cleared. Signed-off-by: Tim Chen tim.c.c...@linux.intel.com Cc: sta...@vger.kernel.org # 3.16+ --- arch/x86/kernel/pci-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index a25e202..e9d8dee 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -125,6 +125,8 @@ again: return NULL; } + /* round up to full page size */ + size = (size + ~PAGE_MASK) PAGE_MASK; Hi, is this an open-coded version of PAGE_ALIGN? memset(page_address(page), 0, size); *dma_addr = addr; return page_address(page); -- js 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
[PATCH V7 RESEND 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds
The host controller by itself may sometimes need to handle PHY
and re-initialize it to re-configure some of the PHY parameters
to get full support out of the PHY controller.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/xhci-plat.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..c478627 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/phy/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
@@ -127,10 +128,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+ hcd-phy = devm_phy_get(pdev-dev, usb2-phy);
+ if (IS_ERR(hcd-phy)) {
+ ret = PTR_ERR(hcd-phy);
+ if (ret == -EPROBE_DEFER) {
+ goto disable_clk;
+ } else if (ret != -ENOSYS ret != -ENODEV) {
+ hcd-phy = NULL;
+ dev_warn(pdev-dev,
+Error retrieving usb2 phy: %d\n, ret);
+ }
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
+ /*
+* Initialize and power-on USB 2.0 PHY
+* FIXME: Isn't this a hacky way of initializing the PHY again ?
+* xhci's parent would have already initialized the PHY, but we
+* wanna do it again.
+*/
+ hcd-phy-init_count = 0;
+ ret = phy_init(hcd-phy);
+ if (ret)
+ goto dealloc_usb2_hcd;
+
+ hcd-phy-power_count = 0;
+ ret = phy_power_on(hcd-phy);
+ if (ret) {
+ phy_exit(hcd-phy);
+ goto dealloc_usb2_hcd;
+ }
+
device_wakeup_enable(hcd-self.controller);
/* USB 2.0 roothub is stored in the platform_device now. */
@@ -156,12 +188,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci-hcc_params) = 4)
xhci-shared_hcd-can_do_streams = 1;
+ /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+ xhci-shared_hcd-phy = devm_phy_get(pdev-dev, usb3-phy);
+ if (IS_ERR(xhci-shared_hcd-phy)) {
+ ret = PTR_ERR(xhci-shared_hcd-phy);
+ if (ret == -EPROBE_DEFER) {
+ goto put_usb3_hcd;
+ } else if (ret != -ENOSYS ret != -ENODEV) {
+ xhci-shared_hcd-phy = NULL;
+ dev_warn(pdev-dev,
+Error retrieving usb3 phy: %d\n, ret);
+ }
+ }
+
ret = usb_add_hcd(xhci-shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
+ /* Initialize and power-on USB 3.0 PHY */
+ xhci-shared_hcd-phy-init_count = 0;
+ ret = phy_init(xhci-shared_hcd-phy);
+ if (ret)
+ goto dealloc_usb3_hcd;
+
+ xhci-shared_hcd-phy-power_count = 0;
+ ret = phy_power_on(xhci-shared_hcd-phy);
+ if (ret) {
+ phy_exit(xhci-shared_hcd-phy);
+ goto dealloc_usb3_hcd;
+ }
+
return 0;
+dealloc_usb3_hcd:
+ usb_remove_hcd(xhci-shared_hcd);
+
put_usb3_hcd:
usb_put_hcd(xhci-shared_hcd);
@@ -184,9 +245,15 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci-clk;
+ phy_power_off(xhci-shared_hcd-phy);
+ phy_exit(xhci-shared_hcd-phy);
+
usb_remove_hcd(xhci-shared_hcd);
usb_put_hcd(xhci-shared_hcd);
+ phy_power_off(hcd-phy);
+ phy_exit(hcd-phy);
+
usb_remove_hcd(hcd);
if (!IS_ERR(clk))
clk_disable_unprepare(clk);
@@ -202,6 +269,8 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ phy_exit(hcd-phy);
+
/*
* xhci_suspend() needs `do_wakeup` to know whether host is allowed
* to do wakeup during suspend. Since xhci_plat_suspend is currently
@@ -217,6 +286,11 @@ static int xhci_plat_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int ret;
+
+ ret = phy_init(hcd-phy);
+ if (ret)
+ return ret;
return xhci_resume(xhci, 0);
}
--
1.7.10.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
[PATCH V7 RESEND 0/2] Fine tune USB 3.0 PHY on exynos5420
This series is tested on usb-next with Heikki's patch [1]: base: platform: name the device already during allocation Changes since v6: - Dropped the changes for adding additional phy_calibrate() callback. - Added phy_init() and phy_power_on() sequence in xhci-plat driver; NOTE: both phy_init() and phy_power_on() will now require PHY's 'init_count' and 'power_count' to be reset to '0' so that we can actually re-initialize the phy. Though this has already been pointed out in discussion for the previous patch-series. [2] - Refactored return codes and error handling in cr_port functions as pointed out by Felipe. Changes since v5: - Assigned NULL to hcd-gen_phy in error path in xhci-plat.c, so that we don't need to check for IS_ERR() while calibrating the PHYs in core/hcd.c - Removed extra empty lines in register definitions in exynos5-usbdrd phy driver. - Added write access for EXYNOS5_DRD_PHYREG0 register before any crport_handshake() call as suggested by Jingoo Han. - Renamed member 'calibrate' to 'phy_exynos_calibrate' of struct exynos5_usbdrd_phy_drvdata. Changes since v4: - Rebased on latest patches by Heikki. - Took care of handling -EPROBE_DEFER error number while getting PHY in xhci plat. Changes from v3: - Modified error message as per review comments from Julius. Changes since v2: - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy, in order to make it more generic. - Moved the phy_calibration calls to core/hcd.c to enable a more generic solution for issues of calibrating the PHYs. Changes since v1: - Using 'gen_phy' member of 'hcd' instead of declaring more variables to hold phys. - Added a check for compatible match for 'Synopsys-dwc3' controller, since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that, instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs (main hcd and shared hcd). - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()' to use hcd-gen_phy directly. Also added the check for Synopsys's DWC3 controller while trying to calibrate the PHY. Explanation for the need of this patch-series: The DWC3-exynos eXtensible host controller present on Exynos5420/5800 SoCs is quirky. The PHY serving this controller operates at High-Speed by default, so it detects even Super-speed devices as high-speed ones. Certain PHY parameters like Tx LOS levels and Boost levels need to be calibrated further post initialization of xHCI controller, to get SuperSpeed operations working. [1] https://lkml.org/lkml/2014/11/19/367 [2] https://lkml.org/lkml/2014/9/2/170; (to be specific https://lkml.org/lkml/2014/9/10/132) Vivek Gautam (2): usb: host: xhci-plat: Get PHYs for xhci's hcds phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800 drivers/phy/phy-exynos5-usbdrd.c | 219 +++--- drivers/usb/host/xhci-plat.c | 74 + 2 files changed, 277 insertions(+), 16 deletions(-) -- 1.7.10.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
You have exceeded the storage limit on your mailbox.
You have exceeded the storage limit on your mailbox. You will not be able to send or receive new mail until you upgrade your email quota. Copy the below link and fill the form to upgrade your account. https://edu-ma.formstack.com/forms/edu_form System Administrator 192.168.0.1? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: gadget: OS desc type unicode multi
Hi Mario,
W dniu 01.02.2015 o 21:07, Mario Schuknecht pisze:
A popular proprietary operating system expects that USB devices provide extra
information via OS descriptors. An introduction to the subject can be found
here:
snip
This patch adds support for property data type 0x7 multiple NUL-terminated
unicode strings.
This suggests that you mean
#define USB_EXT_PROP_UNICODE_MULTI 7
Add case USB_EXT_PROP_UNICODE_MULTI in function fill_ext_prop()
And you do.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
Changes in v2:
- improve commit log
drivers/usb/gadget/composite.c | 5 +
drivers/usb/gadget/u_os_desc.h | 28
2 files changed, 33 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6178353..bf30b73 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1422,6 +1422,11 @@ static int fill_ext_prop(struct usb_configuration *c,
int interface, u8 *buf)
ext_prop-data,
ext_prop-data_len);
break;
+ case USB_EXT_PROP_UNICODE_LINK_MULTI:
Does it compile? I mean the _LINK_ infix - didn't you mean
+ case USB_EXT_PROP_UNICODE_MULTI:
instead?
+ usb_ext_prop_put_unicode_multi(buf, ret,
+ext_prop-data,
+ext_prop-data_len);
+ break;
case USB_EXT_PROP_BINARY:
usb_ext_prop_put_binary(buf, ret,
ext_prop-data,
diff --git a/drivers/usb/gadget/u_os_desc.h b/drivers/usb/gadget/u_os_desc.h
index 947b7dd..bee4274 100644
--- a/drivers/usb/gadget/u_os_desc.h
+++ b/drivers/usb/gadget/u_os_desc.h
@@ -120,4 +120,32 @@ static inline int usb_ext_prop_put_unicode(u8 *buf, int
pnl, const char *string,
return data_len;
}
I'm not sure I understand the logic of the below function well.
+static inline int usb_ext_prop_put_unicode_multi(u8 *buf, int pnl,
+ const char *string, int data_len)
+{
+ int outlen = 0;
+
+ put_unaligned_le32(data_len, usb_ext_prop_data_len_ptr(buf, pnl));
+
+ while (*string outlen data_len - 2) {
You keep looping as long as the source *string is not '\0'
and advance the string in each loop by adding (strlen() + 1) of
what is currently available starting at *string.
For example:
string: a\0b\0and this is past the end of your source buffer
first loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: b\0and this is past the end of your source
buffer */
second loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: and this is past the end of your source buffer
*/
so effectively the first part of the while condition rarely ever becomes
false.
In other words when you process all the source strings from string you, by
design,
end up one byte past the terminating '\0' of the source buffer. The contents
of this memory can be anything, there is just 1/256 chance it is zero,
so the while (*string part does not make sense to me.
+ int len = strlen(string);
+ int result = utf8s_to_utf16s(string, len, UTF16_LITTLE_ENDIAN,
+ (wchar_t *) usb_ext_prop_data_ptr(buf, pnl + outlen),
+ data_len - outlen - 2);
+ if (result 0)
+ return result;
+ outlen += result 1;
+ string += len + 1;
+ put_unaligned_le16(0,
+ buf[USB_EXT_PROP_B_PROPERTY_DATA + pnl + outlen]);
You put a terminating NUL two-byte after each destination, wide string.
+ outlen += 2;
Then you advance the outlen to reflect the above.
+ }
Suppose there is just one string in the source string, so the loop
terminates now.
Am I correct that at this point outlen is supposed to be equal data_len?
If it is, than please see below (*).
+
+ put_unaligned_le16(0,
+ buf[USB_EXT_PROP_B_PROPERTY_DATA + pnl + outlen]);
Why again terminate the destination string? And, since outlen value was
incremented by 2 in the meantime there will be two terminators in a row?
+ outlen += 2;
(*)
If outlen was supposed to be equal data_len above then the
return value of the whole function becomes data_len + 2.
+
+ return outlen;
+}
+
#endif /* __U_OS_DESC_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
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
On 02/02/2015 07:01 PM, Roger Quadros wrote: On 02/02/15 11:55, Chanwoo Choi wrote: Hi Roger, On 02/02/2015 06:09 PM, Roger Quadros wrote: Chanwoo, On 02/02/15 07:04, Chanwoo Choi wrote: Hi Roger, On 01/30/2015 11:05 PM, Roger Quadros wrote: Hi, On 30/01/15 13:04, Roger Quadros wrote: Felipe Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is USB-Host and not USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of USB-HOST to USB-Host. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. Hold on. Let's first decide what we really want to go ahead with USB-Host or USB-HOST. Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST) without any standard way. So, I have plan to define common cable name in extcon header file by using capital letter. OK. In that case, this patch is not required. I will resend patch 1 with cable name corrected to USB-HOST. If you possbile, I want to use 'USB-HOST' cable name in drivers related to extcon. If we use different cable name, this cause the confusion to control cable. Kernel tree shows following users of USB-Host that will have to be changed to USB-HOST. You're right. I'll modify all cable name of 'USB-HOST'. Also, I have plan to use only capital letter for cable name. extcon-class.c: [EXTCON_USB_HOST] = USB-Host, extcon-max77693.c:[EXTCON_CABLE_USB_HOST] = USB-Host, extcon-max77693.c:extcon_set_cable_state(info-edev, USB-Host, attached); extcon-max8997.c: [EXTCON_CABLE_USB_HOST] = USB-Host, extcon-max8997.c: extcon_set_cable_state(info-edev, USB-Host, attached); extcon-rt8973a.c: [EXTCON_CABLE_USB_HOST] = USB-Host, extcon-sm5502.c: [EXTCON_CABLE_USB_HOST] = USB-Host, I'm not aware if any user space programs depend on this name. Do you know of any? As I knew, released samsung smart-phone used the cable name to detect the cable state becaues extcon send the uevent with both cable name and cable state. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe 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/1] extcon: usb-gpio: Introduce gpio usb extcon driver
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-HOST (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
- changed host cable name to USB-HOST
- use 'depends on' instead of 'select' GPIOLIB
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 237 +
4 files changed, 263 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = linux,extcon-usb-gpio;
+ id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+ }
+
+ omap_dwc3_1 {
+ extcon = extcon_usb1;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..e4c01ab 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate USB GPIO extcon support
+ depends on GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..3f0bad3
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,237 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * 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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/extcon.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/workqueue.h
+
+#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
+
+struct usb_extcon_info {
+ struct device *dev;
+ struct extcon_dev *edev;
+
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = USB,
+ [EXTCON_CABLE_USB_HOST] = USB-HOST,
+ NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+ int id;
+ struct usb_extcon_info *info = container_of(to_delayed_work(work),
+ struct usb_extcon_info,
+ wq_detcable);
+
+ /* check ID and update cable state */
+ id = gpiod_get_value_cansleep(info-id_gpiod);
+ if (id) {
+
Re: net2280 driver and gadgetfs?
Hello Carolyn I have tried using g_mass_storage and g_network, but I cannot see why it should not work with gadgetfs. What is exactly the issue? It does not build? it does not behave as expected? I am putting the linux-usb mailing list on cc Regards! On Sat, Jan 31, 2015 at 12:06 AM, Smith, Carolyn J carolyn.j.sm...@tektronix.com wrote: Hello Ricardo, I am working on a board with the PLX3380 chip on it. Thank you very much for your work on integrating support for this chip into the Linux net2280 driver. Have you used the driver successfully with the gadgetfs filesystem at all? Or do you know of anyone who has? I'm not having any luck getting the gadgetfs example at www.linux-usb.org/gadget/usb.c working properly with it. Thank you for any help or suggestions you can provide, Carolyn Smith Tektronix, Inc. -- Ricardo Ribalda -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv5 6/7] base: platform: name the device already during allocation
Hi Kishon,
On Thu, Nov 20, 2014 at 2:51 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi Greg,
On Wednesday 19 November 2014 08:58 PM, Heikki Krogerus wrote:
The device name is usually required when assigning resources
like clocks to platform devices. The problem is that the
device name is not know before platform_device_add is called
and that can be too late as the drivers may have already
requested the resources when the function returns. By naming
the device already in platform_device_alloc, the resources
can be assigned before platform_device_add is called.
This change allows different kinds of probe drivers to pass
forward their resources to the actual driver. The first
place where we need it is dwc3 controllers host glue code
(drivers/usb/dwc3/host.c) to pass the phy's to xhci.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Are you fine with this change? Can it come via linux-phy tree?
Thanks
Kishon
I think this patch missed getting into 3.19 or 20 now.
Is there some other tree where it got pulled in, coz i can't see it in
linux-next also ?
---
drivers/base/platform.c | 69
+
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index cdb6c07..d2217f3 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -195,11 +195,41 @@ void platform_device_put(struct platform_device *pdev)
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name,
pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+ * Automatically allocated device ID. We mark it as such so
+ * that we remember it must be freed, and we append a suffix
+ * to avoid namespace collision with explicit IDs.
+ */
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
+ if (pa-pdev.id_auto)
+ ida_simple_remove(platform_devid_ida, pa-pdev.id);
+
of_device_node_put(pa-pdev.dev);
kfree(pa-pdev.dev.platform_data);
kfree(pa-pdev.mfd_cell);
@@ -228,6 +258,10 @@ struct platform_device *platform_device_alloc(const
char *name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -308,28 +342,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
- * Automatically allocated device ID. We mark it as such so
- * that we remember it must be freed, and we append a suffix
- * to avoid namespace collision with explicit IDs.
- */
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -372,7 +384,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -392,11 +403,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
Hello Pali, W dniu 31.01.2015 o 10:53, Pali Rohár pisze: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. For a hint please see this thread: http://www.spinics.net/lists/linux-usb/msg119669.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] staging: emxx_udc: fix the build error
Fix below build error:
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9239d88fc5e58a2a72bc949362f999aac9bffb29
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings:
In file included from include/linux/seqlock.h:35:0,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/staging/emxx_udc/emxx_udc.c:22:
drivers/staging/emxx_udc/emxx_udc.c: In function
'nbu2ss_gad_set_selfpowered':
drivers/staging/emxx_udc/emxx_udc.c:3129:21: error: 'udc' undeclared (first
use in this function)
spin_lock_irqsave(udc-lock, flags);
^
include/linux/spinlock.h:215:34: note: in definition of macro
'raw_spin_lock_irqsave'
flags = _raw_spin_lock_irqsave(lock); \
^
drivers/staging/emxx_udc/emxx_udc.c:3129:2: note: in expansion of macro
'spin_lock_irqsave'
spin_lock_irqsave(udc-lock, flags);
^
drivers/staging/emxx_udc/emxx_udc.c:3129:21: note: each undeclared
identifier is reported only once for each function it appears in
spin_lock_irqsave(udc-lock, flags);
^
include/linux/spinlock.h:215:34: note: in definition of macro
'raw_spin_lock_irqsave'
flags = _raw_spin_lock_irqsave(lock); \
^
drivers/staging/emxx_udc/emxx_udc.c:3129:2: note: in expansion of macro
'spin_lock_irqsave'
spin_lock_irqsave(udc-lock, flags);
^
vim +/udc +3129 drivers/staging/emxx_udc/emxx_udc.c
33aa8d45 Magnus Damm 2014-06-06 3123
33aa8d45 Magnus Damm 2014-06-06 3124 if (pgadget == NULL) {
33aa8d45 Magnus Damm 2014-06-06 3125 ERR(%s, bad param\n,
__func__);
33aa8d45 Magnus Damm 2014-06-06 3126 return -EINVAL;
33aa8d45 Magnus Damm 2014-06-06 3127 }
33aa8d45 Magnus Damm 2014-06-06 3128
33aa8d45 Magnus Damm 2014-06-06 @3129 spin_lock_irqsave(udc-lock, flags);
9239d88f Peter Chen 2015-01-28 3130 pgadget-is_selfpowered =
(is_selfpowered != 0);
33aa8d45 Magnus Damm 2014-06-06 3131 spin_unlock_irqrestore(udc-lock,
flags);
33aa8d45 Magnus Damm 2014-06-06 3132
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/staging/emxx_udc/emxx_udc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 1d3135a..bd70ea0 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3117,6 +3117,7 @@ static int nbu2ss_gad_wakeup(struct usb_gadget *pgadget)
static int nbu2ss_gad_set_selfpowered(struct usb_gadget *pgadget,
int is_selfpowered)
{
+ struct nbu2ss_udc *udc;
unsigned long flags;
/* INFO(=== %s()\n, __func__); */
@@ -3126,6 +3127,8 @@ static int nbu2ss_gad_set_selfpowered(struct usb_gadget
*pgadget,
return -EINVAL;
}
+ udc = container_of(pgadget, struct nbu2ss_udc, gadget);
+
spin_lock_irqsave(udc-lock, flags);
pgadget-is_selfpowered = (is_selfpowered != 0);
spin_unlock_irqrestore(udc-lock, flags);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] usb: udc: Unify dp control
On Thu, Jan 29, 2015 at 12:27:23PM +0800, Peter Chen wrote: Hi Felipe, Hi Felipe, I see you tree is closed, but below three patches are not in your tree, will you queue them now or at next rc? I have some other patches based on them, so I would like to know your ideas, thanks. Peter This is the follow-up: http://marc.info/?l=linux-usbm=140979297227434w=2. Sorry for late. In the first patch, we introduce an internal APIs which are used to find corresponding udc according to usb_gadget, it can simplify the code structure. In the 2nd patch, it maintains flag 'vbus' as vbus status, and try to connect or disconnect gadget according to vbus status. In the 3rd patch, it maintains count 'deactivations' for connect or disconnect gadget according to function/user behavior. If you agree with handing dp like above way, I will have two patchset, one for udc driver for 'vbus' and another for function driver for 'deactivations'. Thank you. Changes for v5(all for patch [3/3]): - Add mutux_lock to protect deactivation count - Add warning if deactivation is 0, but the user still wants to activate - Add more comments in commit log and code Changes for v4: - Add Alan's Ack Changes for v3: - Add mutex_lock protect for list_del(udc-list) at usb_del_gadget_udc [Patch 1/3] - Drop former [Patch 2/4] which is useless Changes for v2: - introduce two internal APIs to simplify the code structure. - Teach patch 3/4 and 4/4 to use the new introduced API. Peter Chen (3): usb: udc: add usb_gadget_find_udc usb: udc: add usb_udc_vbus_handler usb: udc: add usb_udc_activation_handler drivers/usb/gadget/udc/udc-core.c | 118 +- include/linux/usb/gadget.h| 9 +++ 2 files changed, 101 insertions(+), 26 deletions(-) -- 1.9.1 -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Mon, 2 Feb 2015, Peter Chen wrote: Let's look v2 patch, it bypasses probe at ehci-pci.c, then why ehci_pci_init is still needed to call? The chipidea driver has already done the same thing in ehci_pci_init. You're right; ehci_pci_init isn't needed. But there's no way to eliminate it and still have a universal kernel build. Does the pci id can pass from platform code/table? I don't understand the question. How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return -ENODEV immediately. 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
usb dwc2 too much sof in host mode
Thanks to Yousaf, the latest dwc2 code from latest testing/next works
well for both gadget and host.
When remove the usb, it will switch to host mode by default.
However, at this time, I found too much sof generating in our
platform, if no device attached.
1, usb gadget,
2, remove usb,
3, cat /proc/interrupt, then too much usb interrupt generated quickly.
Same phenomenon if setting usb host to low speed and attach usb disk
or keyboard.
1, usb gadget,
2, remove usb,
3. attach usb keyboard
4, cat /proc/interrupt, then too much usb interrupt generated quickly.
usb_hcd_submit_urb
{
if (is_root_hub(urb-dev)) {
status = rh_urb_enqueue(hcd, urb);
} else {
status = hcd-driver-urb_enqueue(hcd, urb, mem_flags);
}
}
dwc2_hcd_qh_add
{
if (!hsotg-periodic_qh_count) {
intr_mask = readl(hsotg-regs + GINTMSK);
intr_mask |= GINTSTS_SOF;
writel(intr_mask, hsotg-regs + GINTMSK);
}
}
When usb is removed, urb-dev-parent will be generated after
usb 1-1: new full-speed USB device number 2 using dwc2
Then the next USB_ENDPOINT_XFER_INT will set GINTSTS_SOF, and will
cause sof since then.
I am wandering is it expected behavior or abnormal behavior, the sof
interrupt is generated too quickly.
Besides, the dwc2 controller is 2.93a, 0xf72c0040 = 0x4F54300A
Thanks
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH linux-next] usb: gadget: Kconfig: use bool instead of boolean
Keyword 'boolean' for type definition attributes is considered deprecated and, therefore, should not be used anymore. See http://lkml.kernel.org/r/cover.1418003065.git...@linux.com See http://lkml.kernel.org/r/1419108071-11607-1-git-send-email...@linux.com Signed-off-by: Christoph Jaeger c...@linux.com --- drivers/usb/gadget/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 3320d58..b454d05 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -424,7 +424,7 @@ config USB_CONFIGFS_F_HID For more information, see Documentation/usb/gadget_hid.txt. config USB_CONFIGFS_F_UVC - boolean USB Webcam function + bool USB Webcam function depends on USB_CONFIGFS depends on VIDEO_DEV select VIDEOBUF2_VMALLOC -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hi guys. I finally was able to obtain some informations about what was going on - infos I retained useful. I am re-sending these, since it seems my previous message didn't get to the list - but might be I am wrong and didn't find it. This time I posted all the traces to a pstebin, so that it's easier to read the message and might be there are less problems with it in general. 1 - First trace: there where no problems http://cxg.de/_298ad9.htm 2 - Trace immediately before the crash http://cxg.de/_c43356.htm 3 - lspci: http://cxg.de/_4f202a.htm 4 - lsusb: http://cxg.de/_223f6c.htm Any help / hint would be very apreciated. I am not subscribed to the list, so please keep me in CC. Thank you, Enrico -- To unsubscribe from this list: send the line unsubscribe 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: net2280 driver and gadgetfs?
Hi,
2015-02-03 0:25 GMT+01:00 Smith, Carolyn J carolyn.j.sm...@tektronix.com:
Hello Ricardo,
It does build and I have verified that it works fine with g_mass_storage and
g_zero.
However it does not seem to work with gadgetfs. Here are the kernel messages
I get when I load udc-core.ko, net2280.ko and gadgetfs.ko and then
mkdir /dev/gadget
mount -t gadgetfs none /dev/gadget
[ 96.023408] net2280 :04:00.0: usb_reset_338x: Defect 7374 FsmValue
0xf000
[ 96.023436] net2280 :04:00.0: usb_reinit_338x: Defect 7374 FsmValue
f000
[ 96.023508] net2280 :04:00.0: irq 52 for MSI/MSI-X
[ 96.023587] net2280 :04:00.0: PLX NET228x/USB338x USB Peripheral
Controller
[ 96.023593] net2280 :04:00.0: irq 52, pci mem c90004e84000, chip
rev 00ab
[ 96.023597] net2280 :04:00.0: version: 2005 Sept 27/v3.0; dma enabled
enhanced mode
[ 96.023601] usb_add_gadget_udc_release
[ 96.030691] gadgetfs: USB Gadget filesystem, version 24 Aug 2004
[ 96.034381] udc :04:00.0: registering UDC driver [(null)]
At that point gadgetfs is mounted and there is a 0 length /dev/gadget/net2280
file.
If I then run the gadgetfs example program (www.linux-usb.org/gadget/usb.c) I
get the following kernel messages
[ 109.846832] udc :04:00.0: registering UDC driver [USB Gadget
filesystem]
[ 109.846865] gadgetfs: bound to net2280 driver
[ 109.846868] usb_gadget_udc_start
[ 109.846876] net2280 :04:00.0: Operate Defect 7374 workaround soft this
time
[ 109.846880] net2280 :04:00.0: It will operate on cold-reboot and SS
connect
[ 109.846975] net2280 :04:00.0: ep0_start_338x: Defect 7374 FsmValue
1000
At that point, there are the 0 length /dev/gadget/net2280 file as well as 0
length /dev/gadget/ep-a through /dev/gadget/ep-h files representing the
endpoints.
Then if I connect the gadget to a USB host, the example program terminates
because it gets a -EINVAL return from the read function call in ep0_thread.
There are the following kernel messages.
[ 917.671457] gadgetfs: connected
[ 917.671634] usb_gadget_remove_driver
[ 917.671647] gadgetfs :04:00.0: unregistering UDC driver [net2280]
[ 917.671693] gadgetfs: disconnected
[ 917.671732] usb_gadget_udc_stop
[ 917.671743] net2280 :04:00.0: usb_reset_338x: Defect 7374 FsmValue
0x2000
[ 917.671788] net2280 :04:00.0: usb_reinit_338x: Defect 7374 FsmValue
2000
Any ideas would be gratefully received.
Thank you,
Carolyn
-Original Message-
From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com]
Sent: Monday, February 02, 2015 1:47 AM
To: Smith, Carolyn J; Linux USB Mailing List
Subject: Re: net2280 driver and gadgetfs?
Hello Carolyn
I have tried using g_mass_storage and g_network, but I cannot see why it
should not work with gadgetfs.
What is exactly the issue? It does not build? it does not behave as expected?
I am putting the linux-usb mailing list on cc
Regards!
On Sat, Jan 31, 2015 at 12:06 AM, Smith, Carolyn J
carolyn.j.sm...@tektronix.com wrote:
Hello Ricardo,
I am working on a board with the PLX3380 chip on it. Thank you very
much for your work on integrating support for this chip into the Linux
net2280 driver.
Have you used the driver successfully with the gadgetfs filesystem at all?
Or do you know of anyone who has? I'm not having any luck getting the
gadgetfs example at www.linux-usb.org/gadget/usb.c working properly with it.
Thank you for any help or suggestions you can provide,
Carolyn Smith
Tektronix, Inc.
--
Ricardo Ribalda
I used gadgetfs with PLX3380 controler. I had the problem that was
reported here:
http://thread.gmane.org/gmane.linux.usb.general/116872/focus=117488
Perphaps this is also your problem. The commit that caused the error
is probably this:
commit 7f7f25e82d54870df24d415a7007fbd327da027b
Author: Al Viro v...@zeniv.linux.org.uk
Date: Tue Feb 11 17:49:24 2014 -0500
replace checking for -read/-aio_read presence with check in -f_mode
Since we are about to introduce new methods (read_iter/write_iter), the
tests in a bunch of places would have to grow inconveniently. Check
once (at open() time) and store results in -f_mode as FMODE_CAN_READ
and FMODE_CAN_WRITE resp. It might end up being a temporary measure -
once everything switches from -aio_{read,write} to -{read,write}_iter
it might make sense to return to open-coded checks. We'll see...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
If a driver register a read function, it is remembered in a flag in
the open function.
--- a/fs/open.c
+++ b/fs/open.c
@@ -725,6 +725,10 @@ static int do_dentry_open(struct file *f,
}
if ((f-f_mode (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
i_readcount_inc(inode);
+ if ((f-f_mode FMODE_READ) likely(f-f_op-read ||
f-f_op-aio_read))
+ f-f_mode |= FMODE_CAN_READ;
Re: PD: [Bug 92341] xHCI USB driver, support for non-conformant HS USB devices with bulk endpoints of maxpacket size different than 512
On Mon, 2 Feb 2015, Matthieu CASTET wrote: Le Mon, 2 Feb 2015 15:39:47 +0200, Mathias Nyman mathias.ny...@linux.intel.com a �crit : So apparently there were some devices that started working after the 512byte was forced? I wasn't involved in this at the time so I don't know the details, perhaps Alan remembers? As the patch says, USB2 specs say HS bulk endpoints only supports 512 bytes max packet size. USB2 spec section 5.8.3 Bulk Transfer Packet Size Constraints: All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum packet sizes for full-speed bulk endpoints and 512 bytes for high-speed bulk endpoints. No Host Controller is required to support larger or smaller maximum packet sizes. Or maybe that can be interpreted as 8-, 16-, 32-, 64, AND 512 bytes supported for HS bulk endpoints? I don't think so, but I agree the spec could have been more clear about this. I'm otherwise ok with adding the other max packet sizes as well, just worried about the original patch. Are we going to break something that the original patch once fixed -Mathias If ehci driver allows to support others sizes, there may have some devices that use it for HS. There are some examples. In all the cases I know about, the bogus maxpacket size doesn't matter because the device never sends or receives a message on that endpoint requiring more than one packet. Do you know if the windows driver allows this ? Looking from ehci driver [1] it seems to be the case. Instead of forbid value smaller than 512, can we have a list of controllers that can't handle it and make it works on others ? That's not a bad idea. If we can create such a list somehow... Does windows xhci driver allow value different of 512 for HS ? Kazimierz says that the driver in Windows 7 does not allow it. So perhaps it doesn't matter much what we do in Linux. Regarding the e4f47e3675e6 commit ( USB: xHCI: override bogus bulk wMaxPacketSize values), it's hard to say exactly what happened. The patch allowed a device to work, but the device had its bulk maxpacket values set to 8! I don't know if the device's descriptors were simply wrong, or if the user's xHCI controller was unable to handle a maxpacket size different from 512. However, if we change the driver now, that user's device is likely to stop working, which would be a regression. On the whole, I think the best approach is to redesign Kazimierz's device. Changing the endpoints in question from bulk to interrupt could help, for example. Unless he wants to continue producing devices that won't work under Windows 7... 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] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages returned
Hello. On 02/02/2015 05:02 PM, Jiri Slaby wrote: From: Tim Chen tim.c.c...@linux.intel.com Subject: [PATCH] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages returned Commit d92ef66c4f8f (x86: make dma_alloc_coherent() return zeroed memory if CMA is enabled) changed the dma_alloc_coherent page clearance from using an __GFP_ZERO in page allocation to not setting the flag but doing an explicit memory clear at the end. However the memory clear only covered the memory size that was requested, but may not be up to the full extent of the last page, if the total pages returned exceed the memory size requested. This behavior has caused problem with XHCI and caused it to hang: kernel: xhci_hcd :00:14.0: Stopped the command ring failed, maybe the host is dead kernel: xhci_hcd :00:14.0: Abort command ring failed kernel: xhci_hcd :00:14.0: HC died; cleaning up kernel: xhci_hcd :00:14.0: Error while assigning device slot ID kernel: xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 64. Other drivers may have similar issue if it assumes that the pages allocated are completely zeroed. This patch ensures that the pages returned are fully cleared. Signed-off-by: Tim Chen tim.c.c...@linux.intel.com Cc: sta...@vger.kernel.org # 3.16+ --- arch/x86/kernel/pci-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index a25e202..e9d8dee 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -125,6 +125,8 @@ again: return NULL; } + /* round up to full page size */ + size = (size + ~PAGE_MASK) PAGE_MASK; Hi, is this an open-coded version of PAGE_ALIGN? Yes, it appears so. :-) 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: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
Hi, On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. So it does not export anything by default and thus allows to use MyDocs partition as before... Signed-off-by: Pali Rohár pali.ro...@gmail.com thanks, but no thanks. Build your own using configfs. -- balbi signature.asc Description: Digital signature
Re: Kernel Ooops upon USB disconnect of a Western Digital My Passport 1TB drive
On Mon, 2 Feb 2015, Athlion wrote: Hello again, I tried setting up netconsole (I don't have a null-modem serial cable with usb adaptor) and although it *does* capture some of the dump, it does not capture everything. The dump is from 3.18.5. Here goes (from the USB connection): [ 169.827703] usb 2-1.2: new high-speed USB device number 3 using ehci-pci [ 169.980222] usb-storage 2-1.2:1.0: USB Mass Storage device detected [ 169.982264] scsi host6: usb-storage 2-1.2:1.0 [ 169.984548] usbcore: registered new interface driver usb-storage [ 169.989296] usbcore: registered new interface driver uas [ 170.989458] scsi 6:0:0:0: Direct-Access WD My Passport 0748 1016 PQ: 0 ANSI: 6 [ 170.992673] scsi 6:0:0:1: Enclosure WD SES Device 1016 PQ: 0 ANSI: 6 [ 171.002766] sd 6:0:0:0: [sdb] Spinning up disk... [ 172.009278] .ready [ 173.012719] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB) [ 173.016434] sd 6:0:0:0: [sdb] Write Protect is off [ 173.017780] ses 6:0:0:1: Attached Enclosure device [ 173.021519] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08 [ 173.024736] sd 6:0:0:0: [sdb] No Caching mode page found [ 173.026785] sd 6:0:0:0: [sdb] Assuming drive cache: write through [ 173.040339] sdb: sdb1 [ 173.045652] sd 6:0:0:0: [sdb] Attached SCSI disk [ 183.706124] usb 2-1.2: USB disconnect, device number 3 [ 183.725921] BUG: unable to handle kernel NULL pointer dereference at 01a0 [ 183.728560] IP: [812850d5] blk_post_runtime_resume+0x65/0x80 [ 183.730820] PGD 0 [ 183.733038] Oops: 0002 [#1] PREEMPT SMP [ 183.735285] Modules linked in: ses enclosure uas usb_storage netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant ... i2c_algo_bit video drm_kms_helper drm i2c_core There should have been a stack dump here, but there wasn't. Too bad; it would have been helpful. Is there anything I can do to make netconsole dump everything? Not as far as I know. But it might help if we saw the USB debugging messages. Try turning on dynamic debugging for usbcore and scsi_mod before running the test by doing: echo 'module usbcore =p' /sys/kernel/debug/dynamic_debug/control echo 'module scsi_mod =p' /sys/kernel/debug/dynamic_debug/control Had you made any changes to the runtime suspend settings? blk_post_runtime_resume wouldn't be called unless the drive had gone into runtime suspend. And even then, it's not likely to be called after you unplug the USB cable. 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] usb: gadget: nokia: Add mass storage driver to g_nokia
On Monday 02 February 2015 19:54:58 Felipe Balbi wrote: Hi, On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. So it does not export anything by default and thus allows to use MyDocs partition as before... Signed-off-by: Pali Rohár pali.ro...@gmail.com thanks, but no thanks. Build your own using configfs. But it needs some userspace interaction right? Then its not possible for nfsboot. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
Hi, On Mon, Feb 02, 2015 at 07:58:59PM +0100, Pali Rohár wrote: On Monday 02 February 2015 19:54:58 Felipe Balbi wrote: Hi, On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. So it does not export anything by default and thus allows to use MyDocs partition as before... Signed-off-by: Pali Rohár pali.ro...@gmail.com thanks, but no thanks. Build your own using configfs. But it needs some userspace interaction right? Then its not possible for nfsboot. oh, right... you're using nfsboot through g_nokia. Hmm, sounds like you need initramfs. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
On Monday 02 February 2015 20:01:11 Felipe Balbi wrote: Hi, On Mon, Feb 02, 2015 at 07:58:59PM +0100, Pali Rohár wrote: On Monday 02 February 2015 19:54:58 Felipe Balbi wrote: Hi, On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. So it does not export anything by default and thus allows to use MyDocs partition as before... Signed-off-by: Pali Rohár pali.ro...@gmail.com thanks, but no thanks. Build your own using configfs. But it needs some userspace interaction right? Then its not possible for nfsboot. oh, right... you're using nfsboot through g_nokia. Hmm, sounds like you need initramfs. Also compiling usb gadgets as external .ko modules is broken. So I cannot use configfs, when I compile g_nokia even if I use initramfs... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
On Mon, Feb 02, 2015 at 08:07:51PM +0100, Pali Rohár wrote: On Monday 02 February 2015 20:01:11 Felipe Balbi wrote: Hi, On Mon, Feb 02, 2015 at 07:58:59PM +0100, Pali Rohár wrote: On Monday 02 February 2015 19:54:58 Felipe Balbi wrote: Hi, On Sat, Jan 31, 2015 at 10:53:30AM +0100, Pali Rohár wrote: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. So it does not export anything by default and thus allows to use MyDocs partition as before... Signed-off-by: Pali Rohár pali.ro...@gmail.com thanks, but no thanks. Build your own using configfs. But it needs some userspace interaction right? Then its not possible for nfsboot. oh, right... you're using nfsboot through g_nokia. Hmm, sounds like you need initramfs. Also compiling usb gadgets as external .ko modules is broken. So I cannot use configfs, when I compile g_nokia even if I use initramfs... yeah, there are people working on that and some patches already flying around for it. Meanwhile, you can make it built-in and use initramfs to add mass_storage through configfs to g_nokia, no issues. -- balbi signature.asc Description: Digital signature
[ANNOUNCE] tree closed for v3.20
Hi folks, My tree is now closed for v3.20, I'm testing the result with platforms I have access to and should be able to send a pull request before Friday. Thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
Chanwoo, On 02/02/15 07:04, Chanwoo Choi wrote: Hi Roger, On 01/30/2015 11:05 PM, Roger Quadros wrote: Hi, On 30/01/15 13:04, Roger Quadros wrote: Felipe Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is USB-Host and not USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of USB-HOST to USB-Host. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. Hold on. Let's first decide what we really want to go ahead with USB-Host or USB-HOST. Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST) without any standard way. So, I have plan to define common cable name in extcon header file by using capital letter. OK. In that case, this patch is not required. I will resend patch 1 with cable name corrected to USB-HOST. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HP EC372S (Yuan DVB ExpressCard) crash in 3.18.3
Hi, I posted a bug on kernel.org (https://bugzilla.kernel.org/show_bug.cgi?id=92301 ) and was asked to sent it to this mail-address. Jan 29 21:26:51 plattpcn kernel: [ 17.322493] input: UVC Camera (05ca:1812) as /devices/pci:00/:00:1d.7/usb2/2-4/2-4:1.0/input/input10 Jan 29 21:26:51 plattpcn kernel: [ 17.322621] usbcore: registered new interface driver uvcvideo Jan 29 21:26:51 plattpcn kernel: [ 17.322623] USB Video Class driver (1.1.1) Jan 29 21:26:51 plattpcn kernel: [ 17.583002] input: HP WMI hotkeys as /devices/virtual/input/input11 Jan 29 21:26:51 plattpcn kernel: [ 18.108106] iwl4965 :02:00.0: loaded firmware version 228.61.2.24 Jan 29 21:26:51 plattpcn kernel: [ 18.360154] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs' Jan 29 21:26:51 plattpcn kernel: [ 18.620404] dvb-usb: found a 'Yuan EC372S' in cold state, will try to load a firmware Jan 29 21:26:51 plattpcn kernel: [ 18.993039] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Jan 29 21:26:51 plattpcn kernel: [ 19.194634] dib0700: firmware started successfully. Jan 29 21:26:51 plattpcn kernel: [ 19.695174] dvb-usb: found a 'Yuan EC372S' in warm state. Jan 29 21:26:51 plattpcn kernel: [ 19.695448] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jan 29 21:26:51 plattpcn kernel: [ 19.695527] DVB: registering new adapter (Yuan EC372S) Jan 29 21:26:51 plattpcn kernel: [ 20.090809] BUG: unable to handle kernel NULL pointer dereference at 0080 Jan 29 21:26:51 plattpcn kernel: [ 20.090987] IP: [a057b061] dib7000p_attach+0x11/0xa0 [dib7000p] Jan 29 21:26:51 plattpcn kernel: [ 20.091007] PGD 36893067 PUD b95b0067 PMD 0 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Oops: 0002 [#1] SMP Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Modules linked in: dib7000p(E) dvb_usb_dib0700(E+) dib7000m(E) arc4(E) dib0090(E) dib0070(E) dib3000mc(E) dibx000_common(E) dvb_usb(E) dvb_core(E) coretemp(E) hp_wmi(E) rc_core(E) sparse_keymap(E) uvcvideo(E) iwl4965(E) videobuf2_vmalloc(E) snd_hda_codec_si3054(E) kvm(E) iwlegacy(E) snd_hda_codec_realtek(E) videobuf2_memops(E) mac80211(E) videobuf2_core(E) snd_hda_codec_generic(E) v4l2_common(E) videodev(E) snd_hda_intel(E) joydev(E) snd_hda_controller(E) serio_raw(E) snd_hda_codec(E) snd_hwdep(E) r852(E) cfg80211(E) snd_pcm(E) sm_common(E) btusb(E) nand(E) snd_seq_midi(E) nand_ecc(E) snd_seq_midi_event(E) bluetooth(E) snd_rawmidi(E) nand_bch(E) snd_seq(E) bch(E) r592(E) snd_seq_device(E) nand_ids(E) snd_timer(E) mtd(E) memstick(E) drm(E) snd(E) soundcore(E) lpc_ich(E) wmi(E) video(E) mac_hid(E) parport_pc(E) ppdev(E) lp(E) parport(E) psmouse(E) ahci(E) libahci(E) firewire_ohci(E) firewire_core(E) sdhci_pci(E) crc_itu_t(E) sdhci(E) r8169(E) mii(E) Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CPU: 0 PID: 442 Comm: systemd-udevd Tainted: GE 3.18.3jonas #1 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Hardware name: Hewlett-Packard HP Pavilion dv9700 Notebook PC/30CB, BIOS F.59 11/25/2008 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] task: 8800b8f68000 ti: 8800b9148000 task.ti: 8800b9148000 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RIP: 0010:[a057b061] [a057b061] dib7000p_attach+0x11/0xa0 [dib7000p] Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RSP: 0018:8800b914ba88 EFLAGS: 00010202 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RAX: 0010 RBX: 8800ba9d1278 RCX: a0581040 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RDX: a0581040 RSI: a0581c2b RDI: 0010 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] RBP: 8800b914ba88 R08: 810e47a0 R09: 0001802a0029 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] R10: ea0002ed9fc0 R11: 8107cf84 R12: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] R13: 0010 R14: 8800ba9d1278 R15: 8800ba9d1398 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] FS: 7fd441492880() GS:88013fc0() knlGS: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CS: 0010 DS: ES: CR0: 8005003b Jan 29 21:26:51 plattpcn kernel: [ 20.091007] CR2: 0080 CR3: 36892000 CR4: 07f0 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Stack: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800b914bab8 a055adab 8800ba9d1278 8800ba9d1278 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800ba9d1278 8800b914baf8 a04776b8 Jan 29 21:26:51 plattpcn kernel: [ 20.091007] 8800ba9d 8800ba9d1278 8800ba9d Jan 29 21:26:51 plattpcn kernel: [ 20.091007] Call Trace: Jan 29 21:26:51 plattpcn kernel: [ 20.091007] [a055adab] stk7700P2_frontend_attach+0x3b/0x1f0 [dvb_usb_dib0700] Jan 29 21:26:51 plattpcn kernel: [
