Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc
Linus ? On Wed, Jan 28, 2015 at 07:54:44PM +0100, Robert Jarzmik wrote: Felipe Balbi ba...@ti.com writes: nop-gpiod_reset = devm_gpiod_get_optional(dev, reset); if (gpiod_is_active_low(nop-gpiod_reset)) gpiod_direction_output(nop-gpiod_reset, GPIOD_OUT_LOW); else gpiod_direction_output(nop-gpiod_reset, GPIOD_OUT_HIGH); won't the descriptor itself handle that for us ? Linus ? I want to hear from Linus W first. Yes, so do I. Let's add a bit of context for Linus : 1) In the past, the driver was doing a ; gpio_request_one() - gpiod_direction_output_raw() 2) After the conversion to gpio descriptors, it is doing : gpiod_get_optional(dev, reset); - ... - __gpiod_get_index(dev, reset, 0, 0) - this of course doesn't call gpiod_direction() The problem is that we cannot call: gpiod_get_optional(dev, reset, GPIOD_OUT_LOW); because we don't know before the call if the GPIO is active high or low. The former gpio_request_one() was clever and did a gpio_direction_output_raw(.., (flags GPIOF_INIT_HIGH) ? 1 : 0). So what is the right way out ? : - is it to call gpiod_direction_output(nop-gpiod, 0) just after gpiod_get_optional() in probe code ? - is it when the gpio is used to call gpiod_direction_output(gpiod, x) instead of gpiod_set_value() ? - is it something else ? Cheers. -- Robert -- balbi signature.asc Description: Digital signature
Re: usb-storage URB use-after-free
On Wed, 28 Jan 2015, Joe Lawrence wrote:
This one should have gone over to linux-usb.
-- Joe
On 01/28/2015 05:04 PM, Joe Lawrence wrote:
Hello linux-usb,
We've hit a USB use-after-free on Stratus HW during device removal tests.
We're running fio disk I/O to a scsi disk hanging off USB when the USB
controller is hotplug removed. This crash is very consistent (usually the
first device pull during testing). Without I/O, it may take days to
encounter.
general protection fault: [#1] SMP
...
CPU: 35 PID: 19626 Comm: kworker/u97:0 Tainted: PF W O--
3.10.0-210.el7.dev02.x86_64 #1
Hardware name: Stratus ftServer 6800/G7LYY, BIOS BIOS Version 8.0:30
11/12/2014
Workqueue: scsi_tmf_872 scmd_eh_abort_handler
task: 88031bd91960 ti: 880981318000 task.ti: 880981318000
RIP: 0010:[812d5e2d] [812d5e2d] kobject_put+0xd/0x60
RSP: 0018:88098131bd28 EFLAGS: 00010002
RAX: RBX: 6b6b6b6b6b6b6c0b RCX: 0001002f0009
RDX: 002f RSI: ea0015719800 RDI: 6b6b6b6b6b6b6c0b
RBP: 88098131bd30 R08: 88055c6622f0 R09: 0001002f0008
R10: 88085f407a80 R11: 81450503 R12: 8804bab6d248
R13: ff98 R14: 0086 R15: 0c20
FS: () GS:88085fce() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f2ebb5d6008 CR3: 001038dc5000 CR4: 001407e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Stack:
88098131bd40 813cd327 88098131bd50
8140a65a 88098131bd78 81416795
880414791968 880414791978 88098131bd88 814175f6
Call Trace:
[813cd327] put_device+0x17/0x20
[8140a65a] usb_put_dev+0x1a/0x20
[81416795] usb_hcd_unlink_urb+0x65/0xe0
[814175f6] usb_unlink_urb+0x26/0x50
[81418e92] usb_sg_cancel+0x82/0xe0
[a0074e71] usb_stor_stop_transport+0x31/0x50 [usb_storage]
[a0073b8d] command_abort+0xcd/0xe0 [usb_storage]
[813f51ef] scmd_eh_abort_handler+0xbf/0x480
[8108f06b] process_one_work+0x17b/0x470
[8108fe4b] worker_thread+0x11b/0x400
[8108fd30] ? rescuer_thread+0x400/0x400
[8109722f] kthread+0xcf/0xe0
[81097160] ? kthread_create_on_node+0x140/0x140
[8161387c] ret_from_fork+0x7c/0xb0
[81097160] ? kthread_create_on_node+0x140/0x140
from another crash, we know that the URB itself has been freed:
but the underlying usb_device-device is still present:
It looks like usb_hcd_unlink_urb takes a reference out on the underlying
device but not the URB, which in our test case consistently gets freed
just before usb_hcd_unlink_urb tries to return a reference on urb-device.
The analysis looks correct.
Maybe the URB is a reference count short when usb_hcd_unlink_urb calls
unlink1? Somewhere usb-storage missed taking out a ref?
No; it's a simple use-after-free error.
A tourniquet hack-patch follows (probably inside out, as the URB should stay
intact while usb_hcd_unlink_urb does its thing) and has been running a
little over 30 surprise device removals under I/O without incident.
Any better suggestions?
Please try this instead.
Alan Stern
Index: usb-3.19/drivers/usb/core/hcd.c
===
--- usb-3.19.orig/drivers/usb/core/hcd.c
+++ usb-3.19/drivers/usb/core/hcd.c
@@ -1618,6 +1618,7 @@ static int unlink1(struct usb_hcd *hcd,
int usb_hcd_unlink_urb (struct urb *urb, int status)
{
struct usb_hcd *hcd;
+ struct usb_device *udev = urb-dev;
int retval = -EIDRM;
unsigned long flags;
@@ -1629,20 +1630,19 @@ int usb_hcd_unlink_urb (struct urb *urb,
spin_lock_irqsave(hcd_urb_unlink_lock, flags);
if (atomic_read(urb-use_count) 0) {
retval = 0;
- usb_get_dev(urb-dev);
+ usb_get_dev(udev);
}
spin_unlock_irqrestore(hcd_urb_unlink_lock, flags);
if (retval == 0) {
hcd = bus_to_hcd(urb-dev-bus);
retval = unlink1(hcd, urb, status);
- usb_put_dev(urb-dev);
+ if (retval == 0)
+ retval = -EINPROGRESS;
+ else if (retval != -EIDRM retval != -EBUSY)
+ dev_dbg(udev-dev, hcd_unlink_urb %p fail %d\n,
+ urb, retval);
+ usb_put_dev(udev);
}
-
- if (retval == 0)
- retval = -EINPROGRESS;
- else if (retval != -EIDRM retval != -EBUSY)
- dev_dbg(urb-dev-dev, hcd_unlink_urb %p fail %d\n,
-
[PATCH] USB: usbfs: allow URBs to be reaped after disconnection
The usbfs API has a peculiar hole: Users are not allowed to reap their
URBs after the device has been disconnected. There doesn't seem to be
any good reason for this; it is an ad-hoc inconsistency.
The patch allows users to issue the USBDEVFS_REAPURB and
USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts
on 64-bit systems) even after the device is gone. If no URBs are
pending for a disconnected device then the ioctls will return -ENODEV
rather than -EAGAIN, because obviously no new URBs will ever be able
to complete.
The patch also adds a new capability flag for
USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect
feature is supported.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Chris Dickens christopher.a.dick...@gmail.com
---
[as1773]
drivers/usb/core/devio.c | 63 ++
include/uapi/linux/usbdevice_fs.h |3 +
2 files changed, 39 insertions(+), 27 deletions(-)
Index: usb-3.19/include/uapi/linux/usbdevice_fs.h
===
--- usb-3.19.orig/include/uapi/linux/usbdevice_fs.h
+++ usb-3.19/include/uapi/linux/usbdevice_fs.h
@@ -128,11 +128,12 @@ struct usbdevfs_hub_portinfo {
char port [127];/* e.g. port 3 connects to device 27 */
};
-/* Device capability flags */
+/* System and bus capability flags */
#define USBDEVFS_CAP_ZERO_PACKET 0x01
#define USBDEVFS_CAP_BULK_CONTINUATION 0x02
#define USBDEVFS_CAP_NO_PACKET_SIZE_LIM0x04
#define USBDEVFS_CAP_BULK_SCATTER_GATHER 0x08
+#define USBDEVFS_CAP_REAP_AFTER_DISCONNECT 0x10
/* USBDEVFS_DISCONNECT_CLAIM flags struct */
Index: usb-3.19/drivers/usb/core/devio.c
===
--- usb-3.19.orig/drivers/usb/core/devio.c
+++ usb-3.19/drivers/usb/core/devio.c
@@ -1689,7 +1689,7 @@ static struct async *reap_as(struct usb_
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
as = async_getcompleted(ps);
- if (as)
+ if (as || !connected(ps))
break;
if (signal_pending(current))
break;
@@ -1712,7 +1712,7 @@ static int proc_reapurb(struct usb_dev_s
}
if (signal_pending(current))
return -EINTR;
- return -EIO;
+ return -ENODEV;
}
static int proc_reapurbnonblock(struct usb_dev_state *ps, void __user *arg)
@@ -1721,10 +1721,11 @@ static int proc_reapurbnonblock(struct u
struct async *as;
as = async_getcompleted(ps);
- retval = -EAGAIN;
if (as) {
retval = processcompl(as, (void __user * __user *)arg);
free_async(as);
+ } else {
+ retval = (connected(ps) ? -EAGAIN : -ENODEV);
}
return retval;
}
@@ -1854,7 +1855,7 @@ static int proc_reapurb_compat(struct us
}
if (signal_pending(current))
return -EINTR;
- return -EIO;
+ return -ENODEV;
}
static int proc_reapurbnonblock_compat(struct usb_dev_state *ps, void __user
*arg)
@@ -1862,11 +1863,12 @@ static int proc_reapurbnonblock_compat(s
int retval;
struct async *as;
- retval = -EAGAIN;
as = async_getcompleted(ps);
if (as) {
retval = processcompl_compat(as, (void __user * __user *)arg);
free_async(as);
+ } else {
+ retval = (connected(ps) ? -EAGAIN : -ENODEV);
}
return retval;
}
@@ -2038,7 +2040,8 @@ static int proc_get_capabilities(struct
{
__u32 caps;
- caps = USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM;
+ caps = USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM |
+ USBDEVFS_CAP_REAP_AFTER_DISCONNECT;
if (!ps-dev-bus-no_stop_on_short)
caps |= USBDEVFS_CAP_BULK_CONTINUATION;
if (ps-dev-bus-sg_tablesize)
@@ -2138,6 +2141,32 @@ static long usbdev_do_ioctl(struct file
return -EPERM;
usb_lock_device(dev);
+
+ /* Reap operations are allowed even after disconnection */
+ switch (cmd) {
+ case USBDEVFS_REAPURB:
+ snoop(dev-dev, %s: REAPURB\n, __func__);
+ ret = proc_reapurb(ps, p);
+ goto done;
+
+ case USBDEVFS_REAPURBNDELAY:
+ snoop(dev-dev, %s: REAPURBNDELAY\n, __func__);
+ ret = proc_reapurbnonblock(ps, p);
+ goto done;
+
+#ifdef CONFIG_COMPAT
+ case USBDEVFS_REAPURB32:
+ snoop(dev-dev, %s: REAPURB32\n, __func__);
+ ret = proc_reapurb_compat(ps, p);
+ goto done;
+
+ case USBDEVFS_REAPURBNDELAY32:
+ snoop(dev-dev, %s: REAPURBNDELAY32\n, __func__);
+ ret = proc_reapurbnonblock_compat(ps, p);
+
Re: XHCI, brain-dead scanner, and microframe rounding
On 27.01.2015 14:12, Gunter Königsmann wrote: That's very good news indeed. Will re-run the tests on my scanner and looking forward to the fix entering mainline. In the meantime I can acknowledge that with the fix my computer accepts USB memory sticks that normally didn't work. Kind regards, Gunter. Did some cleaning of the patch, and noticed it still had a few bits wrong, but apparently it worked anyway. I added the fixes on top of the ep_reset_halt_test branch. Can any of you with a failing scanner test that it still works? git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git and the ep_reset_halt_test branch, Thanks -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] USB: usbfs: allow URBs to be reaped after disconnection
On Thu, 2015-01-29 at 11:29 -0500, Alan Stern wrote: The usbfs API has a peculiar hole: Users are not allowed to reap their URBs after the device has been disconnected. There doesn't seem to be any good reason for this; it is an ad-hoc inconsistency. How many URBs can you queue this way? Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci_hcd: host died
On 27.01.2015 13:11, Heinz Diehl wrote: Hi, I'm not sure if this is the right place to report this, and would be glad if somebody could point me to the right one if I should be wrong. Anyway, since the main error message comes from xhci_hcd: When resuming from suspend to RAM, sometimes (= about every 4. or 5. suspend) my external USB3 harddisks filesystem (XFS) gets corrupted with I/O block errors. This is what dmesg says: [] [ 274.103912] nouveau [ CLK][:01:00.0] --: core 500 MHz shader 1250 MHz memory 333 MHz [ 274.104561] nouveau [ DRM] resuming client object trees... [ 274.104923] nouveau [ DRM] resuming display... [ 274.155454] nouveau [ DRM] resuming console... [ 274.156877] xhci_hcd :02:00.0: Host took too long to start, waited 16000 microseconds. [ 274.156896] xhci_hcd :02:00.0: PCI post-resume error -19! [ 274.156897] xhci_hcd :02:00.0: HC died; cleaning up Looks like xhci tries to re-initialize after resume, and fails to get it back running. It should only re-initializes in resume if it - was hibernated (S4) - xhci failed normal restore in resume - a special RESET_ON_RESUME quirk is set. Does resume work without the usb drive connected? Does resume work with older kernels? -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 v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
* Roger Quadros rog...@ti.com [150129 03:34]: On 28/01/15 19:09, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150128 04:15]: On 28/01/15 04:19, Chanwoo Choi wrote: I still fail to understand that we need to call disable_irq() in .suspend() and enable_irq() in .resume() can you point me to any other drivers doing so? You can refer the suspend function in drivers/mfd/max14577.c or drivers/mfd/max77693.c. The max14577_suspend() includes the detailed comment for why using disable_irq() in suspend function. In max14577 case, max14577_suspend() use disable_irq() function because of i2c dependency. If max14577 device is wake-up from suspend state before completing the resume sequence of i2c, max14577 may fail to read/write i2c communication. Thanks for this information. I will add disable/enable_irq() in suspend/resume(). Are the .dts changes safe for me to apply already? Yes Tony, you can pick them. Thanks. OK will apply the dts changes into omap-for-v3.20/dt thanks. I have also the defconfig changes tagged, will apply those a bit later probably as a fix after the driver is merged. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libusb] [PATCH] USB: usbfs: allow URBs to be reaped after disconnection
Hi,
On 29-01-15 17:29, Alan Stern wrote:
The usbfs API has a peculiar hole: Users are not allowed to reap their
URBs after the device has been disconnected. There doesn't seem to be
any good reason for this; it is an ad-hoc inconsistency.
The patch allows users to issue the USBDEVFS_REAPURB and
USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts
on 64-bit systems) even after the device is gone. If no URBs are
pending for a disconnected device then the ioctls will return -ENODEV
rather than -EAGAIN, because obviously no new URBs will ever be able
to complete.
The patch also adds a new capability flag for
USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect
feature is supported.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Chris Dickens christopher.a.dick...@gmail.com
Patch looks good and I agree that this is something which we want to fix:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
[as1773]
drivers/usb/core/devio.c | 63
++
include/uapi/linux/usbdevice_fs.h |3 +
2 files changed, 39 insertions(+), 27 deletions(-)
Index: usb-3.19/include/uapi/linux/usbdevice_fs.h
===
--- usb-3.19.orig/include/uapi/linux/usbdevice_fs.h
+++ usb-3.19/include/uapi/linux/usbdevice_fs.h
@@ -128,11 +128,12 @@ struct usbdevfs_hub_portinfo {
char port [127];/* e.g. port 3 connects to device 27 */
};
-/* Device capability flags */
+/* System and bus capability flags */
#define USBDEVFS_CAP_ZERO_PACKET 0x01
#define USBDEVFS_CAP_BULK_CONTINUATION0x02
#define USBDEVFS_CAP_NO_PACKET_SIZE_LIM 0x04
#define USBDEVFS_CAP_BULK_SCATTER_GATHER 0x08
+#define USBDEVFS_CAP_REAP_AFTER_DISCONNECT 0x10
/* USBDEVFS_DISCONNECT_CLAIM flags struct */
Index: usb-3.19/drivers/usb/core/devio.c
===
--- usb-3.19.orig/drivers/usb/core/devio.c
+++ usb-3.19/drivers/usb/core/devio.c
@@ -1689,7 +1689,7 @@ static struct async *reap_as(struct usb_
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
as = async_getcompleted(ps);
- if (as)
+ if (as || !connected(ps))
break;
if (signal_pending(current))
break;
@@ -1712,7 +1712,7 @@ static int proc_reapurb(struct usb_dev_s
}
if (signal_pending(current))
return -EINTR;
- return -EIO;
+ return -ENODEV;
}
static int proc_reapurbnonblock(struct usb_dev_state *ps, void __user *arg)
@@ -1721,10 +1721,11 @@ static int proc_reapurbnonblock(struct u
struct async *as;
as = async_getcompleted(ps);
- retval = -EAGAIN;
if (as) {
retval = processcompl(as, (void __user * __user *)arg);
free_async(as);
+ } else {
+ retval = (connected(ps) ? -EAGAIN : -ENODEV);
}
return retval;
}
@@ -1854,7 +1855,7 @@ static int proc_reapurb_compat(struct us
}
if (signal_pending(current))
return -EINTR;
- return -EIO;
+ return -ENODEV;
}
static int proc_reapurbnonblock_compat(struct usb_dev_state *ps, void __user
*arg)
@@ -1862,11 +1863,12 @@ static int proc_reapurbnonblock_compat(s
int retval;
struct async *as;
- retval = -EAGAIN;
as = async_getcompleted(ps);
if (as) {
retval = processcompl_compat(as, (void __user * __user *)arg);
free_async(as);
+ } else {
+ retval = (connected(ps) ? -EAGAIN : -ENODEV);
}
return retval;
}
@@ -2038,7 +2040,8 @@ static int proc_get_capabilities(struct
{
__u32 caps;
- caps = USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM;
+ caps = USBDEVFS_CAP_ZERO_PACKET | USBDEVFS_CAP_NO_PACKET_SIZE_LIM |
+ USBDEVFS_CAP_REAP_AFTER_DISCONNECT;
if (!ps-dev-bus-no_stop_on_short)
caps |= USBDEVFS_CAP_BULK_CONTINUATION;
if (ps-dev-bus-sg_tablesize)
@@ -2138,6 +2141,32 @@ static long usbdev_do_ioctl(struct file
return -EPERM;
usb_lock_device(dev);
+
+ /* Reap operations are allowed even after disconnection */
+ switch (cmd) {
+ case USBDEVFS_REAPURB:
+ snoop(dev-dev, %s: REAPURB\n, __func__);
+ ret = proc_reapurb(ps, p);
+ goto done;
+
+ case USBDEVFS_REAPURBNDELAY:
+ snoop(dev-dev, %s: REAPURBNDELAY\n, __func__);
+ ret = proc_reapurbnonblock(ps, p);
+ goto done;
+
+#ifdef CONFIG_COMPAT
+ case USBDEVFS_REAPURB32:
+ snoop(dev-dev, %s: REAPURB32\n, __func__);
+ ret = proc_reapurb_compat(ps, p);
+
difference in option.ko and sierra.ko Linux drivers
Can any one let me know the difference in option and sierra kernel modules ? looks like both drivers support GSM modem. And from the source code perspective both look similar. I am able to load sierra module for my Huawei USB dongle E156 and able to connect to internet using pppd. Is it OK to use sierra driver for Huawei in case there is no technical issue? If yes why there are two different modules? 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 v3 0/2] usb: pci: resolve conflict between ci_hdrc_pci and ehci-pci
The patch series introduces the bypass_pci_id_table in ehci-pci to skip a probe stage for certain devices. Changes since v2: - address Alex comments - append Alan's ACK Andy Shevchenko (2): ehci-pci: disable for Intel MID platforms chipidea: pci: add comment regarding to ehci-pci driver drivers/usb/chipidea/ci_hdrc_pci.c | 3 +++ drivers/usb/host/ehci-pci.c| 27 ++- 2 files changed, 29 insertions(+), 1 deletion(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] chipidea: pci: add comment regarding to ehci-pci driver
The patch points a developer of ChipIdea PCI driver to the bypass_pci_id_table
in ehci-pci driver. The table allows to skip a probe stage in ehci-pci for
certain IDs.
There is no functional change.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/chipidea/ci_hdrc_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c
b/drivers/usb/chipidea/ci_hdrc_pci.c
index f997eda..773d150 100644
--- a/drivers/usb/chipidea/ci_hdrc_pci.c
+++ b/drivers/usb/chipidea/ci_hdrc_pci.c
@@ -128,6 +128,9 @@ static void ci_hdrc_pci_remove(struct pci_dev *pdev)
* PCI device structure
*
* Check pci.h for details
+ *
+ * Note: ehci-pci driver may try to probe the device first. You have to add an
+ * ID to the bypass_pci_id_table in ehci-pci driver to prevent this.
*/
static const struct pci_device_id ci_hdrc_pci_id_table[] = {
{
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: renesas: fix extcon dependency
On Wed, Jan 28, 2015 at 10:47:18PM +0100, Arnd Bergmann wrote: The renesas usbhs driver calls extcon_get_edev_by_phandle(), which is defined in drivers/extcon/extcon-class.c, and that can be a loadable module. If the extcon-class support is disabled, usbhs will work correctly for all devices that do not need extcon. However, if extcon-class is a loadable module, and usbhs is built-in, the kernel fails to link. In order to solve that, we need a Kconfig dependency that allows extcon to be disabled but does not allow usbhs built-in if extcon is a module. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/usb/renesas_usbhs/Kconfig b/drivers/usb/renesas_usbhs/Kconfig index de83b9d0cd5c..0ea9040b9f10 100644 --- a/drivers/usb/renesas_usbhs/Kconfig +++ b/drivers/usb/renesas_usbhs/Kconfig @@ -6,6 +6,7 @@ config USB_RENESAS_USBHS tristate 'Renesas USBHS controller' depends on USB_GADGET depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST + depends on EXTCON || !EXTCON # for module build if extcon is The comment doesn't make much sense on its own (and when I read it before reading the above description, it was down right confusing.) Maybe a longer comment would be a good idea? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] usb: serial: implement CMSPAR for F81232
Hello. On 1/29/2015 5:01 AM, Peter Hung wrote: Hello. Please don't top-post. I had using scripts/checkpatch.pl -f to scan original f81232.c. It reported with quoted string split across lines, so I merge these 2 strings into 1 in patch 1/5. Seems like another unrelated change... But it still warning with line over 80 character, so I had shorted string with this line. Hm, the modern checkpatch.pl shouldn't warn about long lines due to string literals used in dev_err(), etc. calls. I will refine my patch set again with more attention. In any case, don't leave the warnings till some next patch, fix them at once. Thanks for your advice. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] ehci-pci: disable for Intel MID platforms
On some Intel MID platforms the ChipIdea USB controller is used. The EHCI PCI
is in conflict with the proper driver. The patch makes ehci-pci to be ignored
in favour of ChipIdea controller.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/host/ehci-pci.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 851006a..2a5d2fd 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -43,6 +43,24 @@ static inline bool is_intel_quark_x1000(struct pci_dev *pdev)
}
/*
+ * This is the list of PCI IDs for the devices that have EHCI USB class and
+ * specific drivers for that. One of the example is a ChipIdea device installed
+ * on some Intel MID platforms.
+ */
+static const struct pci_device_id bypass_pci_id_table[] = {
+ /* ChipIdea on Intel MID platform */
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
+ {}
+};
+
+static inline bool is_bypassed_id(struct pci_dev *pdev)
+{
+ return !!pci_match_id(bypass_pci_id_table, pdev);
+}
+
+/*
* 0x84 is the offset of in/out threshold register,
* and it is the same offset as the register of 'hostpc'.
*/
@@ -352,6 +370,13 @@ static const struct ehci_driver_overrides pci_overrides
__initconst = {
/*-*/
+static int ehci_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ if (is_bypassed_id(pdev))
+ return -ENODEV;
+ return usb_hcd_pci_probe(pdev, id);
+}
+
/* PCI driver selection metadata; PCI hotplugging uses this */
static const struct pci_device_id pci_ids [] = { {
/* handle any USB 2.0 EHCI controller */
@@ -370,7 +395,7 @@ static struct pci_driver ehci_pci_driver = {
.name = (char *) hcd_name,
.id_table = pci_ids,
- .probe =usb_hcd_pci_probe,
+ .probe =ehci_pci_probe,
.remove = usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] usb: serial: add register map for F81232
On Thu, Jan 29, 2015 at 10:37:34AM +0800, Peter Hung wrote: Hello. 1. For retry Issue: These patches is referenced from our other usb serial product. That product maybe not ack the control ep command when It's in very heavily loading. Our workaround is to modify driver to retry more times if it timeout because it's f/w can't upgrade with usb protocol. I will remove the retry mechanic and test for it again. That sounds good. 2. For some function/variable not used: The original driver is lacking a lot of feature. My first patch strategy is putting all needed function / variables in patch 1 and apply it in following patches. Sorry for my wrong strategy, I'll change it with more meaningful and logical patchset and resend it. Perhaps you just need to break the patches up further. Also if you get checkpatch warnings for code you haven't touched, you can either ignore them or fix it separately in preparatory patch. Just try to group related changes together. Thanks for your patient and advice. No worries. In the future when posting to the lists, please try to respond inline (as I am above) rather than top-post, and remove context that isn't relevant (e.g. code that isn't relevant) for the discussion at hand. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: host: pci_quirks: joing string literals
The patch joins the string literals for happy debugging. There is no functional
change.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/host/pci-quirks.c | 46 +++
1 file changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index ce63646..f940056 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -603,9 +603,9 @@ static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
msleep(10);
}
if (wait_time = 0)
- dev_warn(pdev-dev, OHCI: BIOS handoff failed
-(BIOS bug?) %08x\n,
- readl(base + OHCI_CONTROL));
+ dev_warn(pdev-dev,
+OHCI: BIOS handoff failed (BIOS bug?) %08x\n,
+readl(base + OHCI_CONTROL));
}
#endif
@@ -733,8 +733,9 @@ static void ehci_bios_handoff(struct pci_dev *pdev,
* and hope nothing goes too wrong
*/
if (try_handoff)
- dev_warn(pdev-dev, EHCI: BIOS handoff failed
- (BIOS bug?) %08x\n, cap);
+ dev_warn(pdev-dev,
+EHCI: BIOS handoff failed (BIOS bug?) %08x\n,
+cap);
pci_write_config_byte(pdev, offset + 2, 0);
}
@@ -781,8 +782,9 @@ static void quirk_usb_disable_ehci(struct pci_dev *pdev)
case 0: /* Illegal reserved cap, set cap=0 so we exit */
cap = 0; /* then fallthrough... */
default:
- dev_warn(pdev-dev, EHCI: unrecognized capability
-%02x\n, cap 0xff);
+ dev_warn(pdev-dev,
+EHCI: unrecognized capability %02x\n,
+cap 0xff);
}
offset = (cap 8) 0xff;
}
@@ -893,8 +895,7 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
*/
if (!IS_ENABLED(CONFIG_USB_XHCI_HCD)) {
dev_warn(xhci_pdev-dev,
- CONFIG_USB_XHCI_HCD is turned off,
- defaulting to EHCI.\n);
+CONFIG_USB_XHCI_HCD is turned off, defaulting to
EHCI.\n);
dev_warn(xhci_pdev-dev,
USB 3.0 devices will work at USB 2.0
speeds.\n);
usb_disable_xhci_ports(xhci_pdev);
@@ -919,8 +920,9 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
pci_read_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
ports_available);
- dev_dbg(xhci_pdev-dev, USB 3.0 ports that are now enabled
- under xHCI: 0x%x\n, ports_available);
+ dev_dbg(xhci_pdev-dev,
+ USB 3.0 ports that are now enabled under xHCI: 0x%x\n,
+ ports_available);
/* Read XUSB2PRM, xHCI USB 2.0 Port Routing Mask Register
* Indicate the USB 2.0 ports to be controlled by the xHCI host.
@@ -941,8 +943,9 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
pci_read_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
ports_available);
- dev_dbg(xhci_pdev-dev, USB 2.0 ports that are now switched over
- to xHCI: 0x%x\n, ports_available);
+ dev_dbg(xhci_pdev-dev,
+ USB 2.0 ports that are now switched over to xHCI: 0x%x\n,
+ ports_available);
}
EXPORT_SYMBOL_GPL(usb_enable_intel_xhci_ports);
@@ -1010,8 +1013,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
/* Assume a buggy BIOS and take HC ownership anyway */
if (timeout) {
- dev_warn(pdev-dev, xHCI BIOS handoff failed
-(BIOS bug ?) %08x\n, val);
+ dev_warn(pdev-dev,
+xHCI BIOS handoff failed (BIOS bug ?) %08x\n,
+val);
writel(val ~XHCI_HC_BIOS_OWNED, base +
ext_cap_offset);
}
}
@@ -1039,8 +1043,8 @@ hc_init:
if (timeout) {
val = readl(op_reg_base + XHCI_STS_OFFSET);
dev_warn(pdev-dev,
- xHCI HW not ready after 5 sec (HC bug?)
- status = 0x%x\n, val);
+xHCI HW not ready after 5 sec (HC bug?) status =
0x%x\n,
+val);
}
/* Send the halt and disable interrupts command */
@@ -1054,8 +1058,8 @@ hc_init:
if (timeout) {
val = readl(op_reg_base + XHCI_STS_OFFSET);
Re: [PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Chanwoo,
On 29/01/15 03:49, Chanwoo Choi wrote:
Hi Roger,
We need to discuss one point about 'id_irqwake'.
I don't recommend to use 'id_irqwake' field.
And I catch build warning by using select keywork in Kconfig.
It is my wrong guide of select keyword. So, I'll change it
as 'depends on' keyword.
Looks good to me except for 'id_irqwake'.
I'll apply this patch on 3.21 queue after completing this discussion.
On 01/28/2015 09:15 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
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 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..fd11536 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
+select GPIOLIB
I catch the build warning if using 'select' instead of 'depends on' as
following:
It is my wrong guide to you. So, I'll modify it by using depends on as your
original patch.
OK. Thanks.
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage -j 8
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/gpio/Kconfig:34:error: recursive dependency detected!
drivers/gpio/Kconfig:34: symbol GPIOLIB is selected by EXTCON_USB_GPIO
drivers/extcon/Kconfig:96:symbol EXTCON_USB_GPIO depends on EXTCON
drivers/extcon/Kconfig:1: symbol EXTCON is selected by CHARGER_MANAGER
drivers/power/Kconfig:316:symbol CHARGER_MANAGER depends on POWER_SUPPLY
drivers/power/Kconfig:1: symbol POWER_SUPPLY is selected by HID_SONY
drivers/hid/Kconfig:670: symbol HID_SONY depends on NEW_LEDS
drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by BCMA_DRIVER_GPIO
drivers/bcma/Kconfig:75: symbol BCMA_DRIVER_GPIO 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..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * 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.
+ *
+ *
Re: [PATCH 2/2] usb: renesas_usbhs: add support for requesting DT DMA
Hi Shimoda-san,
On Mon, Jan 19, 2015 at 12:53:17PM +0900, Yoshihiro Shimoda wrote:
This patch adds dma_request_slave_channel_reason() calling to request
dma slave channels for multiplatform environment.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
.../devicetree/bindings/usb/renesas_usbhs.txt |2 ++
drivers/usb/renesas_usbhs/fifo.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
I have observed what appears to be a regression caused by this
patch when booting a kernel built using shmobile_defconfig on the koelsch
and lager boards.
I noticed this problem while testing next-20150129.
I have provided boot logs at the end of this email.
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index b08c903..61b045b 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -14,6 +14,8 @@ Optional properties:
function should be enabled
- phys: phandle + phy specifier pair
- phy-names: must be usb
+ - dmas: Must contain a list of references to DMA specifiers.
+ - dma-names : Must contain a list of DMA names, tx or rx.
Example:
usbhs: usb@e659 {
diff --git a/drivers/usb/renesas_usbhs/fifo.c
b/drivers/usb/renesas_usbhs/fifo.c
index 48e31b9..4c086b1 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -1069,12 +1069,21 @@ static void usbhsf_dma_init_pdev(struct usbhs_fifo
*fifo)
fifo-rx_slave);
}
+static void usbhsf_dma_init_dt(struct device *dev, struct usbhs_fifo *fifo)
+{
+ fifo-tx_chan = dma_request_slave_channel_reason(dev, tx);
+ fifo-rx_chan = dma_request_slave_channel_reason(dev, rx);
+}
+
static void usbhsf_dma_init(struct usbhs_priv *priv,
struct usbhs_fifo *fifo)
{
struct device *dev = usbhs_priv_to_dev(priv);
- usbhsf_dma_init_pdev(fifo);
+ if (dev-of_node)
+ usbhsf_dma_init_dt(dev, fifo);
+ else
+ usbhsf_dma_init_pdev(fifo);
if (fifo-tx_chan || fifo-rx_chan)
dev_dbg(dev, enable DMAEngine (%s%s%s)\n,
Koelsch
---
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 3.19.0-rc5-00129-gabd2dbf
(ho...@ayumi.isobedori.kobe.vergenet.net) (gcc version 4.6.3 (GCC) ) #959 SMP
Thu Jan 29 20:40:07 JST 2015
CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5307d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine model: Koelsch
Ignoring memory block 0x2 - 0x24000
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c0612a80, node_mem_map eeff9000
Normal zone: 1520 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 194560 pages, LIFO batch:31
HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 7 pages/cpu @eefca000 s7552 r0 d21120 u32768
pcpu-alloc: s7552 r0 d21120 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624
Kernel command line: ignore_loglevel rw root=/dev/nfs ip=dhcp
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1032964K/1048576K available (4524K kernel code, 264K rwdata, 1128K
rodata, 268K init, 191K bss, 15612K reserved, 0K cma-reserved, 270336K highmem)
Virtual kernel memory layout:
vector : 0x - 0x1000 ( 4 kB)
fixmap : 0xffc0 - 0xfff0 (3072 kB)
vmalloc : 0xf000 - 0xff00 ( 240 MB)
lowmem : 0xc000 - 0xef80 ( 760 MB)
pkmap : 0xbfe0 - 0xc000 ( 2 MB)
.text : 0xc0008000 - 0xc058e024 (5657 kB)
.init : 0xc058f000 - 0xc05d2000 ( 268 kB)
.data : 0xc05d2000 - 0xc06143a0 ( 265 kB)
.bss : 0xc06143a0 - 0xc064407c ( 192 kB)
Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
Architected cp15 timer(s) running at 10.00MHz (virt).
sched_clock: 56 bits at 10MHz, resolution 100ns, wraps every 3435973836800ns
Switching to timer-based delay loop, resolution 100ns
Console: colour dummy device 80x30
console [tty0] enabled
Calibrating delay loop (skipped), value calculated using timer frequency..
20.00 BogoMIPS (lpj=10)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
On 28/01/15 19:09, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150128 04:15]: On 28/01/15 04:19, Chanwoo Choi wrote: I still fail to understand that we need to call disable_irq() in .suspend() and enable_irq() in .resume() can you point me to any other drivers doing so? You can refer the suspend function in drivers/mfd/max14577.c or drivers/mfd/max77693.c. The max14577_suspend() includes the detailed comment for why using disable_irq() in suspend function. In max14577 case, max14577_suspend() use disable_irq() function because of i2c dependency. If max14577 device is wake-up from suspend state before completing the resume sequence of i2c, max14577 may fail to read/write i2c communication. Thanks for this information. I will add disable/enable_irq() in suspend/resume(). Are the .dts changes safe for me to apply already? Yes Tony, you can pick them. Thanks. 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: [PATCH_V3 1/3] dt: usb: jz4740: Add DT binding document for OHCI
On Wednesday 28 January 2015 13:26:03 Zubair Lutfullah Kakakhel wrote: + - clocks: Should contain a single clock specifier for the SoC UHC clock. + - clock-names: Must be uhc Same comment as for the watchdog binding, this should probably be removed. See what the other ohci drivers use and pick the most common clock name if you must have one. Arnd -- To unsubscribe from this list: send the line unsubscribe 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 Heikki, Felipe, On Thu, Jan 29, 2015 at 10:20:23AM -0600, Felipe Balbi wrote: Hi On Thu, Jan 29, 2015 at 04:14:12PM +0200, Heikki Krogerus wrote: Can you share how tusb1210 is connected on the platform you're using as test for this patch? I don't think this driver would work reliably with this device: http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html The only reason why that board doesn't work is because of very much Baytrail-CR specific problems. These are are two issues, but the first That's not BYT-CR specific problems. That's just dwc3 and tusb1210 interacting as they're expecting to. one is critical for getting it working. Both will be handled, but separately from this set: 1) The firmware leaves the PHY in reset, forcing us to enable it somehow in OS before accessing ulpi. Unless we can get a firmware fix for that (it's starting to look like it's not going to happen; please correct me if you know something else!), we need to add a quirk for Baytrails (attached), which is probable still OK. But IMO this really should be fixed in the firmware. It seems you're expecting the PHY to be fully operational in order to probe it. That's wrong assumption. BYT-CR's BIOS is doing nothing wrong by leaving PHY on reset state. But it is. If we want to use ULPI as a bus like we do, then the PHY will be no different then devices attached to many other buses. We have made firmware fixes like that before. All the devices need to be in a state, operational enough after bootup, so we can probe them in OS without the need for hacks where they are separately enabled before it's possible. That makes no sense. Not only dwc3 and phy could live as modules (which means they may probe far away from device's boot time) but we have examples of buses not behaving like you said. E.g. I2C needs master to be probed to have bus working and no BIOS needs to make I2C controller functional in order to probe its controller's driver. 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 ? The real problem is what I stated above. With your current logic, you'll get stuck with checking/egg problem: you need phy probed to probe dwc3, but need dwc3 probed to power on phy. You need a logic to break this circular dependency. The moment we register the ulpi interface with the ulpi bus in dwc3_probe(), we know dwc3 has it's PHY interface in operational mode and register access to ULPI PHY is possible. And that is all dwc3 needs to/can do. I don't think you are seeing the whole ulpi bus in these patches, but in any case; Like I said, this problem is purely BYT-CR specific, which IMO really should be fixed in the firmware. The proposed design has a flaw that breaks products on market simply because they don't have BIOS (unnecessarily) powering on phy. You're labeling that as BYT-CR specific issue because BYT-CR needs to be PM efficient and then it won't power on hw components in moment they don't need to. FW developers won't like this suggestion and I'd have to agree with them. 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 :/ one comment below on this. 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 ? Let's propose this non-BYT-CR scenario: You have dwc3/phy powered on by BIOS and dwc3 + phy as modules. You probe the modules for the first time and it works because phy was accessible. Then we remove the modules and load it again.
Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY
On Thu, Jan 29, 2015 at 10:04:16AM -0800, David Cohen wrote: On Thu, Jan 29, 2015 at 10:20:49AM -0600, Felipe Balbi wrote: On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote: Also, I was chatting in private with David and, apparently, there's a way to request for eye diagram data from BIOS straight. That's more in-line with what we would do for DT-based boots, passing that eye-diagram data as a DT attribute. Care to comment ? If that's the case, I'd rather use that BIOS hook and remove ulpi_read() from probe(). I'm not familiar with such method. But if there is one, I'm not against it. I need to check it. David ? Care to comment ? I agree with Heikki's proposal to use BIOS hook and remove ulpi_read() from probe(). That address one of my chicken/egg concerns. Oops. I misinterpreted the thread. Heikki didn't propose that :) Let me get things mature and reply to here. Br, David Br, David -- balbi -- To unsubscribe from this list: send the line unsubscribe 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: usbfs: allow URBs to be reaped after disconnection
On Thu, 29 Jan 2015, Oliver Neukum wrote: On Thu, 2015-01-29 at 11:29 -0500, Alan Stern wrote: The usbfs API has a peculiar hole: Users are not allowed to reap their URBs after the device has been disconnected. There doesn't seem to be any good reason for this; it is an ad-hoc inconsistency. How many URBs can you queue this way? I don't understand the question. Are you asking how many URBs can be queued via usbfs? It's limited only by the restriction on the total memory usage (see usbfs_memory_mb in devio.c). Of course, after a device has disconnected, you can't queue any URBs for it. 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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
On Thu, Jan 29, 2015 at 10:20:49AM -0600, Felipe Balbi wrote: On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote: Also, I was chatting in private with David and, apparently, there's a way to request for eye diagram data from BIOS straight. That's more in-line with what we would do for DT-based boots, passing that eye-diagram data as a DT attribute. Care to comment ? If that's the case, I'd rather use that BIOS hook and remove ulpi_read() from probe(). I'm not familiar with such method. But if there is one, I'm not against it. I need to check it. David ? Care to comment ? I agree with Heikki's proposal to use BIOS hook and remove ulpi_read() from probe(). That address one of my chicken/egg concerns. Br, David -- balbi -- To unsubscribe from this list: send the line unsubscribe 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: xhci_hcd: host died
On 29.01.2015, Mathias Nyman wrote: [ 274.156877] xhci_hcd :02:00.0: Host took too long to start, waited 16000 microseconds. [ 274.156896] xhci_hcd :02:00.0: PCI post-resume error -19! [ 274.156897] xhci_hcd :02:00.0: HC died; cleaning up Does resume work without the usb drive connected? Does resume work with older kernels? Yes on both questions. The problem was not that the machine didn't resume, but the data corruption occuring when going S1/S3. I resolved the problem about 30 min. ago by updating the controllers firmware. Have checked by suspending 20 times, and the error didn't come back. Wasn't aware that such small controller cards have firmware which is user-updateable (and that they are obviously sold without any serious quality control). For those who care or are encountering the same/similar problems, I got the firmware from this place: http://www.station-drivers.com/index.php/downloads/Drivers/Renesas-Nec/USB-3.0/ Release 2.0.2.4 fixed my problem. Had to find a guy with a Wind*ws machine who allowed me to insert my card into his machine to be able to flash it. Booting Windows PE and similar didn't work out. Thanks Mathias for your time and interest! -- To unsubscribe from this list: send the line unsubscribe 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
Can you share how tusb1210 is connected on the platform you're using as test for this patch? I don't think this driver would work reliably with this device: http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html The only reason why that board doesn't work is because of very much Baytrail-CR specific problems. These are are two issues, but the first That's not BYT-CR specific problems. That's just dwc3 and tusb1210 interacting as they're expecting to. one is critical for getting it working. Both will be handled, but separately from this set: 1) The firmware leaves the PHY in reset, forcing us to enable it somehow in OS before accessing ulpi. Unless we can get a firmware fix for that (it's starting to look like it's not going to happen; please correct me if you know something else!), we need to add a quirk for Baytrails (attached), which is probable still OK. But IMO this really should be fixed in the firmware. It seems you're expecting the PHY to be fully operational in order to probe it. That's wrong assumption. BYT-CR's BIOS is doing nothing wrong by leaving PHY on reset state. But it is. If we want to use ULPI as a bus like we do, then the PHY will be no different then devices attached to many other buses. We have made firmware fixes like that before. All the devices need to be in a state, operational enough after bootup, so we can probe them in OS without the need for hacks where they are separately enabled before it's possible. That makes no sense. Not only dwc3 and phy could live as modules (which means they may probe far away from device's boot time) but we have examples of buses not behaving like you said. E.g. I2C needs master to be probed to have bus working and no BIOS needs to make I2C controller functional in order to probe its controller's driver. You can't really compare a bus like i2c, which can't enumerate devices natively, to ULPI which can. The real problem is what I stated above. With your current logic, you'll get stuck with checking/egg problem: you need phy probed to probe dwc3, but need dwc3 probed to power on phy. You need a logic to break this circular dependency. The moment we register the ulpi interface with the ulpi bus in dwc3_probe(), we know dwc3 has it's PHY interface in operational mode and register access to ULPI PHY is possible. And that is all dwc3 needs to/can do. I don't think you are seeing the whole ulpi bus in these patches, but in any case; Like I said, this problem is purely BYT-CR specific, which IMO really should be fixed in the firmware. The proposed design has a flaw that breaks products on market simply because they don't have BIOS (unnecessarily) powering on phy. You're labeling that as BYT-CR specific issue because BYT-CR needs to be PM efficient and then it won't power on hw components in moment they don't need to. FW developers won't like this suggestion and I'd have to agree with them. 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). 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. 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. 2) Since the gpio resources are given to the controller device in ACPI tables and there isn't separate device object for the PHY at all, we need to deliver the gpios somehow separately to the phy driver. There is a thread where we are talking about how to do that: https://lkml.org/lkml/2014/12/18/82 How about just leave the logic the way it is: dwc3-pci.c registers platform_device with gpio as resource if the GPIOs are provided to dwc3. If not, then dwc3-pci.c will expect phy to have its own ACPI id. I think you are now talking about the platform devices for the legacy USB PHY framework created in dwc3-pci.c, which btw. were removed. Please note that we are not using platform bus with the ULPI devices, and those devices are created by the bus driver and not dwc3. Yes, that the one. Current products' BIOS on market didn't know about new ULPI bus. They rely on platform devices created by pci probe. Your ULPI bus proposal is way better to handle that problem and got my support since they beginning you showed that to me, but
Re: [PATCH 1/8] usb: add bus type for USB ULPI
On Wed, Jan 28, 2015 at 11:02:37PM -0600, Felipe Balbi wrote: Hi, On Fri, Jan 23, 2015 at 05:12:51PM +0200, Heikki Krogerus wrote: @@ -6,4 +6,5 @@ obj-$(CONFIG_USB_COMMON) += usb-common.o usb-common-y += common.o usb-common-$(CONFIG_USB_LED_TRIG) += led.o -obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o +obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o a bit of unrelated change here. OK diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index cc0ced0..c0fc3b5 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -84,3 +84,11 @@ config USB_OTG_FSM Implements OTG Finite State Machine as specified in On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification. +config USB_ULPI_BUS + bool USB ULPI PHY interface support + depends on USB || USB_GADGET depends on USB_SUPPORT ? sure +int ulpi_register_driver(struct ulpi_driver *drv); +void ulpi_unregister_driver(struct ulpi_driver *drv); + +#define module_ulpi_driver(__ulpi_driver) \ + module_driver(__ulpi_driver, ulpi_register_driver, \ + ulpi_unregister_driver) + +int ulpi_read(struct ulpi *ulpi, u8 addr); +int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val); no stubs ? Is there really need for them? Well, I'll add them. 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: difference in option.ko and sierra.ko Linux drivers
On Thu, Jan 29, 2015 at 02:50:13PM +0530, temp sha wrote: Can any one let me know the difference in option and sierra kernel modules ? looks like both drivers support GSM modem. And from the source code perspective both look similar. I am able to load sierra module for my Huawei USB dongle E156 and able to connect to internet using pppd. Is it OK to use sierra driver for Huawei in case there is no technical issue? If yes why there are two different modules? They support two different chipsets and control them differently. If the sierra module works for your hardware, great! Please send us a patch that adds the device id to the driver and we will be glad to merge it into the kernel tree. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Also, I was chatting in private with David and, apparently, there's a way to request for eye diagram data from BIOS straight. That's more in-line with what we would do for DT-based boots, passing that eye-diagram data as a DT attribute. Care to comment ? If that's the case, I'd rather use that BIOS hook and remove ulpi_read() from probe(). I'm not familiar with such method. But if there is one, I'm not against it. I need to check it. 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 7/8] phy: helpers for USB ULPI PHY registering
On Wed, Jan 28, 2015 at 11:03:55PM -0600, Felipe Balbi wrote:
On Fri, Jan 23, 2015 at 05:12:57PM +0200, Heikki Krogerus wrote:
ULPI PHYs need to be bound to their controllers with a
lookup. This adds helpers that the ULPI drivers can use to
do both, the registration of the PHY and the lookup, at the
same time.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/ulpi_phy.h | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 drivers/phy/ulpi_phy.h
diff --git a/drivers/phy/ulpi_phy.h b/drivers/phy/ulpi_phy.h
new file mode 100644
index 000..ac49fb6
--- /dev/null
+++ b/drivers/phy/ulpi_phy.h
@@ -0,0 +1,31 @@
+#include linux/phy/phy.h
+
+/**
+ * Helper that registers PHY for a ULPI device and adds a lookup for
binding it
+ * and it's controller, which is always the parent.
+ */
+static inline struct phy
+*ulpi_phy_create(struct ulpi *ulpi, struct phy_ops *ops)
+{
+ struct phy *phy;
+ int ret;
+
+ phy = phy_create(ulpi-dev, NULL, ops);
+ if (IS_ERR(phy))
+ return phy;
+
+ ret = phy_create_lookup(phy, usb2-phy, dev_name(ulpi-dev.parent));
I wonder if this would break DT-based boot where PHY phandle is
available. Kishon ?
If there are of_node for the PHY, we will not use this binding at all.
Br,
--
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
Hi On Thu, Jan 29, 2015 at 04:14:12PM +0200, Heikki Krogerus wrote: Can you share how tusb1210 is connected on the platform you're using as test for this patch? I don't think this driver would work reliably with this device: http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html The only reason why that board doesn't work is because of very much Baytrail-CR specific problems. These are are two issues, but the first That's not BYT-CR specific problems. That's just dwc3 and tusb1210 interacting as they're expecting to. one is critical for getting it working. Both will be handled, but separately from this set: 1) The firmware leaves the PHY in reset, forcing us to enable it somehow in OS before accessing ulpi. Unless we can get a firmware fix for that (it's starting to look like it's not going to happen; please correct me if you know something else!), we need to add a quirk for Baytrails (attached), which is probable still OK. But IMO this really should be fixed in the firmware. It seems you're expecting the PHY to be fully operational in order to probe it. That's wrong assumption. BYT-CR's BIOS is doing nothing wrong by leaving PHY on reset state. But it is. If we want to use ULPI as a bus like we do, then the PHY will be no different then devices attached to many other buses. We have made firmware fixes like that before. All the devices need to be in a state, operational enough after bootup, so we can probe them in OS without the need for hacks where they are separately enabled before it's possible. That makes no sense. Not only dwc3 and phy could live as modules (which means they may probe far away from device's boot time) but we have examples of buses not behaving like you said. E.g. I2C needs master to be probed to have bus working and no BIOS needs to make I2C controller functional in order to probe its controller's driver. 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 ? The real problem is what I stated above. With your current logic, you'll get stuck with checking/egg problem: you need phy probed to probe dwc3, but need dwc3 probed to power on phy. You need a logic to break this circular dependency. The moment we register the ulpi interface with the ulpi bus in dwc3_probe(), we know dwc3 has it's PHY interface in operational mode and register access to ULPI PHY is possible. And that is all dwc3 needs to/can do. I don't think you are seeing the whole ulpi bus in these patches, but in any case; Like I said, this problem is purely BYT-CR specific, which IMO really should be fixed in the firmware. The proposed design has a flaw that breaks products on market simply because they don't have BIOS (unnecessarily) powering on phy. You're labeling that as BYT-CR specific issue because BYT-CR needs to be PM efficient and then it won't power on hw components in moment they don't need to. FW developers won't like this suggestion and I'd have to agree with them. 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). one comment below on this. 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 ? 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. 2) Since the gpio resources are given to the controller device in ACPI tables and there isn't separate device object for the PHY at all, we need to deliver the gpios somehow separately to the phy driver. There is a thread where we are talking about how to do that: https://lkml.org/lkml/2014/12/18/82 How about just leave the logic the way it is: dwc3-pci.c registers
Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY
On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote: Also, I was chatting in private with David and, apparently, there's a way to request for eye diagram data from BIOS straight. That's more in-line with what we would do for DT-based boots, passing that eye-diagram data as a DT attribute. Care to comment ? If that's the case, I'd rather use that BIOS hook and remove ulpi_read() from probe(). I'm not familiar with such method. But if there is one, I'm not against it. I need to check it. David ? Care to comment ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Thu, 29 Jan 2015, Peter Chen wrote: Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c is a driver for a USB Device Controller. In fact, it is not, ci_hdrc_pci is the pci glue layer for chipidea driver. I am just wonder andy's v2 change is suitable or not, the right way should not call ehci_pci_init at all. The chipidea driver is structured in an odd way. It looks like the PCI device combines a host controller and a device controller (and maybe even an OTG controller) into a single device. That's why the chipidea driver has to duplicate ehci-pci.c and register various platform devices. If ehci-pci were allowed to bind to the device then the gadget controller (and OTG controller?) would be unusable, because ehci-pci doesn't know how to use them. 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 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
On Thu, 29 Jan 2015, Ruslan Bilovol wrote:
Change behavior during registration of gadgets and
gadget drivers in udc-core. Instead of previous
approach when for successful probe of usb gadget driver
at least one usb gadget should be already registered
use another one where gadget drivers and gadgets
can be registered in udc-core independently.
Independent registration of gadgets and gadget drivers
is useful for built-in into kernel gadget and gadget
driver case - because it's possible that gadget is
really probed only on late_init stage (due to deferred
probe) whereas gadget driver's probe is silently failed
on module_init stage due to no any UDC added.
Also it is useful for modules case - now there is no
difference what module to insert first: gadget module
or gadget driver one.
It's possible to do all this much more simply. In fact, I posted a
patch some time ago to do exactly this (but I can't find a copy of it
anywhere).
Signed-off-by: Ruslan Bilovol ruslan.bilo...@gmail.com
---
drivers/usb/gadget/udc/udc-core.c | 113
+++---
1 file changed, 105 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index e31d574..4c9412b 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -43,13 +43,23 @@ struct usb_udc {
struct usb_gadget_driver*driver;
struct usb_gadget *gadget;
struct device dev;
+ boolbind_by_name;
+ struct list_headlist;
+};
+
+struct pending_gadget_driver {
+ struct usb_gadget_driver*driver;
+ char*udc_name;
struct list_headlist;
};
You don't need all this stuff. What's the point of keeping track of
names? If there are any unbound gadget drivers pending, a newly
registered UDC should bind to the first one available.
Just add a pending list_head into the usb_gadget_driver structure and
forget about all the rest. (Or try to find my patch in the mailing
list archives somehow see if you think it needs to be changed.)
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 7/8] phy: helpers for USB ULPI PHY registering
On Thu, Jan 29, 2015 at 04:34:41PM +0200, Heikki Krogerus wrote:
On Wed, Jan 28, 2015 at 11:03:55PM -0600, Felipe Balbi wrote:
On Fri, Jan 23, 2015 at 05:12:57PM +0200, Heikki Krogerus wrote:
ULPI PHYs need to be bound to their controllers with a
lookup. This adds helpers that the ULPI drivers can use to
do both, the registration of the PHY and the lookup, at the
same time.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/ulpi_phy.h | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 drivers/phy/ulpi_phy.h
diff --git a/drivers/phy/ulpi_phy.h b/drivers/phy/ulpi_phy.h
new file mode 100644
index 000..ac49fb6
--- /dev/null
+++ b/drivers/phy/ulpi_phy.h
@@ -0,0 +1,31 @@
+#include linux/phy/phy.h
+
+/**
+ * Helper that registers PHY for a ULPI device and adds a lookup for
binding it
+ * and it's controller, which is always the parent.
+ */
+static inline struct phy
+*ulpi_phy_create(struct ulpi *ulpi, struct phy_ops *ops)
+{
+ struct phy *phy;
+ int ret;
+
+ phy = phy_create(ulpi-dev, NULL, ops);
+ if (IS_ERR(phy))
+ return phy;
+
+ ret = phy_create_lookup(phy, usb2-phy, dev_name(ulpi-dev.parent));
I wonder if this would break DT-based boot where PHY phandle is
available. Kishon ?
If there are of_node for the PHY, we will not use this binding at all.
where is that taken care of ? ulpi_phy_create() is called
unconditionally.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: dwc2: fix USB core dependencies
Hi, Adding John On Wed, Jan 28, 2015 at 10:49:00PM +0100, Arnd Bergmann wrote: It is currently possible to configure the dwc2 driver as built-in when host mode or dual-role is enabled, but the USB core is a loadable module. This leads to a link failure: drivers/built-in.o: In function `_dwc2_hcd_start': :(.text+0x84538): undefined reference to `usb_hcd_resume_root_hub' drivers/built-in.o: In function `_dwc2_hcd_urb_dequeue': :(.text+0x84aa0): undefined reference to `usb_hcd_check_unlink_urb' :(.text+0x84e4c): undefined reference to `usb_hcd_unlink_urb_from_ep' :(.text+0x84e74): undefined reference to `usb_hcd_giveback_urb' drivers/built-in.o: In function `dwc2_assign_and_init_hc': :(.text+0x86b98): undefined reference to `usb_hcd_unmap_urb_for_dma' drivers/built-in.o: In function `_dwc2_hcd_urb_enqueue': :(.text+0x8717c): undefined reference to `usb_hcd_link_urb_to_ep' :(.text+0x872f4): undefined reference to `usb_hcd_unlink_urb_from_ep' drivers/built-in.o: In function `dwc2_host_complete': :(.text+0x875d4): undefined reference to `usb_hcd_unlink_urb_from_ep' :(.text+0x87600): undefined reference to `usb_hcd_giveback_urb' drivers/built-in.o: In function `dwc2_hcd_init': :(.text+0x87ba8): undefined reference to `usb_disabled' :(.text+0x87d38): undefined reference to `usb_create_hcd' :(.text+0x88094): undefined reference to `usb_add_hcd' :(.text+0x880dc): undefined reference to `usb_put_hcd' drivers/built-in.o: In function `dwc2_hcd_remove': :(.text+0x8821c): undefined reference to `usb_remove_hcd' :(.text+0x8823c): undefined reference to `usb_put_hcd' drivers/built-in.o: In function `dwc2_hc_handle_tt_clear.isra.10': :(.text+0x88e2c): undefined reference to `usb_hub_clear_tt_buffer' drivers/built-in.o: In function `dwc2_hcd_qtd_add': :(.text+0x8b554): undefined reference to `usb_calc_bus_time' To fix the problem, this patch changes the dependencies so that dwc2 host mode can only be enabled if either the USB core is built-in or both USB and dwc2 are modules. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index b323c4c11b0a..76b9ba4dc925 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -23,7 +23,7 @@ choice config USB_DWC2_HOST bool Host only mode - depends on USB + depends on USB=y || (USB_DWC2=m USB) help The Designware USB2.0 high-speed host controller integrated into many SoCs. Select this option if you want the @@ -42,7 +42,7 @@ config USB_DWC2_PERIPHERAL config USB_DWC2_DUAL_ROLE bool Dual Role mode - depends on (USB=y || USB=USB_DWC2) (USB_GADGET=y || USB_GADGET=USB_DWC2) + depends on (USB=y USB_GADGET=y) || (USB_DWC2=m USB USB_GADGET) help Select this option if you want the driver to work in a dual-role mode. In this mode both host and gadget features are enabled, and ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/5] Add support for Fujitsu USB host controller
On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote: Hi, On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote: These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 4 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Mathias, let me know how you want to handle this. Either I take them all, or you take them all. What do you prefer ? Mathias ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY
On Thu, Jan 29, 2015 at 10:25:38AM -0800, David Cohen wrote: On Thu, Jan 29, 2015 at 10:04:16AM -0800, David Cohen wrote: On Thu, Jan 29, 2015 at 10:20:49AM -0600, Felipe Balbi wrote: On Thu, Jan 29, 2015 at 04:30:53PM +0200, Heikki Krogerus wrote: Also, I was chatting in private with David and, apparently, there's a way to request for eye diagram data from BIOS straight. That's more in-line with what we would do for DT-based boots, passing that eye-diagram data as a DT attribute. Care to comment ? If that's the case, I'd rather use that BIOS hook and remove ulpi_read() from probe(). I'm not familiar with such method. But if there is one, I'm not against it. I need to check it. David ? Care to comment ? I agree with Heikki's proposal to use BIOS hook and remove ulpi_read() from probe(). That address one of my chicken/egg concerns. Oops. I misinterpreted the thread. Heikki didn't propose that :) Let me get things mature and reply to here. I talked to David Box (CC'ed him to this reply). We can add an integer value to ACPI and request it during phy's probe using ACPI's Device Specific Data (_DSD). That would end the need to have phy functional during probe (being compatible to BYT-CR and to module support) and would be more compatible to DT as well. Br, David Br, David Br, David -- balbi -- To unsubscribe from this list: send the line unsubscribe 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: difference in option.ko and sierra.ko Linux drivers
On Thu, 2015-01-29 at 06:23 -0800, Greg KH wrote: On Thu, Jan 29, 2015 at 02:50:13PM +0530, temp sha wrote: Can any one let me know the difference in option and sierra kernel modules ? looks like both drivers support GSM modem. And from the source code perspective both look similar. I am able to load sierra module for my Huawei USB dongle E156 and able to connect to internet using pppd. Is it OK to use sierra driver for Huawei in case there is no technical issue? If yes why there are two different modules? They support two different chipsets and control them differently. If the sierra module works for your hardware, great! Please send us a patch that adds the device id to the driver and we will be glad to merge it into the kernel tree. I'd really, really rather not have non-Sierra devices controlled by 'sierra'. There are some Sierra-specific things the driver does, like interface enumeration, enabling/disabling power state and NMEA ports using Sierra-proprietary commands, and a few other things. Since PPP-using Huawei devices are usually done by 'option', I'd prefer to have them added there, and if there is some issue, then I'd prefer to have that issue fixed in option. Dan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)
Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.
This patch adds a cant_recv_wakeups flag to the usb_hcd structure
and sets the flag in isp1760-hcd. The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Nicolas Pitre n...@linaro.org
CC: sta...@vger.kernel.org
---
[as1775]
drivers/usb/core/driver.c | 12
drivers/usb/host/isp1760-hcd.c |3 +++
include/linux/usb/hcd.h|2 ++
3 files changed, 17 insertions(+)
Index: usb-3.19/include/linux/usb/hcd.h
===
--- usb-3.19.orig/include/linux/usb/hcd.h
+++ usb-3.19/include/linux/usb/hcd.h
@@ -146,6 +146,8 @@ struct usb_hcd {
unsignedamd_resume_bug:1; /* AMD remote wakeup quirk */
unsignedcan_do_streams:1; /* HC supports streams */
unsignedtpl_support:1; /* OTG EH TPL support */
+ unsignedcant_recv_wakeups:1;
+ /* wakeup requests from downstream aren't received */
unsigned intirq;/* irq allocated */
void __iomem*regs; /* device memory/io */
Index: usb-3.19/drivers/usb/host/isp1760-hcd.c
===
--- usb-3.19.orig/drivers/usb/host/isp1760-hcd.c
+++ usb-3.19/drivers/usb/host/isp1760-hcd.c
@@ -2247,6 +2247,9 @@ struct usb_hcd *isp1760_register(phys_ad
hcd-rsrc_start = res_start;
hcd-rsrc_len = res_len;
+ /* This driver doesn't support wakeup requests */
+ hcd-cant_recv_wakeups = 1;
+
ret = usb_add_hcd(hcd, irq, irqflags);
if (ret)
goto err_unmap;
Index: usb-3.19/drivers/usb/core/driver.c
===
--- usb-3.19.orig/drivers/usb/core/driver.c
+++ usb-3.19/drivers/usb/core/driver.c
@@ -1780,6 +1780,18 @@ static int autosuspend_check(struct usb_
dev_dbg(udev-dev, remote wakeup needed for autosuspend\n);
return -EOPNOTSUPP;
}
+
+ /*
+* If the device is a direct child of the root hub and the HCD
+* doesn't handle wakeup requests, don't allow autosuspend when
+* wakeup is needed.
+*/
+ if (w udev-parent == udev-bus-root_hub
+ bus_to_hcd(udev-bus)-cant_recv_wakeups) {
+ dev_dbg(udev-dev, HCD doesn't handle wakeup requests\n);
+ return -EOPNOTSUPP;
+ }
+
udev-do_remote_wakeup = w;
return 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: XHCI, brain-dead scanner, and microframe rounding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Only in the hope that you might be able to do some additional magic (but I won't be too disappointed if you tell that this time you have already archieved enough) a fresh log for my scanner (that never worked with USB-3.0 on my linux box and still doesn't do after the patch). I can at least tell that my USB-3.0 hard disk (that always worked fine with my computer) still works fine after the patch. Kind regards, Gunter. On 29.01.2015 17:42, Mathias Nyman wrote: On 27.01.2015 14:12, Gunter Königsmann wrote: That's very good news indeed. Will re-run the tests on my scanner and looking forward to the fix entering mainline. In the meantime I can acknowledge that with the fix my computer accepts USB memory sticks that normally didn't work. Kind regards, Gunter. Did some cleaning of the patch, and noticed it still had a few bits wrong, but apparently it worked anyway. I added the fixes on top of the ep_reset_halt_test branch. Can any of you with a failing scanner test that it still works? git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git and the ep_reset_halt_test branch, Thanks -Mathias -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUyp5ZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1M0YwNDdDRTY2QjkxQjBGNzI0QzU0NUQ1 Qzg2QzBFNDIxMUQ1QjhFAAoJEFyGwOQhHVuOzpcP/RbmflebVQdWUVDb6BgoPI8U CYJeO3jChzFL0OSrAu7lgM8B2MOzLO2NsFpQL3Mjj9TPl9uutvZ8W+phuI3f3kk5 LAktsljsW0E06kGAoQQTrxl8ZaqqY4MfSkkN3Vet/fGcFzaprk3kJYGUnRRlgzqz +HT1KKsRBo+z5L0m+Y2Bl/fATGAhx+Som85ECH+u9Q/CfgEjakT6wLetfyJyGIDs quJljakzejp8xkLppVREP1ObSx4i7L3HZMcOkdRDuzWqpbmMLxtgOJ/RybHCJKqk UEoz1xnHvCVC/4kSPaNT+6Bxl3kmZxpnwxpXuRaVs+xIyrQAHQ32wivQn/GhVh1c tzh2EuRtR2A47fdIpNp6+s2/YGPdN6s0zZQyDKuZAgH6AhsiNUFPOcIhWlMNKgvr qmvzCNsxXtASmbc6zbDsXDCdAo9bk5CHdfcUaV+Uuzt29jNlTgbu+9XcWl2NEmRo UANJ8X7b/0WdfW2Mw/cBaLaUGQBjxblmxCzzr4l5u3c6pNDme+Xb6kdTNmZPeyDx wFQgD2i4NgDkGs2FMlHoC9OIoxDXXS/EvD8txMyNO8mVVsnxnQBiHcfOuJIw2jEh CmpUfxwNGuC8qGtad0v8BvMMnc4/awiW1F4RWADy9NWCs1V9XgczUNlYhmWtSZX8 f2glk+HzHR6nEFj0duRS =1ERG -END PGP SIGNATURE- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.19.0-rc5+ (gunter@Marius) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu2) ) #2 SMP PREEMPT Thu Jan 29 19:32:42 CET 2015 [0.00] Command line: BOOT_IMAGE=/@/boot/vmlinuz-3.19.0-rc5+ root=UUID=6d0fd0ad-9048-4fdb-881a-eba6d6d13c3b ro rootflags=subvol=@ acpi_backlight=vendor init=/lib/systemd/systemd quiet splash acpi_backlight=vendor init=/lib/systemd/systemd vt.handoff=7 init=/lib/systemd/systemd [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x000917ff] usable [0.00] BIOS-e820: [mem 0x00091800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x30da] usable [0.00] BIOS-e820: [mem 0x30db-0x321a] reserved [0.00] BIOS-e820: [mem 0x321b-0x36abefff] usable [0.00] BIOS-e820: [mem 0x36abf000-0x36ebefff] reserved [0.00] BIOS-e820: [mem 0x36ebf000-0x36fbefff] ACPI NVS [0.00] BIOS-e820: [mem 0x36fbf000-0x36ffefff] ACPI data [0.00] BIOS-e820: [mem 0x36fff000-0x36ff] usable [0.00] BIOS-e820: [mem 0x3700-0x3f9f] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001bf5f] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: Acer Aspire S7-391/Storm, BIOS V2.09 11/16/2012 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x1bf600 max_arch_pfn = 0x4 [
Re: [PATCH v2 1/2] usb: phy: generic: fix the gpios to be optional
On Thu, Jan 29, 2015 at 8:41 PM, Robert Jarzmik robert.jarz...@free.fr wrote: + if (nop-gpiod_reset) + gpiod_direction_output(nop-gpiod_reset, 0); Why do you set it to zero independently of the GPIO active level flag? Previously, we had: if (nop-reset_active_low) gpio_flags = GPIOF_OUT_INIT_LOW; else gpio_flags = GPIOF_OUT_INIT_HIGH; err = devm_gpio_request_one(dev, nop-gpio_reset, gpio_flags, dev_name(dev)); ,which correctly puts the GPIO output to the correct initial level depending on the active level flag. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] usb: phy: generic: fix the vbus interrupt request
Declare the interrupt as one shot so that it is masked until the end
of the threaded handler. This prevents the irq core from spitting out an
error :
Threaded irq requested with handler=NULL and !ONESHOT for irq 63
This was introduced by commit usb: phy: generic: add vbus support.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
drivers/usb/phy/phy-generic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 9f08c1e..af32ce2 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -41,7 +41,8 @@
#include phy-generic.h
#define VBUS_IRQ_FLAGS \
- (IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING)
+ (IRQF_SHARED | IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | \
+ IRQF_ONESHOT)
struct platform_device *usb_phy_generic_register(void)
{
--
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
[PATCH v2 1/2] usb: phy: generic: fix the gpios to be optional
All the gpios, ie. reset-gpios and vbus-detect-gpio, should be optional
and not prevent the driver from working. Fix the regression in the
behavior introduced by commit usb: phy: generic: migrate to gpio_desc.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
Since v1: correctly handle the error codes
set the reset gpio as an output gpio
---
drivers/usb/phy/phy-generic.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 9a826ff..9f08c1e 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -218,12 +218,12 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, vcc-supply);
- nop-gpiod_reset = devm_gpiod_get_optional(dev, reset-gpios);
- err = PTR_ERR(nop-gpiod_reset);
+ nop-gpiod_reset = devm_gpiod_get_optional(dev, reset);
+ err = PTR_ERR_OR_ZERO(nop-gpiod_reset);
if (!err) {
nop-gpiod_vbus = devm_gpiod_get_optional(dev,
-vbus-detect-gpio);
- err = PTR_ERR(nop-gpiod_vbus);
+vbus-detect);
+ err = PTR_ERR_OR_ZERO(nop-gpiod_vbus);
}
} else if (pdata) {
type = pdata-type;
@@ -242,9 +242,11 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
if (err == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (err) {
- dev_err(dev, Error requesting RESET GPIO\n);
+ dev_err(dev, Error requesting RESET or VBUS GPIO\n);
return err;
}
+ if (nop-gpiod_reset)
+ gpiod_direction_output(nop-gpiod_reset, 0);
nop-phy.otg = devm_kzalloc(dev, sizeof(*nop-phy.otg),
GFP_KERNEL);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id
On Tuesday, December 16, 2014 06:12:30 PM Octavian Purdila wrote:
acpi_tb_delete_namespace_by_owner expects ACPI_MTX_INTERPRETER to be
taken. This fixes the following issue:
ACPI Error: Mutex [0x0] is not acquired, cannot release (20141107/utmutex-322)
Call Trace:
[81b0bd28] dump_stack+0x4f/0x7b
[81546bfc] acpi_ut_release_mutex+0x47/0x67
[81542cf1] acpi_tb_delete_namespace_by_owner+0x57/0x8d
[81543ef1] acpi_unload_table_id+0x3a/0x5e
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
I've queued up this one for 3.20.
---
drivers/acpi/acpica/tbxface.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index 6482b0d..9520ae1 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -281,6 +281,11 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
ACPI_FUNCTION_TRACE(acpi_unload_table_id);
+ status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
/* Find table in the global table list */
for (i = 0; i acpi_gbl_root_table_list.current_table_count; ++i) {
if (id != acpi_gbl_root_table_list.tables[i].owner_id) {
@@ -297,6 +302,8 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
acpi_tb_set_table_loaded_flag(i, FALSE);
break;
}
+
+ (void)acpi_ut_release_mutex(ACPI_MTX_INTERPRETER);
return_ACPI_STATUS(status);
}
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
On 01/28/2015 09:15 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
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 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..fd11536 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
+ select 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..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * 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;
+ bool id_irqwake;/* ID wakeup enabled flag */
+
+ 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,
I'll use the defined name for extcon cable name as soon because
it has potential isseu about the conflict of extcon cable name between
subsystems.
So, I recommend to use a captical letter as USB-HOST instead of USB-Host.
If other
[PATCH v1] 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.
---
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
RE: [PATCH 2/2] usb: renesas_usbhs: add support for requesting DT DMA
Hi Simon-san,
-Original Message-
From: Simon Horman [mailto:ho...@verge.net.au]
Sent: Thursday, January 29, 2015 9:19 PM
To: yoshihiro shimoda
Cc: gre...@linuxfoundation.org; ba...@ti.com; robh...@kernel.org;
pawel.m...@arm.com; mark.rutl...@arm.com;
ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
linux-usb@vger.kernel.org; linux...@vger.kernel.org
Subject: Re: [PATCH 2/2] usb: renesas_usbhs: add support for requesting DT DMA
Hi Shimoda-san,
On Mon, Jan 19, 2015 at 12:53:17PM +0900, Yoshihiro Shimoda wrote:
This patch adds dma_request_slave_channel_reason() calling to request
dma slave channels for multiplatform environment.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
.../devicetree/bindings/usb/renesas_usbhs.txt |2 ++
drivers/usb/renesas_usbhs/fifo.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
I have observed what appears to be a regression caused by this
patch when booting a kernel built using shmobile_defconfig on the koelsch
and lager boards.
Thank you for the point. I should have tested using shmobile_defconfig.
So, I will submit a patch to fix this issue.
Detail:
- Since the defconfig doesn't enable CONFIG_GENERIC_PHY and
CONFIG_PHY_RCAR_GEN2,
the driver's probe failed.
- Since we don't have dmac for usb at the moment if we use the defconfig,
dma_request_slave_channel_reason() will fail with ERR_PTR(-ENODEV).
- But, the current renesas_usbhs driver will keeps ERR_PTR(-ENODEV) in tx_chan
and rx_chan.
So, if the driver calls usbhs_dma_quit, the driver calls
dma_release_channel() with
wrong argument (ERR_PTR(-ENODEV)).
- So, I will write a patch to set tx_chan and rx_chan to NULL in the
usbhsf_dma_init_dt()
if these values are IS_ERR.
Best regards,
Yoshihiro Shimoda
I noticed this problem while testing next-20150129.
I have provided boot logs at the end of this email.
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index b08c903..61b045b 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -14,6 +14,8 @@ Optional properties:
function should be enabled
- phys: phandle + phy specifier pair
- phy-names: must be usb
+ - dmas: Must contain a list of references to DMA specifiers.
+ - dma-names : Must contain a list of DMA names, tx or rx.
Example:
usbhs: usb@e659 {
diff --git a/drivers/usb/renesas_usbhs/fifo.c
b/drivers/usb/renesas_usbhs/fifo.c
index 48e31b9..4c086b1 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -1069,12 +1069,21 @@ static void usbhsf_dma_init_pdev(struct usbhs_fifo
*fifo)
fifo-rx_slave);
}
+static void usbhsf_dma_init_dt(struct device *dev, struct usbhs_fifo *fifo)
+{
+ fifo-tx_chan = dma_request_slave_channel_reason(dev, tx);
+ fifo-rx_chan = dma_request_slave_channel_reason(dev, rx);
+}
+
static void usbhsf_dma_init(struct usbhs_priv *priv,
struct usbhs_fifo *fifo)
{
struct device *dev = usbhs_priv_to_dev(priv);
- usbhsf_dma_init_pdev(fifo);
+ if (dev-of_node)
+ usbhsf_dma_init_dt(dev, fifo);
+ else
+ usbhsf_dma_init_pdev(fifo);
if (fifo-tx_chan || fifo-rx_chan)
dev_dbg(dev, enable DMAEngine (%s%s%s)\n,
Koelsch
---
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 3.19.0-rc5-00129-gabd2dbf
(ho...@ayumi.isobedori.kobe.vergenet.net) (gcc version 4.6.3 (GCC) ) #959 SMP
Thu Jan 29 20:40:07 JST 2015
CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5307d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine model: Koelsch
Ignoring memory block 0x2 - 0x24000
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c0612a80, node_mem_map eeff9000
Normal zone: 1520 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 194560 pages, LIFO batch:31
HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 7 pages/cpu @eefca000 s7552 r0 d21120 u32768
pcpu-alloc: s7552 r0 d21120 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624
Kernel command line: ignore_loglevel rw root=/dev/nfs ip=dhcp
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1032964K/1048576K available (4524K kernel code, 264K rwdata, 1128K
rodata, 268K init, 191K bss, 15612K reserved,
0K cma-reserved, 270336K highmem)
Virtual kernel memory
Re: XHCI, brain-dead scanner, and microframe rounding
On Jan 29, 2015, at 8:42 AM, Mathias Nyman wrote: On 27.01.2015 14:12, Gunter Königsmann wrote: That's very good news indeed. Will re-run the tests on my scanner and looking forward to the fix entering mainline. In the meantime I can acknowledge that with the fix my computer accepts USB memory sticks that normally didn't work. Kind regards, Gunter. Did some cleaning of the patch, and noticed it still had a few bits wrong, but apparently it worked anyway. I added the fixes on top of the ep_reset_halt_test branch. Can any of you with a failing scanner test that it still works? git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git and the ep_reset_halt_test branch, Thanks -Mathias Looks like it still works at 9fc99b08. -- To unsubscribe from this list: send the line unsubscribe 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 01/13] usb: dwc2: host: register hcd handle to the phy
On 01/28/2015 11:26 PM, Kaukab, Yousaf wrote:
-Original Message-
From: John Youn [mailto:john.y...@synopsys.com]
Sent: Thursday, January 29, 2015 3:25 AM
To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com;
john.y...@synopsys.com
Cc: Herrero, Gregory; r.bald...@samsung.com;
dingu...@opensource.altera.com; sergei.shtyl...@cogentembedded.com
Subject: RE: [PATCH v1 01/13] usb: dwc2: host: register hcd handle to the phy
From: Mian Yousaf Kaukab [mailto:yousaf.kau...@intel.com]
Sent: Wednesday, January 21, 2015 6:37 AM
From: Gregory Herrero gregory.herr...@intel.com
If phy driver is present, register hcd handle to it and let it take
care of calling usb_add_hcd. Otherwise, add hcd here.
Moreover, save irq number so that it can be used to call usb_add_hcd.
Signed-off-by: Gregory Herrero gregory.herr...@intel.com
---
drivers/usb/dwc2/hcd.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
755e16b..4375d4f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2779,6 +2779,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int
irq,
u32 hcfg;
int i, num_channels;
int retval;
+ bool add_host = true;
if (usb_disabled())
return -ENODEV;
@@ -2935,14 +2936,30 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg,
int irq,
/* Don't support SG list at this point */
hcd-self.sg_tablesize = 0;
+ /* Save irq number */
+ hcd-irq = irq;
+
/*
* Finish generic HCD initialization and start the HCD. This
function
* allocates the DMA buffer pool, registers the USB bus, requests
the
* IRQ line, and calls hcd_start method.
+* If a phy driver is present, let it handle the hcd initialization.
*/
- retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
- if (retval 0)
- goto error3;
+ if (!IS_ERR_OR_NULL(hsotg-uphy)) {
+ retval = otg_set_host(hsotg-uphy-otg, hcd-
self);
+ if (retval) {
+ if (retval != -ENOTSUPP)
+ goto error3;
+ } else {
+ add_host = false;
+ }
+ }
+
+ if (add_host) {
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (retval)
+ goto error3;
+ }
device_wakeup_enable(hcd-self.controller);
@@ -2976,7 +2993,8 @@ EXPORT_SYMBOL_GPL(dwc2_hcd_init); void
dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {
struct usb_hcd *hcd;
-
+ bool remove_host = true;
+ int retval;
dev_dbg(hsotg-dev, DWC OTG HCD REMOVE\n);
hcd = dwc2_hsotg_to_hcd(hsotg);
@@ -2988,7 +3006,14 @@ void dwc2_hcd_remove(struct dwc2_hsotg
*hsotg)
return;
}
- usb_remove_hcd(hcd);
+ if (!IS_ERR_OR_NULL(hsotg-uphy)) {
+ retval = otg_set_host(hsotg-uphy-otg, NULL);
+ if (!retval)
+ remove_host = false;
+ }
+
+ if (remove_host)
+ usb_remove_hcd(hcd);
hsotg-priv = NULL;
dwc2_hcd_release(hsotg);
usb_put_hcd(hcd);
--
1.9.1
Hi Yousaf,
Hi John,
This patch seems to break host-mode on the Altera platform.
When it comes up as an A-Host, the HCD doesn't get loaded. When it comes up
as a B-Peripheral, it gets the connector ID status change interrupt, but
hangs
the system.
Thank you testing this patchset. Can you point me to the phy driver used by
your platform?
I will take a look what's going on.
It is using the generic PHY.
I can drop this patch for now. Are you ok with rest of the patches in this
set? If so, can you send your conditional ACK for them? May be there is still
time to get them queued for v3.20.
Yes, I'm ok with that.
Hi Felipe,
Could you queue patch 2-13 for 3.20 or would you like it respun?
Patch 2-13:
Acked-by: John Youn johny...@synopsys.com
Also Robert Baldyga gave Tested-by previously:
[for gadget part]
Tested-by: Robert Baldyga r.bald...@samsung.com
Thanks,
John
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
On 01/29/2015 08:26 PM, Roger Quadros wrote:
Chanwoo,
On 29/01/15 03:49, Chanwoo Choi wrote:
Hi Roger,
We need to discuss one point about 'id_irqwake'.
I don't recommend to use 'id_irqwake' field.
And I catch build warning by using select keywork in Kconfig.
It is my wrong guide of select keyword. So, I'll change it
as 'depends on' keyword.
Looks good to me except for 'id_irqwake'.
I'll apply this patch on 3.21 queue after completing this discussion.
On 01/28/2015 09:15 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
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 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..fd11536 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
+ select GPIOLIB
I catch the build warning if using 'select' instead of 'depends on' as
following:
It is my wrong guide to you. So, I'll modify it by using depends on as
your original patch.
OK. Thanks.
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage -j 8
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/gpio/Kconfig:34:error: recursive dependency detected!
drivers/gpio/Kconfig:34: symbol GPIOLIB is selected by EXTCON_USB_GPIO
drivers/extcon/Kconfig:96: symbol EXTCON_USB_GPIO depends on EXTCON
drivers/extcon/Kconfig:1:symbol EXTCON is selected by CHARGER_MANAGER
drivers/power/Kconfig:316: symbol CHARGER_MANAGER depends on POWER_SUPPLY
drivers/power/Kconfig:1: symbol POWER_SUPPLY is selected by HID_SONY
drivers/hid/Kconfig:670: symbol HID_SONY depends on NEW_LEDS
drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by BCMA_DRIVER_GPIO
drivers/bcma/Kconfig:75: symbol BCMA_DRIVER_GPIO 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..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * 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
Re: [PATCH] usb: dwc2: fix USB core dependencies
On 01/29/2015 08:25 AM, Felipe Balbi wrote: Hi, Adding John On Wed, Jan 28, 2015 at 10:49:00PM +0100, Arnd Bergmann wrote: It is currently possible to configure the dwc2 driver as built-in when host mode or dual-role is enabled, but the USB core is a loadable module. This leads to a link failure: drivers/built-in.o: In function `_dwc2_hcd_start': :(.text+0x84538): undefined reference to `usb_hcd_resume_root_hub' drivers/built-in.o: In function `_dwc2_hcd_urb_dequeue': :(.text+0x84aa0): undefined reference to `usb_hcd_check_unlink_urb' :(.text+0x84e4c): undefined reference to `usb_hcd_unlink_urb_from_ep' :(.text+0x84e74): undefined reference to `usb_hcd_giveback_urb' drivers/built-in.o: In function `dwc2_assign_and_init_hc': :(.text+0x86b98): undefined reference to `usb_hcd_unmap_urb_for_dma' drivers/built-in.o: In function `_dwc2_hcd_urb_enqueue': :(.text+0x8717c): undefined reference to `usb_hcd_link_urb_to_ep' :(.text+0x872f4): undefined reference to `usb_hcd_unlink_urb_from_ep' drivers/built-in.o: In function `dwc2_host_complete': :(.text+0x875d4): undefined reference to `usb_hcd_unlink_urb_from_ep' :(.text+0x87600): undefined reference to `usb_hcd_giveback_urb' drivers/built-in.o: In function `dwc2_hcd_init': :(.text+0x87ba8): undefined reference to `usb_disabled' :(.text+0x87d38): undefined reference to `usb_create_hcd' :(.text+0x88094): undefined reference to `usb_add_hcd' :(.text+0x880dc): undefined reference to `usb_put_hcd' drivers/built-in.o: In function `dwc2_hcd_remove': :(.text+0x8821c): undefined reference to `usb_remove_hcd' :(.text+0x8823c): undefined reference to `usb_put_hcd' drivers/built-in.o: In function `dwc2_hc_handle_tt_clear.isra.10': :(.text+0x88e2c): undefined reference to `usb_hub_clear_tt_buffer' drivers/built-in.o: In function `dwc2_hcd_qtd_add': :(.text+0x8b554): undefined reference to `usb_calc_bus_time' To fix the problem, this patch changes the dependencies so that dwc2 host mode can only be enabled if either the USB core is built-in or both USB and dwc2 are modules. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index b323c4c11b0a..76b9ba4dc925 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -23,7 +23,7 @@ choice config USB_DWC2_HOST bool Host only mode -depends on USB +depends on USB=y || (USB_DWC2=m USB) help The Designware USB2.0 high-speed host controller integrated into many SoCs. Select this option if you want the @@ -42,7 +42,7 @@ config USB_DWC2_PERIPHERAL config USB_DWC2_DUAL_ROLE bool Dual Role mode -depends on (USB=y || USB=USB_DWC2) (USB_GADGET=y || USB_GADGET=USB_DWC2) +depends on (USB=y USB_GADGET=y) || (USB_DWC2=m USB USB_GADGET) help Select this option if you want the driver to work in a dual-role mode. In this mode both host and gadget features are enabled, and Acked-by: John Youn johny...@synopsys.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] usb: dwc2: Use platform endianness when accessing registers
On 01/28/2015 02:02 AM, Antti Seppälä wrote:
On 27 January 2015 at 04:18, John Youn john.y...@synopsys.com wrote:
From: Vincent Pelletier [mailto:plr.vinc...@gmail.com]
Sent: Friday, January 23, 2015 12:19 AM
On Fri, 23 Jan 2015 02:38:37 +, John Youn john.y...@synopsys.com
wrote:
Having the __raw functions everywhere is not pretty and probably not a
good idea either.
I would rather have a dwc2_writel/dwc2_readl (like in dwc3), and we
can figure out what needs to happen in there to support your platform.
As for readl/writel or the __raw equivalents, I am not sure. I haven't
run the in-kernel driver on a big endian system so I don't know what
the issue is. But I suspect there may be consequences to other
platforms if we simply change this to __raw_readl/__raw_writel.
(focussing on readl, but the following also applies to writel)
readl is defined as __le32_to_cpu(__raw_readl(...)), so using readl on
little endian is equivalent to __raw_readl, as __le32_to_cpu is a no-op.
On big endian, it causes problems because __le32_to_cpu swaps bytes
around, causing GSNPSID to be read as 0xnn2n544f instead of expected
0x4f542nnn - and likewise for all other registers.
An earlier version (sent to linux-usb a week ago with not enough CC,
but I cannot find it in archives now) defined dwc2_readl as
le32_to_cpu(readl(...))
which is equivalent to
le32_to_cpu(le32_to_cpu(__raw_readl(...)))
and which, on big-endian, makes le32_to_cpu(le32_to_cpu()) a no-op and
(ignoring possible compiler optimisation) swaps bytes twice per call.
On little endian, it is still equivalent to __raw_readl(...).
As for the prettiness of calling double-underscore functions,
speaking for myself I'm not used to Linux development enough to tell.
My python developer reflex tell me it's not how it should be.
OTOH there is no raw_readl or so alias, and other USB drivers
reference __raw_readl (example as of v3.14.28):
linux/drivers/usb$ git grep -l __raw_readl
gadget/at91_udc.c
gadget/atmel_usba_udc.c
gadget/atmel_usba_udc.h
gadget/fsl_udc_core.c
gadget/pxa27x_udc.h
host/ehci-omap.c
host/ehci-orion.c
host/ehci-w90x900.c
host/ehci.h
host/isp1760-hcd.c
host/ohci-da8xx.c
host/ohci-nxp.c
host/ohci-pxa27x.c
musb/da8xx.c
musb/davinci.c
musb/musb_dsps.c
musb/musb_io.h
phy/phy-fsl-usb.c
Would it be better to wrap __raw_readl in a macro and call that
everywhere rather than calling __raw_readl itself ?
I was thinking more along the lines of what dwc3 does. See
drivers/usb/dwc3/io.h.
One solution would be to do as above, and put in a compile-time check
for your platform and call the appropriate access function.
I believe writel/readl also preserves memory ordering so it might
affect other platforms to just use the __raw equivalent in its place.
Broadly speaking readl(x) can be split to three separate functions. I
think it evaluates to something like below for dwc2:
static inline u32 dwc2_readl(const volatile void __iomem *addr)
{
u32 value = __raw_readl(addr); /* Raw access to io */
value = le32_to_cpu(value); /* Ensure little-endian byte order */
mb(); /* Prevent re-ordering of io-accesses */
return value;
}
Now le32_to_cpu is a no-op for little-endian platforms and breaks dwc2
for big endian ones (as Vincent explained, it swaps bytes
unnecessarily for big endian platforms). So I'm thinking of dropping
it and re-spinning the patch with something like below:
static inline u32 dwc2_readl(const volatile void __iomem *addr)
{
u32 value = __raw_readl(addr); /* Raw access to io */
mb(); /* Prevent re-ordering of io-accesses */
return value;
}
and then replacing all readl's in dwc2 with dwc2_readl (and same for
writel). That way nothing should get broken on little-endian as we're
only dropping a no-op and we get to use the same code for big-endian
platforms too. Would that be ok?
I really would not want to add platform specific io-access
functionalities if we can manage with a generic approach.
Ok, I'm fine with that.
John
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: renesas_usbhs: fix NULL pointer dereference in dma_release_channel()
This patch fixes an issue that the following commit causes NULL
pointer dereference in dma_release_channel().
usb: renesas_usbhs: add support for requesting DT DMA
(commit id abd2dbf6bb1b5f3a03a8c76b1a8879da1dd30caa)
The usbhsf_dma_init_dt() should set fifo-{t,r}x_chan to NULL if
dma_request_slave_channel_reason() returns IS_ERR value.
Otherwise, usbhsf_dma_quit() will call dma_release_channel(), and then
NULL pointer dereference happens.
Reported-by: Simon Horman ho...@verge.net.au
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
This patch is based on Felipe's usb.git / testing/next branch.
(commit id =7db3990cb707ff91cd6507d53a0a730afe97)
drivers/usb/renesas_usbhs/fifo.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 4c086b1..d891bff 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -1072,7 +1072,11 @@ static void usbhsf_dma_init_pdev(struct usbhs_fifo *fifo)
static void usbhsf_dma_init_dt(struct device *dev, struct usbhs_fifo *fifo)
{
fifo-tx_chan = dma_request_slave_channel_reason(dev, tx);
+ if (IS_ERR(fifo-tx_chan))
+ fifo-tx_chan = NULL;
fifo-rx_chan = dma_request_slave_channel_reason(dev, rx);
+ if (IS_ERR(fifo-rx_chan))
+ fifo-rx_chan = NULL;
}
static void usbhsf_dma_init(struct usbhs_priv *priv,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 01/13] usb: dwc2: host: register hcd handle to the phy
On Thu, Jan 29, 2015 at 05:29:23PM -0800, John Youn wrote:
On 01/28/2015 11:26 PM, Kaukab, Yousaf wrote:
-Original Message-
From: John Youn [mailto:john.y...@synopsys.com]
Sent: Thursday, January 29, 2015 3:25 AM
To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com;
john.y...@synopsys.com
Cc: Herrero, Gregory; r.bald...@samsung.com;
dingu...@opensource.altera.com; sergei.shtyl...@cogentembedded.com
Subject: RE: [PATCH v1 01/13] usb: dwc2: host: register hcd handle to the
phy
From: Mian Yousaf Kaukab [mailto:yousaf.kau...@intel.com]
Sent: Wednesday, January 21, 2015 6:37 AM
From: Gregory Herrero gregory.herr...@intel.com
If phy driver is present, register hcd handle to it and let it take
care of calling usb_add_hcd. Otherwise, add hcd here.
Moreover, save irq number so that it can be used to call usb_add_hcd.
Signed-off-by: Gregory Herrero gregory.herr...@intel.com
---
drivers/usb/dwc2/hcd.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
755e16b..4375d4f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2779,6 +2779,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int
irq,
u32 hcfg;
int i, num_channels;
int retval;
+ bool add_host = true;
if (usb_disabled())
return -ENODEV;
@@ -2935,14 +2936,30 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg,
int irq,
/* Don't support SG list at this point */
hcd-self.sg_tablesize = 0;
+ /* Save irq number */
+ hcd-irq = irq;
+
/*
* Finish generic HCD initialization and start the HCD. This
function
* allocates the DMA buffer pool, registers the USB bus, requests
the
* IRQ line, and calls hcd_start method.
+ * If a phy driver is present, let it handle the hcd initialization.
*/
- retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
- if (retval 0)
- goto error3;
+ if (!IS_ERR_OR_NULL(hsotg-uphy)) {
+ retval = otg_set_host(hsotg-uphy-otg, hcd-
self);
+ if (retval) {
+ if (retval != -ENOTSUPP)
+ goto error3;
+ } else {
+ add_host = false;
+ }
+ }
+
+ if (add_host) {
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (retval)
+ goto error3;
+ }
device_wakeup_enable(hcd-self.controller);
@@ -2976,7 +2993,8 @@ EXPORT_SYMBOL_GPL(dwc2_hcd_init); void
dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {
struct usb_hcd *hcd;
-
+ bool remove_host = true;
+ int retval;
dev_dbg(hsotg-dev, DWC OTG HCD REMOVE\n);
hcd = dwc2_hsotg_to_hcd(hsotg);
@@ -2988,7 +3006,14 @@ void dwc2_hcd_remove(struct dwc2_hsotg
*hsotg)
return;
}
- usb_remove_hcd(hcd);
+ if (!IS_ERR_OR_NULL(hsotg-uphy)) {
+ retval = otg_set_host(hsotg-uphy-otg, NULL);
+ if (!retval)
+ remove_host = false;
+ }
+
+ if (remove_host)
+ usb_remove_hcd(hcd);
hsotg-priv = NULL;
dwc2_hcd_release(hsotg);
usb_put_hcd(hcd);
--
1.9.1
Hi Yousaf,
Hi John,
This patch seems to break host-mode on the Altera platform.
When it comes up as an A-Host, the HCD doesn't get loaded. When it comes up
as a B-Peripheral, it gets the connector ID status change interrupt, but
hangs
the system.
Thank you testing this patchset. Can you point me to the phy driver used by
your platform?
I will take a look what's going on.
It is using the generic PHY.
I can drop this patch for now. Are you ok with rest of the patches in this
set? If so, can you send your conditional ACK for them? May be there is
still time to get them queued for v3.20.
Yes, I'm ok with that.
Hi Felipe,
Could you queue patch 2-13 for 3.20 or would you like it respun?
Patch 2-13:
Acked-by: John Youn johny...@synopsys.com
Also Robert Baldyga gave Tested-by previously:
[for gadget part]
Tested-by: Robert Baldyga r.bald...@samsung.com
It would be nicer if author could resend 2-13 with your Acked-by and
Robert's Tested-by
Thanks
--
balbi
signature.asc
Description: Digital signature
[PATCH v4 5/7] usb: serial: implement set_termios for F81232
The original driver had do not any h/w change in driver.
This patch implements with configure H/W for
baud/parity/word length/stop bits functional.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 144 +---
1 file changed, 137 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 12e1ae4..248f40d 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -51,6 +51,10 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define F81232_USB_TIMEOUT 3000
#define SERIAL_BASE_ADDRESS (0x0120)
+#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS)
+#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS)
+#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS)
+#define LINE_CONTROL_REGISTER (0x03 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
struct f81232_private {
spinlock_t lock;
@@ -61,6 +65,20 @@ struct f81232_private {
struct usb_serial_port *port;
};
+static inline int calc_baud_divisor(u32 baudrate)
+{
+ u32 divisor, rem;
+
+ divisor = 115200L / baudrate;
+ rem = 115200L % baudrate;
+
+ /* Round to nearest divisor */
+ if (((rem * 2) = baudrate) (baudrate != 110))
+ divisor++;
+
+ return divisor;
+}
+
static inline int f81232_get_register(struct usb_device *dev,
u16 reg, u8 *data)
{
@@ -84,6 +102,29 @@ static inline int f81232_get_register(struct usb_device
*dev,
return status;
}
+static inline int f81232_set_register(struct usb_device *dev,
+ u16 reg, u8 data)
+{
+ int status;
+
+ status = usb_control_msg(dev,
+ usb_sndctrlpipe(dev, 0),
+ REGISTER_REQUEST,
+ SET_REGISTER,
+ reg,
+ 0,
+ data,
+ 1,
+ F81232_USB_TIMEOUT);
+
+ if (status 0) {
+ dev_dbg(dev-dev,
+ %s status: %d\n, __func__, status);
+ }
+
+ return status;
+}
+
static void f81232_read_msr(struct f81232_private *priv)
{
int status;
@@ -240,15 +281,104 @@ static void f81232_break_ctl(struct tty_struct *tty, int
break_state)
static void f81232_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
- /* FIXME - Stubbed out for now */
+ u16 divisor;
+ u16 new_lcr = 0;
+ u8 data;
+ int status;
+ struct ktermios *termios = tty-termios;
+ struct usb_device *dev = port-serial-dev;
+ unsigned int cflag = termios-c_cflag;
- /* Don't change anything if nothing has changed */
- if (old_termios !tty_termios_hw_change(tty-termios, old_termios))
- return;
+ divisor = calc_baud_divisor(tty_get_baud_rate(tty));
+
+ status = f81232_set_register(dev, LINE_CONTROL_REGISTER,
+UART_LCR_DLAB); /* DLAB */
+
+ if (status 0) {
+ dev_dbg(dev-dev,
+ %s status: %d line:%d\n, __func__, status, __LINE__);
+ }
+
+ status = f81232_set_register(dev, RECEIVE_BUFFER_REGISTER,
+divisor 0x00ff); /* low */
+
+ if (status 0) {
+ dev_dbg(dev-dev,
+ %s status: %d line:%d\n, __func__, status, __LINE__);
+ }
+
+ status = f81232_set_register(dev, INTERRUPT_ENABLE_REGISTER,
+(divisor 0xff00) 8); /* high */
+
+ if (status 0) {
+ dev_dbg(dev-dev,
+ %s status: %d line:%d\n, __func__, status, __LINE__);
+ }
+
+ status = f81232_set_register(dev, LINE_CONTROL_REGISTER, 0x00);
+
+ if (status 0) {
+ dev_dbg(dev-dev,
+ %s status: %d line:%d\n, __func__, status, __LINE__);
+ }
+
+ if (cflag PARENB) {
+ new_lcr |= UART_LCR_PARITY; /* default parity on/odd */
+
+ if (cflag CMSPAR) {
+ if (cflag PARODD) {
+ /* stick mark */
+ new_lcr |= UART_LCR_SPAR;
+ } else {
+/* stick space */
+ new_lcr |= (UART_LCR_EPAR | UART_LCR_SPAR);
+ }
+ } else {
+ if (!(cflag PARODD)) {
+ /* even */
+ new_lcr |= UART_LCR_EPAR;
+ }
+ }
+ }
+
+ if (cflag CSTOPB)
+ new_lcr |= UART_LCR_STOP;
+ else
+ new_lcr = ~UART_LCR_STOP;
+
+
[PATCH v4 6/7] usb: serial: implement MCR/MSR function for F81232
This patch implement relative MCR/MSR function, such like
tiocmget()/tiocmset()/dtr_rts().
The update_mctrl() replace set_control_lines() to do MCR control
so we clean-up the set_control_lines() function.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 105 ++--
1 file changed, 83 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 248f40d..0ed7e36 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -38,11 +38,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define UART_STATE_TRANSIENT_MASK 0x74
#define UART_DCD 0x01
#define UART_DSR 0x02
-#define UART_BREAK_ERROR 0x04
#define UART_RING 0x08
-#define UART_FRAME_ERROR 0x10
-#define UART_PARITY_ERROR 0x20
-#define UART_OVERRUN_ERROR 0x40
#define UART_CTS 0x80
#define REGISTER_REQUEST 0xA0
@@ -55,6 +51,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS)
#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS)
#define LINE_CONTROL_REGISTER (0x03 + SERIAL_BASE_ADDRESS)
+#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
struct f81232_private {
spinlock_t lock;
@@ -165,6 +162,62 @@ static void f81232_read_msr(struct f81232_private *priv)
dev_dbg(dev-dev, %s: %x\n, __func__, priv-line_status);
}
+
+static inline int update_mctrl(struct f81232_private *port_priv,
+ unsigned int set, unsigned int clear)
+{
+ struct usb_device *dev = port_priv-port-serial-dev;
+ u8 urb_value;
+ int status;
+ unsigned long flags;
+
+ if (((set | clear) (TIOCM_DTR | TIOCM_RTS)) == 0) {
+ dev_dbg(dev-dev, %s fail - DTR|RTS %d\n,
+ __func__, __LINE__);
+ return 0; /* no change */
+ }
+
+ clear = ~set; /* 'set' takes precedence over 'clear' */
+ urb_value = 8 | port_priv-line_control;
+
+ if (clear TIOCM_DTR) {
+ urb_value = ~UART_MCR_DTR;
+ dev_dbg(dev-dev, clear DTR\n);
+ }
+
+ if (clear TIOCM_RTS) {
+ urb_value = ~UART_MCR_RTS;
+ dev_dbg(dev-dev, clear RTS\n);
+ }
+
+ if (set TIOCM_DTR) {
+ urb_value |= UART_MCR_DTR;
+ dev_dbg(dev-dev, set DTR\n);
+ }
+
+ if (set TIOCM_RTS) {
+ urb_value |= UART_MCR_RTS;
+ dev_dbg(dev-dev, set RTS\n);
+ }
+
+ dev_dbg(dev-dev, %s n:%x o:%x\n, __func__, urb_value,
+ port_priv-line_control);
+
+ status = f81232_set_register(dev, MODEM_CONTROL_REGISTER, urb_value);
+
+ if (status 0) {
+ dev_dbg(dev-dev, %s read MSR status 0\n, __func__);
+ } else {
+ spin_lock_irqsave(port_priv-lock, flags);
+ port_priv-line_control = urb_value;
+ spin_unlock_irqrestore(port_priv-lock, flags);
+ }
+
+ f81232_read_msr(port_priv);
+
+ return status;
+}
+
static void f81232_update_line_status(struct usb_serial_port *port,
unsigned char *data,
unsigned int actual_length)
@@ -261,12 +314,6 @@ static void f81232_process_read_urb(struct urb *urb)
}
-static int set_control_lines(struct usb_device *dev, u8 value)
-{
- /* FIXME - Stubbed out for now */
- return 0;
-}
-
static void f81232_break_ctl(struct tty_struct *tty, int break_state)
{
/* FIXME - Stubbed out for now */
@@ -383,14 +430,35 @@ static void f81232_set_termios(struct tty_struct *tty,
static int f81232_tiocmget(struct tty_struct *tty)
{
- /* FIXME - Stubbed out for now */
- return 0;
+ int r;
+ struct usb_serial_port *port = tty-driver_data;
+ struct f81232_private *port_priv = usb_get_serial_port_data(port);
+ unsigned long flags;
+ u8 mcr, msr;
+
+ spin_lock_irqsave(port_priv-lock, flags);
+ mcr = port_priv-line_control;
+ msr = port_priv-line_status;
+ spin_unlock_irqrestore(port_priv-lock, flags);
+
+ r = (mcr UART_MCR_DTR ? TIOCM_DTR : 0) |
+ (mcr UART_MCR_RTS ? TIOCM_RTS : 0) |
+ (msr UART_MSR_CTS ? TIOCM_CTS : 0) |
+ (msr UART_MSR_DCD ? TIOCM_CAR : 0) |
+ (msr UART_MSR_RI ? TIOCM_RI : 0) |
+ (msr UART_MSR_DSR ? TIOCM_DSR : 0);
+
+ return r;
}
static int f81232_tiocmset(struct tty_struct *tty,
unsigned int set, unsigned int clear)
{
- /* FIXME - Stubbed out for now */
+ struct usb_serial_port *port = tty-driver_data;
+
[PATCH v4 3/7] usb: serial: implement read IIR/MSR ep for F81232
The F81232 interrupt ep will continuously report IIR register value.
We had implement the interrupt callback to read IIR, If noticed with
MSR change, we will call worker to read MSR later.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 114 +---
1 file changed, 107 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 9ef9775..274120d 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -23,6 +23,7 @@
#include linux/uaccess.h
#include linux/usb.h
#include linux/usb/serial.h
+#include linux/serial_reg.h
static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1934, 0x0706) },
@@ -44,23 +45,112 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define UART_OVERRUN_ERROR 0x40
#define UART_CTS 0x80
+#define REGISTER_REQUEST 0xA0
+#define GET_REGISTER 0xc0
+#define SET_REGISTER 0x40
+#define F81232_USB_TIMEOUT 3000
+
+#define SERIAL_BASE_ADDRESS (0x0120)
+#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
struct f81232_private {
spinlock_t lock;
u8 line_control;
u8 line_status;
+
+ struct work_struct int_worker;
+ struct usb_serial_port *port;
};
+static inline int f81232_get_register(struct usb_device *dev,
+ u16 reg, u8 *data)
+{
+ int status;
+
+ status = usb_control_msg(dev,
+usb_rcvctrlpipe(dev, 0),
+REGISTER_REQUEST,
+GET_REGISTER,
+reg,
+0,
+data,
+sizeof(*data),
+F81232_USB_TIMEOUT);
+
+ if (status 0) {
+ dev_dbg(dev-dev,
+ %s status: %d\n, __func__, status);
+ }
+
+ return status;
+}
+
+static void f81232_read_msr(struct f81232_private *priv)
+{
+ int status;
+ unsigned long flags;
+ u8 current_msr, old_msr;
+ struct usb_device *dev = priv-port-serial-dev;
+ struct tty_struct *tty;
+
+ status = f81232_get_register(dev, MODEM_STATUS_REGISTER, current_msr);
+
+ if (status 0) {
+ dev_dbg(dev-dev, %s fail, status: %d\n, __func__, status);
+ return;
+ }
+
+ spin_lock_irqsave(priv-lock, flags);
+ old_msr = priv-line_status;
+ spin_unlock_irqrestore(priv-lock, flags);
+
+ if (current_msr UART_MSR_ANY_DELTA) {
+ tty = tty_port_tty_get(priv-port-port);
+
+ if (tty) {
+ if (current_msr UART_MSR_DDCD) {
+ usb_serial_handle_dcd_change(priv-port,
+ tty, current_msr UART_MSR_DCD);
+ }
+
+ tty_kref_put(tty);
+ }
+
+ spin_lock_irqsave(priv-lock, flags);
+ priv-line_status = current_msr;
+ spin_unlock_irqrestore(priv-lock, flags);
+
+ wake_up_interruptible(priv-port-port.delta_msr_wait);
+ }
+
+ dev_dbg(dev-dev, %s: %x\n, __func__, priv-line_status);
+}
static void f81232_update_line_status(struct usb_serial_port *port,
unsigned char *data,
unsigned int actual_length)
{
- /*
-* FIXME: Update port-icount, and call
-*
-* wake_up_interruptible(port-port.delta_msr_wait);
-*
-*on MSR changes.
-*/
+ struct f81232_private *priv = usb_get_serial_port_data(port);
+ struct usb_device *dev = port-serial-dev;
+
+ if (!actual_length)
+ return;
+
+ switch (data[0] 0x07) {
+ case 0x00: /* msr change */
+ dev_dbg(dev-dev, IIR: MSR Change: %x\n, data[0]);
+ schedule_work(priv-int_worker);
+ break;
+
+ case 0x02: /* tx-empty */
+ break;
+
+ case 0x04: /* rx data available */
+ break;
+
+ case 0x06: /* lsr change */
+ /* we can forget it. the LSR will read from bulk-in */
+ dev_dbg(dev-dev, IIR: LSR Change: %x\n, data[0]);
+ break;
+ }
}
static void f81232_read_int_callback(struct urb *urb)
@@ -270,6 +360,14 @@ static int f81232_ioctl(struct tty_struct *tty,
return -ENOIOCTLCMD;
}
+static void f81232_int_work_wq(struct work_struct *work)
+{
+ struct f81232_private *priv =
+ container_of(work, struct f81232_private, int_worker);
+
+ f81232_read_msr(priv);
+}
+
static int f81232_port_probe(struct usb_serial_port *port)
{
struct f81232_private *priv;
@@ -279,10 +377,12 @@ static int f81232_port_probe(struct usb_serial_port *port)
[PATCH v4 4/7] usb: serial: reimplement RX bulk-in ep for F81232
The F81232 bulk-in is RX data channel. Data format is
[LSR+Data][LSR+Data]. , We had reimplemented in this patch.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 47 +++--
1 file changed, 15 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 274120d..12e1ae4 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -194,47 +194,30 @@ exit:
static void f81232_process_read_urb(struct urb *urb)
{
struct usb_serial_port *port = urb-context;
- struct f81232_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb-transfer_buffer;
char tty_flag = TTY_NORMAL;
- unsigned long flags;
- u8 line_status;
+ u8 line_status = 0;
int i;
- /* update line status */
- spin_lock_irqsave(priv-lock, flags);
- line_status = priv-line_status;
- priv-line_status = ~UART_STATE_TRANSIENT_MASK;
- spin_unlock_irqrestore(priv-lock, flags);
-
if (!urb-actual_length)
return;
- /* break takes precedence over parity, */
- /* which takes precedence over framing errors */
- if (line_status UART_BREAK_ERROR)
- tty_flag = TTY_BREAK;
- else if (line_status UART_PARITY_ERROR)
- tty_flag = TTY_PARITY;
- else if (line_status UART_FRAME_ERROR)
- tty_flag = TTY_FRAME;
- dev_dbg(port-dev, %s - tty_flag = %d\n, __func__, tty_flag);
-
- /* overrun is special, not associated with a char */
- if (line_status UART_OVERRUN_ERROR)
- tty_insert_flip_char(port-port, 0, TTY_OVERRUN);
-
- if (port-port.console port-sysrq) {
- for (i = 0; i urb-actual_length; ++i)
- if (!usb_serial_handle_sysrq_char(port, data[i]))
- tty_insert_flip_char(port-port, data[i],
- tty_flag);
- } else {
- tty_insert_flip_string_fixed_flag(port-port, data, tty_flag,
- urb-actual_length);
+ /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
+
+ if (urb-actual_length = 2) {
+
+ for (i = 0 ; i urb-actual_length ; i += 2) {
+ line_status |= data[i+0];
+ tty_insert_flip_string_fixed_flag(port-port,
+ data[i+1], tty_flag, 1);
+ }
+
+ if (unlikely(line_status UART_LSR_OE))
+ tty_insert_flip_char(port-port, 0, TTY_OVERRUN);
+
+ tty_flip_buffer_push(port-port);
}
- tty_flip_buffer_push(port-port);
}
static int set_control_lines(struct usb_device *dev, u8 value)
--
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 v1] ehci-pci: disable for Intel MID platforms
On Thu, Jan 29, 2015 at 10:44:48AM -0500, Alan Stern wrote: On Thu, 29 Jan 2015, Peter Chen wrote: Then, it is strange. Do we need even two glue layer drivers for pci device? Look at usb/chipidea/ci_hdrc_pci.c it has pci_register_driver, and its host driver will call ehci_init_driver, it is definitely duplicated with usb/host/ehci-pci.c. ehci-pci.c is a driver for a USB Host Controller, whereas ci_hdrc_pci.c is a driver for a USB Device Controller. In fact, it is not, ci_hdrc_pci is the pci glue layer for chipidea driver. I am just wonder andy's v2 change is suitable or not, the right way should not call ehci_pci_init at all. The chipidea driver is structured in an odd way. It looks like the PCI device combines a host controller and a device controller (and maybe even an OTG controller) into a single device. Any problems for that? That's why the chipidea driver has to duplicate ehci-pci.c and register various platform devices. If ehci-pci were allowed to bind to the device then the gadget controller (and OTG controller?) would be unusable, because ehci-pci doesn't know how to use them. If the chipidea has host function, it doesn't need any drivers at usb/host/ehci-*.c, the v1 patch for this thread, it just doesn't compile ehci-pci.c, and it should work too. 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. -- 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
[PATCH v4 7/7] usb: serial: modify ioctl TIOCGSERIAL for F81232
Set correct product type from 16654 to 16550A and
fix the ioctl TIOCGSERIAL return struct values.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 0ed7e36..4d3aba8 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -518,13 +518,18 @@ static int f81232_ioctl(struct tty_struct *tty,
switch (cmd) {
case TIOCGSERIAL:
- memset(ser, 0, sizeof ser);
- ser.type = PORT_16654;
+ memset(ser, 0, sizeof(ser));
+ ser.flags = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
+ ser.xmit_fifo_size = port-bulk_out_size;
+ ser.close_delay = 5*HZ;
+ ser.closing_wait= 30*HZ;
+
+ ser.type = PORT_16550A;
ser.line = port-minor;
ser.port = port-port_number;
- ser.baud_base = 460800;
+ ser.baud_base = 115200;
- if (copy_to_user((void __user *)arg, ser, sizeof ser))
+ if (copy_to_user((void __user *)arg, ser, sizeof(ser)))
return -EFAULT;
return 0;
--
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 v4 1/7] usb: serial: modify bulk-in/out size for F81232
The F81232 real bulk-in/out ep buffer size is 64Bytes
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c5dc233..4f42e9d 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -304,8 +304,8 @@ static struct usb_serial_driver f81232_device = {
},
.id_table = id_table,
.num_ports =1,
- .bulk_in_size = 256,
- .bulk_out_size =256,
+ .bulk_in_size = 64,
+ .bulk_out_size =64,
.open = f81232_open,
.close =f81232_close,
.dtr_rts = f81232_dtr_rts,
--
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 v4 2/7] usb: serial: modify author for F81232
add co-author and fix no '' in greg kh's email
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 4f42e9d..9ef9775 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -330,5 +330,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
module_usb_serial_driver(serial_drivers, id_table);
MODULE_DESCRIPTION(Fintek F81232 USB to serial adaptor driver);
-MODULE_AUTHOR(Greg Kroah-Hartman gre...@linuxfoundation.org);
+MODULE_AUTHOR(Greg Kroah-Hartman gre...@linuxfoundation.org);
+MODULE_AUTHOR(Peter Hong peter_h...@fintek.com.tw);
MODULE_LICENSE(GPL v2);
--
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
