Re: [PATCH v2 4/5] usb: common: otg-fsm: add HNP polling support
On Thu, Mar 12, 2015 at 10:30:23AM +0800, Li Jun wrote:
> Adds HNP polling timer when transits to host state, the OTG status request
> will be sent to peripheral after timeout, if host request flag is set, it will
> switch to peripheral state, otherwise it will repeat HNP polling every 1.5s
> and
> maintain the current session.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/common/usb-otg-fsm.c | 93
> ++
> include/linux/usb/otg-fsm.h | 14 ++
> 2 files changed, 107 insertions(+)
>
> diff --git a/drivers/usb/common/usb-otg-fsm.c
> b/drivers/usb/common/usb-otg-fsm.c
> index 61d538a..965b258 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -78,6 +78,8 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
> fsm->b_srp_done = 0;
> break;
> case OTG_STATE_B_PERIPHERAL:
> + if (fsm->otg->gadget)
> + fsm->otg->gadget->host_request_flag = 0;
> break;
> case OTG_STATE_B_WAIT_ACON:
> otg_del_timer(fsm, B_ASE0_BRST);
> @@ -107,6 +109,8 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
> case OTG_STATE_A_PERIPHERAL:
> otg_del_timer(fsm, A_BIDL_ADIS);
> fsm->a_bidl_adis_tmout = 0;
> + if (fsm->otg->gadget)
> + fsm->otg->gadget->host_request_flag = 0;
> break;
> case OTG_STATE_A_WAIT_VFALL:
> otg_del_timer(fsm, A_WAIT_VFALL);
> @@ -120,6 +124,93 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
> }
> }
>
> +static void otg_hnp_polling_work(struct work_struct *work)
> +{
> + struct otg_fsm *fsm = container_of(work, struct otg_fsm,
> + hnp_polling_work);
> + struct usb_device *udev;
> + u8 host_req_flag;
> + enum usb_otg_state state = fsm->otg->state;
> + int retval;
> +
> + if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
> + return;
> +
> + udev = usb_hub_find_child(fsm->otg->host->root_hub, 1);
> + if (!udev) {
> + dev_err(fsm->otg->host->controller,
> + "no usb dev connected, can't start HNP polling\n");
> + return;
> + }
> +
> + /* Get host request flag from connected USB device */
> + retval = usb_control_msg(udev,
> + usb_rcvctrlpipe(udev, 0),
> + USB_REQ_GET_STATUS,
> + USB_DIR_IN | USB_RECIP_DEVICE,
> + 0,
> + OTG_STS_SELECTOR,
> + &host_req_flag,
> + 1,
> + USB_CTRL_GET_TIMEOUT);
> + if (retval != 1) {
> + dev_err(&udev->dev, "Get one byte OTG status failed\n");
> + return;
> + }
> +
> + if (host_req_flag == 0) {
> + /* Continue HNP polling */
> + mod_timer(&fsm->hnp_polling_timer,
> + jiffies + msecs_to_jiffies(T_HOST_REQ_POLL));
> + return;
> + } else if (host_req_flag != HOST_REQUEST_FLAG) {
> + dev_err(&udev->dev, "host request flag %d is invalid\n",
> + host_req_flag);
> + return;
> + }
> +
> + /* Host request flag is set */
> + if (state == OTG_STATE_A_HOST) {
> + /* Set b_hnp_enable */
> + if (!fsm->otg->host->b_hnp_enable) {
> + retval = usb_control_msg(udev,
> + usb_sndctrlpipe(udev, 0),
> + USB_REQ_SET_FEATURE, 0,
> + USB_DEVICE_B_HNP_ENABLE,
> + 0, NULL, 0,
> + USB_CTRL_SET_TIMEOUT);
> + if (retval < 0) {
> + dev_err(&udev->dev,
> + "can't enable HNP %d\n", retval);
> + return;
> + }
> + fsm->otg->host->b_hnp_enable = 1;
> + }
> +
> + fsm->a_bus_req = 0;
> + } else if (state == OTG_STATE_B_HOST) {
> + fsm->b_bus_req = 0;
> + }
> +
> + otg_statemachine(fsm);
> +}
> +
> +static void hnp_polling_timer_work(unsigned long arg)
> +{
> + struct otg_fsm *fsm = (struct otg_fsm *)arg;
> +
> + schedule_work(&fsm->hnp_polling_work);
> +}
> +
> +static void otg_start_hnp_polling(struct otg_fsm *fsm)
> +{
> + INIT_WORK(&fsm->hnp_polling_work, otg_hnp_polling_work);
> + setup_timer(&fsm->hnp_polling_timer, hnp_polling_timer_work,
> + (unsigned long)fsm);
The above two is one-tim
Re: linux-next: manual merge of the net-next tree with the vfs tree
From: Al Viro
Date: Fri, 13 Mar 2015 03:56:09 +
> On Thu, Mar 12, 2015 at 11:24:26PM -0400, David Miller wrote:
>> From: Stephen Rothwell
>> Date: Fri, 13 Mar 2015 13:15:43 +1100
>>
>> > Today's linux-next merge of the net-next tree got a conflict in
>> > net/socket.c between commits 005139a14660 ("fs: remove ki_nbytes") and
>> > e9eab93cc2dc ("fs: don't allow to complete sync iocbs through
>> > aio_complete") from the vfs tree and commit 1b784140474e ("net: Remove
>> > iocb argument from sendmsg and recvmsg") from the net-next tree.
>> >
>> > I fixed it up (mainly using the net-next version - see below) and can
>> > carry the fix as necessary (no action is required).
>>
>> Al, how do you want to resolve this?
>
> Hmm... I could backmerge 1b784140474e4fc94281a49e96c67d29df0efbde into
> vfs.git#for-next, of course, but you've got quite a pile of stuff in front
> of it... FWIW, the conflict resolution proposed by Stephen is correct;
> the question is what should go into which tree.
>
> Actually, prereqs of the commit in question on vfs.git side are mostly
> -stable fodder; all it really needs is vfs.git#gadget and I was planning
> to send that to Linus - fixes for leaks and use-after-free in gadgetfs
> that had been there since forever, plus fixes for regression since 3.18
> (->f_op flipping that had always been fishy and outright broke when we
> started to FMODE_CAN_READ/FMODE_CAN_WRITE). USB folks seem to be OK
> with it. Christoph's patch isn't a regression fix, but seeing that it's
> (a) trivial and (b) ends up causing merge headache... Maybe it would
> make sense to pull it into mainline and resolve the conflict on backmerge
> from mainline to net-next. Linus? I've pushed that (gadget + ki_nbytes)
> into vfs.git#for-linus-2; would you be OK with pulling that?
Push your stuff to Linus, then I'll solve all of this by merging
Linus --> net --> net-next at some point, ok?
Meanwhile Stephen's fix will carry us over until then.
THanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the net-next tree with the vfs tree
Hi Al,
On Fri, 13 Mar 2015 03:56:09 + Al Viro wrote:
>
> On Thu, Mar 12, 2015 at 11:24:26PM -0400, David Miller wrote:
> > From: Stephen Rothwell
> > Date: Fri, 13 Mar 2015 13:15:43 +1100
> >
> > > Today's linux-next merge of the net-next tree got a conflict in
> > > net/socket.c between commits 005139a14660 ("fs: remove ki_nbytes") and
> > > e9eab93cc2dc ("fs: don't allow to complete sync iocbs through
> > > aio_complete") from the vfs tree and commit 1b784140474e ("net: Remove
> > > iocb argument from sendmsg and recvmsg") from the net-next tree.
> > >
> > > I fixed it up (mainly using the net-next version - see below) and can
> > > carry the fix as necessary (no action is required).
> >
> > Al, how do you want to resolve this?
>
> Hmm... I could backmerge 1b784140474e4fc94281a49e96c67d29df0efbde into
> vfs.git#for-next, of course, but you've got quite a pile of stuff in front
> of it... FWIW, the conflict resolution proposed by Stephen is correct;
> the question is what should go into which tree.
>
> Actually, prereqs of the commit in question on vfs.git side are mostly
> -stable fodder; all it really needs is vfs.git#gadget and I was planning
> to send that to Linus - fixes for leaks and use-after-free in gadgetfs
> that had been there since forever, plus fixes for regression since 3.18
> (->f_op flipping that had always been fishy and outright broke when we
> started to FMODE_CAN_READ/FMODE_CAN_WRITE). USB folks seem to be OK
> with it. Christoph's patch isn't a regression fix, but seeing that it's
> (a) trivial and (b) ends up causing merge headache... Maybe it would
> make sense to pull it into mainline and resolve the conflict on backmerge
> from mainline to net-next. Linus? I've pushed that (gadget + ki_nbytes)
> into vfs.git#for-linus-2; would you be OK with pulling that?
>
> It's on
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus-2
>
> Shortlog:
> Al Viro (8):
> new helper: dup_iter()
> move iov_iter.c from mm/ to lib/
> gadget/function/f_fs.c: close leaks
> gadget/function/f_fs.c: use put iov_iter into io_data
> gadget/function/f_fs.c: switch to ->{read,write}_iter()
> gadgetfs: use-after-free in ->aio_read()
> gadget: switch ep_io_operations to ->read_iter/->write_iter
> gadgetfs: get rid of flipping ->f_op in ep_config()
>
> Alan Stern (1):
> gadgetfs: really get rid of switching ->f_op
>
> Christoph Hellwig (1):
> fs: remove ki_nbytes
There is also a conflict with e9eab93cc2dc ("fs: don't allow to
complete sync iocbs through aio_complete"), though it doesn't show up
in the resolution since I I just used the next-next tree bits. So a
common branch containing that as well could be merged into both trees.
But none of this is really that complex, maybe worth a hint to Linus
during the merge window. Unless there is more planned for that file?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpShk8EDSMSE.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the net-next tree with the vfs tree
On Thu, Mar 12, 2015 at 11:24:26PM -0400, David Miller wrote:
> From: Stephen Rothwell
> Date: Fri, 13 Mar 2015 13:15:43 +1100
>
> > Today's linux-next merge of the net-next tree got a conflict in
> > net/socket.c between commits 005139a14660 ("fs: remove ki_nbytes") and
> > e9eab93cc2dc ("fs: don't allow to complete sync iocbs through
> > aio_complete") from the vfs tree and commit 1b784140474e ("net: Remove
> > iocb argument from sendmsg and recvmsg") from the net-next tree.
> >
> > I fixed it up (mainly using the net-next version - see below) and can
> > carry the fix as necessary (no action is required).
>
> Al, how do you want to resolve this?
Hmm... I could backmerge 1b784140474e4fc94281a49e96c67d29df0efbde into
vfs.git#for-next, of course, but you've got quite a pile of stuff in front
of it... FWIW, the conflict resolution proposed by Stephen is correct;
the question is what should go into which tree.
Actually, prereqs of the commit in question on vfs.git side are mostly
-stable fodder; all it really needs is vfs.git#gadget and I was planning
to send that to Linus - fixes for leaks and use-after-free in gadgetfs
that had been there since forever, plus fixes for regression since 3.18
(->f_op flipping that had always been fishy and outright broke when we
started to FMODE_CAN_READ/FMODE_CAN_WRITE). USB folks seem to be OK
with it. Christoph's patch isn't a regression fix, but seeing that it's
(a) trivial and (b) ends up causing merge headache... Maybe it would
make sense to pull it into mainline and resolve the conflict on backmerge
from mainline to net-next. Linus? I've pushed that (gadget + ki_nbytes)
into vfs.git#for-linus-2; would you be OK with pulling that?
It's on
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus-2
Shortlog:
Al Viro (8):
new helper: dup_iter()
move iov_iter.c from mm/ to lib/
gadget/function/f_fs.c: close leaks
gadget/function/f_fs.c: use put iov_iter into io_data
gadget/function/f_fs.c: switch to ->{read,write}_iter()
gadgetfs: use-after-free in ->aio_read()
gadget: switch ep_io_operations to ->read_iter/->write_iter
gadgetfs: get rid of flipping ->f_op in ep_config()
Alan Stern (1):
gadgetfs: really get rid of switching ->f_op
Christoph Hellwig (1):
fs: remove ki_nbytes
Diffstat:
drivers/usb/gadget/function/f_fs.c | 204 +++-
drivers/usb/gadget/legacy/inode.c | 466 +++--
fs/aio.c | 34 +--
fs/ceph/file.c | 2 +-
fs/nfs/direct.c| 2 +-
fs/ocfs2/file.c| 8 +-
fs/read_write.c| 8 -
fs/udf/file.c | 2 +-
include/linux/aio.h| 1 -
include/linux/uio.h| 2 +
kernel/printk/printk.c | 2 +-
lib/Makefile | 2 +-
{mm => lib}/iov_iter.c | 15 ++
mm/Makefile| 2 +-
mm/page_io.c | 1 -
net/socket.c | 6 +-
16 files changed, 319 insertions(+), 438 deletions(-)
rename {mm => lib}/iov_iter.c (97%)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] usb: chipidea: udc: add OTG status request handling
On Thu, Mar 12, 2015 at 11:04:09AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 12, 2015 at 10:30:21AM +0800, Li Jun wrote:
> > From: Li Jun
> >
> > Peripheral answers OTG status selector request from host according to
> > host_request_flag of gadget, length is 1.
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/chipidea/udc.c | 28 +++-
> > 1 file changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 4254792..eed66bc 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -831,7 +831,17 @@ __acquires(hwep->lock)
> > return -ENOMEM;
> >
> > req->complete = isr_get_status_complete;
> > - req->length = 2;
> > + if (setup->wIndex == OTG_STS_SELECTOR) {
> > + if (ci_otg_is_fsm_mode(ci)) {
> > + req->length = 1;
> > + } else {
> > + retval = -ENOTSUPP;
> > + goto err_free_req;
> > + }
> > + } else {
> > + req->length = 2;
> > + }
>
> this could still be done generically in composite.c
>
I suggested it at v1, but after thinking more, we have handled
DEVICE request type at individual udc driver, like remote wakeup,
self-power support, so it is reasonable we handle get_status that
if we support hnp polling at udc driver, since it is controller
driver's capabilities.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] usb: chipidea: udc: add OTG status request handling
On Thu, Mar 12, 2015 at 10:30:21AM +0800, Li Jun wrote:
> From: Li Jun
>
> Peripheral answers OTG status selector request from host according to
> host_request_flag of gadget, length is 1.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/udc.c | 28 +++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 4254792..eed66bc 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -831,7 +831,17 @@ __acquires(hwep->lock)
> return -ENOMEM;
>
> req->complete = isr_get_status_complete;
> - req->length = 2;
> + if (setup->wIndex == OTG_STS_SELECTOR) {
It seems you define OTG_STS_SELECTOR at your 4/5, move it
to this one to avoid 'git bisect' problem.
> + if (ci_otg_is_fsm_mode(ci)) {
> + req->length = 1;
> + } else {
> + retval = -ENOTSUPP;
> + goto err_free_req;
> + }
If we don't support it, why not stall it?
> + } else {
> + req->length = 2;
> + }
> +
> req->buf = kzalloc(req->length, gfp_flags);
> if (req->buf == NULL) {
> retval = -ENOMEM;
> @@ -839,8 +849,15 @@ __acquires(hwep->lock)
> }
>
> if ((setup->bRequestType & USB_RECIP_MASK) == USB_RECIP_DEVICE) {
> - *(u16 *)req->buf = (ci->remote_wakeup << 1) |
> - ci->gadget.is_selfpowered;
> + if (setup->wIndex == OTG_STS_SELECTOR) {
> + if (ci->gadget.host_request_flag)
> + *(u8 *)req->buf = HOST_REQUEST_FLAG;
> + else
> + *(u8 *)req->buf = 0;
> + } else {
> + *(u16 *)req->buf = (ci->remote_wakeup << 1) |
> + ci->gadget.is_selfpowered;
> + }
> } else if ((setup->bRequestType & USB_RECIP_MASK) \
> == USB_RECIP_ENDPOINT) {
> dir = (le16_to_cpu(setup->wIndex) & USB_ENDPOINT_DIR_MASK) ?
> @@ -1018,8 +1035,9 @@ __acquires(ci->lock)
> type != (USB_DIR_IN|USB_RECIP_ENDPOINT) &&
> type != (USB_DIR_IN|USB_RECIP_INTERFACE))
> goto delegate;
> - if (le16_to_cpu(req.wLength) != 2 ||
> - le16_to_cpu(req.wValue) != 0)
> + if ((le16_to_cpu(req.wLength) != 2 &&
> + le16_to_cpu(req.wLength) != 1) ||
> + le16_to_cpu(req.wValue) != 0)
> break;
> err = isr_get_status_response(ci, &req);
> break;
> --
> 1.7.9.5
>
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] usb: gadget: add host_requestf_flag in usb_gadget for OTG HNP
On Thu, Mar 12, 2015 at 10:30:20AM +0800, Li Jun wrote:
> From: Li Jun
>
> Adds host_request_flag for gadget to store host request information from
> application, which can be used to response to HNP polling from host.
typo, %s/response to/respond
>
> Signed-off-by: Li Jun
> ---
> include/linux/usb/gadget.h |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index e2f00fd..6443512 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -521,6 +521,8 @@ struct usb_gadget_ops {
> * only supports HNP on a different root port.
> * @b_hnp_enable: OTG device feature flag, indicating that the A-Host
> * enabled HNP support.
> + * @host_request_flag: OTG device feature flag, indicating if A-Peripheral
> + * or B-Peripheral wants to take host role.
> * @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
> * MaxPacketSize.
> * @is_selfpowered: if the gadget is self-powered.
> @@ -563,6 +565,7 @@ struct usb_gadget {
> unsignedb_hnp_enable:1;
> unsigneda_hnp_support:1;
> unsigneda_alt_hnp_support:1;
> + unsignedhost_request_flag:1;
> unsignedquirk_ep_out_aligned_size:1;
> unsignedis_selfpowered:1;
> };
> --
> 1.7.9.5
>
--
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 1/2] serial: 8250_pci: remove non-used var for F81504
Remove pci_fintek_setup() non-used var with calculation ciobase
Signed-off-by: Peter Hung
---
drivers/tty/serial/8250/8250_pci.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 892eb32..701b7b1 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1550,9 +1550,7 @@ static int pci_fintek_setup(struct serial_private *priv,
struct uart_8250_port *port, int idx)
{
struct pci_dev *pdev = priv->dev;
- unsigned long base;
unsigned long iobase;
- unsigned long ciobase = 0;
u8 config_base;
u32 bar_data[3];
@@ -1601,11 +1599,6 @@ static int pci_fintek_setup(struct serial_private *priv,
return -EINVAL;
}
- if (idx < 4) {
- base = pci_resource_start(priv->dev, 3);
- ciobase = (int)(base + (0x8 * idx));
- }
-
/* Get the io address dispatch from the BIOS */
pci_read_config_dword(pdev, 0x24, &bar_data[0]);
pci_read_config_dword(pdev, 0x20, &bar_data[1]);
@@ -1614,8 +1607,8 @@ static int pci_fintek_setup(struct serial_private *priv,
/* Calculate Real IO Port */
iobase = (bar_data[idx/4] & 0xffe0) + (idx % 4) * 8;
- dev_dbg(&pdev->dev, "%s: idx=%d iobase=0x%lx ciobase=0x%lx
config_base=0x%2x\n",
- __func__, idx, iobase, ciobase, config_base);
+ dev_dbg(&pdev->dev, "%s: idx=%d iobase=0x%lx config_base=0x%2x\n",
+ __func__, idx, iobase, config_base);
/* Enable UART I/O port */
pci_write_config_byte(pdev, config_base + 0x00, 0x01);
--
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 0/2] serial: 8250_pci: Fintek products patches
These series patches works for Fintek F81504/F81508/F81512 PCI to Serial Port. and patch 0002 is following with patch 0001. patch 0001 is just cleanup non-used source code. patch 0002 is major patch. The serial port of our product will failed after wakeup from S3(STR). It's due to when the system wakeup from S3(STR), this PCI device's configuration space from 0x40 to 0x40 + max_port * 0x08 should be re-configured. If had no re-configure, It's will all zero. We move all initialization from pci_fintek_setup() to pci_fintek_init() and set it to pci_serial_quirks struct .init section. It's will re-init this device when system wakeup from pciserial_resume_ports(). Peter Hung (2): serial: 8250_pci: remove non-used var for F81504 serial: 8250_pci: port failed after wakeup from S3 drivers/tty/serial/8250/8250_pci.c | 121 +++-- 1 file changed, 50 insertions(+), 71 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] serial: 8250_pci: port failed after wakeup from S3
Serial ports of F81504/F81508/F81512 will failed when wakeup from S3(STR).
It's due to when the system wakeup from S3(STR), this PCI device's
configuration space from 0x40 to 0x40 + max_port * 0x08 should be
re-configured.
We move all initialization from pci_fintek_setup() to pci_fintek_init() and
set it to pci_serial_quirks .init section. It's will re-init this device when
system wakeup from pciserial_resume_ports().
Signed-off-by: Peter Hung
---
drivers/tty/serial/8250/8250_pci.c | 114 -
1 file changed, 50 insertions(+), 64 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 701b7b1..cfa477f 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1545,91 +1545,74 @@ pci_brcm_trumanage_setup(struct serial_private *priv,
return ret;
}
-static int pci_fintek_setup(struct serial_private *priv,
- const struct pciserial_board *board,
- struct uart_8250_port *port, int idx)
+static int pci_fintek_init(struct pci_dev *dev)
{
- struct pci_dev *pdev = priv->dev;
unsigned long iobase;
- u8 config_base;
+ u32 max_port, i;
u32 bar_data[3];
+ u8 config_base;
- /*
-* Find each UARTs offset in PCI configuraion space
-*/
- switch (idx) {
- case 0:
- config_base = 0x40;
- break;
- case 1:
- config_base = 0x48;
- break;
- case 2:
- config_base = 0x50;
- break;
- case 3:
- config_base = 0x58;
- break;
- case 4:
- config_base = 0x60;
- break;
- case 5:
- config_base = 0x68;
+ switch (dev->device) {
+ case 0x1104: /* 4 ports */
+ case 0x1108: /* 8 ports */
+ max_port = dev->device & 0xff;
break;
- case 6:
- config_base = 0x70;
- break;
- case 7:
- config_base = 0x78;
- break;
- case 8:
- config_base = 0x80;
- break;
- case 9:
- config_base = 0x88;
- break;
- case 10:
- config_base = 0x90;
- break;
- case 11:
- config_base = 0x98;
+ case 0x1112: /* 12 ports */
+ max_port = 12;
break;
default:
- /* Unknown number of ports, get out of here */
return -EINVAL;
}
/* Get the io address dispatch from the BIOS */
- pci_read_config_dword(pdev, 0x24, &bar_data[0]);
- pci_read_config_dword(pdev, 0x20, &bar_data[1]);
- pci_read_config_dword(pdev, 0x1c, &bar_data[2]);
+ pci_read_config_dword(dev, 0x24, &bar_data[0]);
+ pci_read_config_dword(dev, 0x20, &bar_data[1]);
+ pci_read_config_dword(dev, 0x1c, &bar_data[2]);
+
+ for (i = 0; i < max_port; ++i) {
+ /* UART0 configuration offset start from 0x40 */
+ config_base = 0x40 + 0x08 * i;
+
+ /* Calculate Real IO Port */
+ iobase = (bar_data[i / 4] & 0xffe0) + (i % 4) * 8;
+
+ /* Enable UART I/O port */
+ pci_write_config_byte(dev, config_base + 0x00, 0x01);
+
+ /* Select 128-byte FIFO and 8x FIFO threshold */
+ pci_write_config_byte(dev, config_base + 0x01, 0x33);
- /* Calculate Real IO Port */
- iobase = (bar_data[idx/4] & 0xffe0) + (idx % 4) * 8;
+ /* LSB UART */
+ pci_write_config_byte(dev, config_base + 0x04,
+ (u8)(iobase & 0xff));
- dev_dbg(&pdev->dev, "%s: idx=%d iobase=0x%lx config_base=0x%2x\n",
- __func__, idx, iobase, config_base);
+ /* MSB UART */
+ pci_write_config_byte(dev, config_base + 0x05,
+ (u8)((iobase & 0xff00) >> 8));
- /* Enable UART I/O port */
- pci_write_config_byte(pdev, config_base + 0x00, 0x01);
+ pci_write_config_byte(dev, config_base + 0x06, dev->irq);
+ }
+
+ return max_port;
+}
- /* Select 128-byte FIFO and 8x FIFO threshold */
- pci_write_config_byte(pdev, config_base + 0x01, 0x33);
+static int pci_fintek_setup(struct serial_private *priv,
+ const struct pciserial_board *board,
+ struct uart_8250_port *port, int idx)
+{
+ struct pci_dev *pdev = priv->dev;
+ u8 config_base;
+ u16 iobase;
- /* LSB UART */
- pci_write_config_byte(pdev, config_base + 0x04, (u8)(iobase & 0xff));
+ config_base = 0x40 + 0x08 * idx;
- /* MSB UART */
- pci_write_config_byte(pdev, config_base + 0x05, (u8)((iobase & 0xff00)
>> 8));
+ /* Get the i
RE: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function
Hi,
> Hi,
>
> On Thu, Mar 12, 2015 at 05:40:56AM +, yoshihiro shimoda wrote:
> > Hi,
> >
< snip >
> > >
> > > try something like below:
> > >
> > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > index e0384af77e56..e9d75d85be59 100644
> > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > @@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
> > > /*
> > > * queue push/pop
> > > */
> > > -static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > +static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
> > >struct usbhsg_request *ureq,
> > >int status)
> > > {
> > > @@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > usb_gadget_giveback_request(&uep->ep, &ureq->req);
> > > }
> > >
> > > +static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > + struct usbhsg_request *ureq,
> > > + int status)
> > > +{
> > > + usbhs_lock(priv, flags);
> > > + __usbhsg_queue_pop(uep, ureq, status);
> > > + usbhs_unlock(priv, flags);
> > > +}
> > > +
> > > static void usbhsg_queue_done(struct usbhs_priv *priv, struct usbhs_pkt
> > > *pkt)
> > > {
> > > struct usbhs_pipe *pipe = pkt->pipe;
> > >
> > >
> > > then, for cases where lock is already held you call __usbhsg_queue_pop()
> > > and for all other cases, call usbhsg_queue_pop().
> >
> > Thank you for the suggestion. However, we cannot use this
> > usbhsg_queue_pop() because a gadget driver might call usb_ep_queue()
> > in the "complete" function and this driver calls usbhs_lock() in the
> > usb_ep_queue().
>
> right, in that case just call __usbhs_queue_pop() directly.
Yes. So, my understanding is that this driver always calls __usbhs_queue_pop()
because this driver cannot know that a gadget driver calls usb_ep_queue() or not
in the "complete" function.
> > Perhaps my explanation was bad, but this issue was caused by the
> > following conditions:
> > - I use the renesas_usbhs driver as udc.
> > - I use an old usb-dmac driver that the callback runs on a kthread.
> > - I use the ncm driver. In this environment, the ncm driver might
> > cause a spinlock suspected.
> >
> > As an old solution, I fixed the renesas_usbhs driver by this patch.
> > However, if I use a new usb-dmac driver that the callback runs on a
> > tasklet, I don't need this patch. (This is a new solution.)
>
> then differentiate based on some revision register or something like
> that ?
Sorry for the lack information. I am submitting this usb-dmac driver that
the callback runs on a tasklet now. This means that the driver is not
merged yet. So, I think that we don't need to differentiate.
Best regards,
Yoshihiro Shimoda
> --
> 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
[PATCH v3 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.
However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set, an "Event Ring is Full" event
will be posted to the last entry of the event ring, but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring. That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.
This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
Signed-off-by: Lu Baolu
Tested-by: Alistair Grant
Tested-by: Devin Heitmueller
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Change log:
v2: apply to all Intel xHC devices as suggested by Mathias
v3: add two Tested-by's
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fd53c9e..2af32e2 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -115,6 +115,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
+ xhci->quirks |= XHCI_AVOID_BEI;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
@@ -130,7 +131,6 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
* PPT chipsets.
*/
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
- xhci->quirks |= XHCI_AVOID_BEI;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
--
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 v2 18/22] usb: gadget: serial: %pf is only for function pointers
On Thu, Mar 12, 2015 at 6:46 PM, Scott Wood wrote: > Use %ps for actual addresses, otherwise you'll get bad output > on arches like ppc64 where %pf expects a function descriptor > (which is not what __builtin_return_address returns). > > Signed-off-by: Scott Wood > Cc: linux-usb@vger.kernel.org > Cc: Felipe Balbi > Cc: Fabio Estevam > CC: Sergei Shtylyov Reviewed-by: Fabio Estevam -- 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 18/22] usb: gadget: serial: %pf is only for function pointers
Use %ps for actual addresses, otherwise you'll get bad output
on arches like ppc64 where %pf expects a function descriptor
(which is not what __builtin_return_address returns).
Signed-off-by: Scott Wood
Cc: linux-usb@vger.kernel.org
Cc: Felipe Balbi
Cc: Fabio Estevam
CC: Sergei Shtylyov
---
v2: Fix commit message to reflect that this patch is about %pf, not %pF,
and to clarify (as requested) that __builtin_return_address does not
return a function pointer.
drivers/usb/gadget/function/u_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index 491082a..89179ab 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -912,7 +912,7 @@ static int gs_put_char(struct tty_struct *tty, unsigned
char ch)
unsigned long flags;
int status;
- pr_vdebug("gs_put_char: (%d,%p) char=0x%x, called from %pf\n",
+ pr_vdebug("gs_put_char: (%d,%p) char=0x%x, called from %ps\n",
port->port_num, tty, ch, __builtin_return_address(0));
spin_lock_irqsave(&port->port_lock, flags);
--
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 v4 0/5] usb/gadget: independent registration of gadgets and gadget drivers
This patchset adds independent registration of gadgets and gadget drivers to udc-core. This is very useful for built-in modules into kernel case since it's possible situation that gadget driver is probing at a time when no gadgets are registered in udc-core. In this case instead of silently failing without of any attempt to recover, with independent registration of gadgets and gadget drivers there is no matter in which order gadgets and gadget drivers are probed/registered. This patch has side-effect on gadget drivers that had __init/__exit attributes on some paths like bind/unbind and (since bind/unbind may happen at any time) should not use them now. This is covered by forth patch = v4: - misc fixes - addressed Alan's and Sergei's comments - rebased onto latest 'next' branch of Felipe Balbi's tree v3: - addressed Alan's comments - now UDC name and pending gadget drivers list is a part of struct usb_gadget_driver. - removed usb_udc_attach_driver() function that became unused and not needed now v2: - changed first patch to have only deferred probe part (because Gadget Bus seems to be better variant when some more complicated behavior will be required) - rebased to latest 'next' branch of Felipe Balbi's tree Ruslan Bilovol (5): usb: gadget: bind UDC by name passed via usb_gadget_driver structure usb: gadget: configfs: pass UDC name via usb_gadget_driver struct usb: gadget: udc-core: remove unused usb_udc_attach_driver() usb: gadget: legacy: don't use __init/__exit attributes for bind/unbind path usb: gadget: udc-core: independent registration of gadgets and gadget drivers drivers/usb/gadget/configfs.c| 27 +- drivers/usb/gadget/legacy/acm_ms.c | 6 +-- drivers/usb/gadget/legacy/audio.c| 6 +-- drivers/usb/gadget/legacy/cdc2.c | 6 +-- drivers/usb/gadget/legacy/dbgp.c | 2 +- drivers/usb/gadget/legacy/ether.c| 8 +-- drivers/usb/gadget/legacy/gmidi.c| 6 +-- drivers/usb/gadget/legacy/hid.c | 6 +-- drivers/usb/gadget/legacy/mass_storage.c | 4 +- drivers/usb/gadget/legacy/multi.c| 16 +++--- drivers/usb/gadget/legacy/ncm.c | 6 +-- drivers/usb/gadget/legacy/nokia.c| 6 +-- drivers/usb/gadget/legacy/printer.c | 6 +-- drivers/usb/gadget/legacy/serial.c | 2 +- drivers/usb/gadget/legacy/webcam.c | 4 +- drivers/usb/gadget/legacy/zero.c | 2 +- drivers/usb/gadget/udc/udc-core.c| 87 include/linux/usb/gadget.h | 8 ++- 18 files changed, 117 insertions(+), 91 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/5] usb: gadget: udc-core: remove unused usb_udc_attach_driver()
Now when last user of usb_udc_attach_driver() is switched
to passing UDC name via usb_gadget_driver struct, it's safe
to remove this function
Signed-off-by: Ruslan Bilovol
---
drivers/usb/gadget/udc/udc-core.c | 26 --
include/linux/usb/gadget.h| 2 --
2 files changed, 28 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index da738ee..3165d48 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -411,32 +411,6 @@ err1:
return ret;
}
-int usb_udc_attach_driver(const char *name, struct usb_gadget_driver *driver)
-{
- struct usb_udc *udc = NULL;
- int ret = -ENODEV;
-
- mutex_lock(&udc_lock);
- list_for_each_entry(udc, &udc_list, list) {
- ret = strcmp(name, dev_name(&udc->dev));
- if (!ret)
- break;
- }
- if (ret) {
- ret = -ENODEV;
- goto out;
- }
- if (udc->driver) {
- ret = -EBUSY;
- goto out;
- }
- ret = udc_bind_to_driver(udc, driver);
-out:
- mutex_unlock(&udc_lock);
- return ret;
-}
-EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
-
int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
{
struct usb_udc *udc = NULL;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 6d26657..b584ed2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -930,8 +930,6 @@ extern int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget
*gadget);
extern void usb_del_gadget_udc(struct usb_gadget *gadget);
-extern int usb_udc_attach_driver(const char *name,
- struct usb_gadget_driver *driver);
/*-*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
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.
Signed-off-by: Ruslan Bilovol
---
drivers/usb/gadget/udc/udc-core.c | 49 ---
include/linux/usb/gadget.h| 2 ++
2 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 3165d48..53571dd 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -48,8 +48,12 @@ struct usb_udc {
static struct class *udc_class;
static LIST_HEAD(udc_list);
+static LIST_HEAD(gadget_driver_pending_list);
static DEFINE_MUTEX(udc_lock);
+static int udc_bind_to_driver(struct usb_udc *udc,
+ struct usb_gadget_driver *driver);
+
/* - */
#ifdef CONFIG_HAS_DMA
@@ -243,6 +247,7 @@ int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget,
void (*release)(struct device *dev))
{
struct usb_udc *udc;
+ struct usb_gadget_driver *driver;
int ret = -ENOMEM;
udc = kzalloc(sizeof(*udc), GFP_KERNEL);
@@ -288,6 +293,18 @@ int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget,
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
+ /* pick up one of pending gadget drivers */
+ list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
+ if (!driver->udc_name || strcmp(driver->udc_name,
+ dev_name(&udc->dev)) == 0) {
+ ret = udc_bind_to_driver(udc, driver);
+ if (ret)
+ goto err4;
+ list_del(&driver->pending);
+ break;
+ }
+ }
+
mutex_unlock(&udc_lock);
return 0;
@@ -366,9 +383,16 @@ found:
list_del(&udc->list);
mutex_unlock(&udc_lock);
- if (udc->driver)
+ if (udc->driver) {
+ struct usb_gadget_driver *driver = udc->driver;
+
usb_gadget_remove_driver(udc);
+ mutex_lock(&udc_lock);
+ list_add(&driver->pending, &gadget_driver_pending_list);
+ mutex_unlock(&udc_lock);
+ }
+
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
device_unregister(&udc->dev);
@@ -426,11 +450,7 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver)
if (!ret)
break;
}
- if (ret)
- ret = -ENODEV;
- else if (udc->driver)
- ret = -EBUSY;
- else
+ if (!ret && !udc->driver)
goto found;
} else {
list_for_each_entry(udc, &udc_list, list) {
@@ -440,9 +460,12 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver)
}
}
- pr_debug("couldn't find an available UDC\n");
+ list_add_tail(&driver->pending, &gadget_driver_pending_list);
+ pr_info("udc-core: couldn't find an available UDC "
+ "- added [%s] to list of pending drivers\n",
+ driver->function);
mutex_unlock(&udc_lock);
- return ret;
+ return 0;
found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
@@ -468,6 +491,16 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver
*driver)
break;
}
+ if (ret) {
+ struct usb_gadget_driver *tmp;
+
+ list_for_each_entry(tmp, &gadget_driver_pending_list, pending)
+ if (tmp == driver) {
+ list_del(&driver->pending);
+ ret = 0;
+ break;
+ }
+ }
mutex_unlock(&udc_lock);
return ret;
}
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index b584ed2..ccf872f 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -823,6 +823,7 @@ static inline
[PATCH v4 2/5] usb: gadget: configfs: pass UDC name via usb_gadget_driver struct
Now when udc-core supports binding to specific UDC by passing
its name via 'udc_name' member of usb_gadget_driver struct,
switch to this generic approach.
Signed-off-by: Ruslan Bilovol
---
drivers/usb/gadget/configfs.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index c42765b..efad021 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -54,7 +54,6 @@ struct gadget_info {
struct list_head string_list;
struct list_head available_func;
- const char *udc_name;
#ifdef CONFIG_USB_OTG
struct usb_otg_descriptor otg;
#endif
@@ -230,21 +229,21 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct
gadget_info *gi,
static ssize_t gadget_dev_desc_UDC_show(struct gadget_info *gi, char *page)
{
- return sprintf(page, "%s\n", gi->udc_name ?: "");
+ return sprintf(page, "%s\n", gi->composite.gadget_driver.udc_name ?:
"");
}
static int unregister_gadget(struct gadget_info *gi)
{
int ret;
- if (!gi->udc_name)
+ if (!gi->composite.gadget_driver.udc_name)
return -ENODEV;
ret = usb_gadget_unregister_driver(&gi->composite.gadget_driver);
if (ret)
return ret;
- kfree(gi->udc_name);
- gi->udc_name = NULL;
+ kfree(gi->composite.gadget_driver.udc_name);
+ gi->composite.gadget_driver.udc_name = NULL;
return 0;
}
@@ -267,14 +266,16 @@ static ssize_t gadget_dev_desc_UDC_store(struct
gadget_info *gi,
if (ret)
goto err;
} else {
- if (gi->udc_name) {
+ if (gi->composite.gadget_driver.udc_name) {
ret = -EBUSY;
goto err;
}
- ret = usb_udc_attach_driver(name, &gi->composite.gadget_driver);
- if (ret)
+ gi->composite.gadget_driver.udc_name = name;
+ ret = usb_gadget_probe_driver(&gi->composite.gadget_driver);
+ if (ret) {
+ gi->composite.gadget_driver.udc_name = NULL;
goto err;
- gi->udc_name = name;
+ }
}
mutex_unlock(&gi->lock);
return len;
@@ -438,9 +439,9 @@ static int config_usb_cfg_unlink(
* remove the function.
*/
mutex_lock(&gi->lock);
- if (gi->udc_name)
+ if (gi->composite.gadget_driver.udc_name)
unregister_gadget(gi);
- WARN_ON(gi->udc_name);
+ WARN_ON(gi->composite.gadget_driver.udc_name);
list_for_each_entry(f, &cfg->func_list, list) {
if (f->fi == fi) {
@@ -917,10 +918,10 @@ static int os_desc_unlink(struct config_item *os_desc_ci,
struct usb_composite_dev *cdev = &gi->cdev;
mutex_lock(&gi->lock);
- if (gi->udc_name)
+ if (gi->composite.gadget_driver.udc_name)
unregister_gadget(gi);
cdev->os_desc_config = NULL;
- WARN_ON(gi->udc_name);
+ WARN_ON(gi->composite.gadget_driver.udc_name);
mutex_unlock(&gi->lock);
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 4/5] usb: gadget: legacy: don't use __init/__exit attributes for bind/unbind path
In order to prepare to independent gadgets and
gadget drivers registration in udc-core, some of the
functions can't have __init/__exit attributes (almost
only bind/unbind callbacks are affected)
Signed-off-by: Ruslan Bilovol
---
drivers/usb/gadget/legacy/acm_ms.c | 6 +++---
drivers/usb/gadget/legacy/audio.c| 6 +++---
drivers/usb/gadget/legacy/cdc2.c | 6 +++---
drivers/usb/gadget/legacy/dbgp.c | 2 +-
drivers/usb/gadget/legacy/ether.c| 8
drivers/usb/gadget/legacy/gmidi.c| 6 +++---
drivers/usb/gadget/legacy/hid.c | 6 +++---
drivers/usb/gadget/legacy/mass_storage.c | 4 ++--
drivers/usb/gadget/legacy/multi.c| 16
drivers/usb/gadget/legacy/ncm.c | 6 +++---
drivers/usb/gadget/legacy/nokia.c| 6 +++---
drivers/usb/gadget/legacy/printer.c | 6 +++---
drivers/usb/gadget/legacy/serial.c | 2 +-
drivers/usb/gadget/legacy/webcam.c | 4 ++--
drivers/usb/gadget/legacy/zero.c | 2 +-
15 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/gadget/legacy/acm_ms.c
b/drivers/usb/gadget/legacy/acm_ms.c
index c30b7b5..3a48aab 100644
--- a/drivers/usb/gadget/legacy/acm_ms.c
+++ b/drivers/usb/gadget/legacy/acm_ms.c
@@ -121,7 +121,7 @@ static struct usb_function *f_msg;
/*
* We _always_ have both ACM and mass storage functions.
*/
-static int __init acm_ms_do_config(struct usb_configuration *c)
+static int acm_ms_do_config(struct usb_configuration *c)
{
struct fsg_opts *opts;
int status;
@@ -174,7 +174,7 @@ static struct usb_configuration acm_ms_config_driver = {
/*-*/
-static int __init acm_ms_bind(struct usb_composite_dev *cdev)
+static int acm_ms_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
struct fsg_opts *opts;
@@ -249,7 +249,7 @@ fail_get_msg:
return status;
}
-static int __exit acm_ms_unbind(struct usb_composite_dev *cdev)
+static int acm_ms_unbind(struct usb_composite_dev *cdev)
{
usb_put_function(f_msg);
usb_put_function_instance(fi_msg);
diff --git a/drivers/usb/gadget/legacy/audio.c
b/drivers/usb/gadget/legacy/audio.c
index f46a395..ba95518 100644
--- a/drivers/usb/gadget/legacy/audio.c
+++ b/drivers/usb/gadget/legacy/audio.c
@@ -167,7 +167,7 @@ static const struct usb_descriptor_header *otg_desc[] = {
/*-*/
-static int __init audio_do_config(struct usb_configuration *c)
+static int audio_do_config(struct usb_configuration *c)
{
int status;
@@ -216,7 +216,7 @@ static struct usb_configuration audio_config_driver = {
/*-*/
-static int __init audio_bind(struct usb_composite_dev *cdev)
+static int audio_bind(struct usb_composite_dev *cdev)
{
#ifndef CONFIG_GADGET_UAC1
struct f_uac2_opts *uac2_opts;
@@ -276,7 +276,7 @@ fail:
return status;
}
-static int __exit audio_unbind(struct usb_composite_dev *cdev)
+static int audio_unbind(struct usb_composite_dev *cdev)
{
#ifdef CONFIG_GADGET_UAC1
if (!IS_ERR_OR_NULL(f_uac1))
diff --git a/drivers/usb/gadget/legacy/cdc2.c b/drivers/usb/gadget/legacy/cdc2.c
index 2e85d94..8d1985c 100644
--- a/drivers/usb/gadget/legacy/cdc2.c
+++ b/drivers/usb/gadget/legacy/cdc2.c
@@ -104,7 +104,7 @@ static struct usb_function_instance *fi_ecm;
/*
* We _always_ have both CDC ECM and CDC ACM functions.
*/
-static int __init cdc_do_config(struct usb_configuration *c)
+static int cdc_do_config(struct usb_configuration *c)
{
int status;
@@ -153,7 +153,7 @@ static struct usb_configuration cdc_config_driver = {
/*-*/
-static int __init cdc_bind(struct usb_composite_dev *cdev)
+static int cdc_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
struct f_ecm_opts *ecm_opts;
@@ -211,7 +211,7 @@ fail:
return status;
}
-static int __exit cdc_unbind(struct usb_composite_dev *cdev)
+static int cdc_unbind(struct usb_composite_dev *cdev)
{
usb_put_function(f_acm);
usb_put_function_instance(fi_serial);
diff --git a/drivers/usb/gadget/legacy/dbgp.c b/drivers/usb/gadget/legacy/dbgp.c
index 633683a..7c42b01 100644
--- a/drivers/usb/gadget/legacy/dbgp.c
+++ b/drivers/usb/gadget/legacy/dbgp.c
@@ -284,7 +284,7 @@ fail_1:
return -ENODEV;
}
-static int __init dbgp_bind(struct usb_gadget *gadget,
+static int dbgp_bind(struct usb_gadget *gadget,
struct usb_gadget_driver *driver)
{
int err, stp;
diff --git a/drivers/usb/gadget/legacy/ether.c
b/drivers/usb/gadget/legacy/ether.c
index c5fdc61..4283969 100644
--- a/drivers/usb/gadget/legacy/ether.c
+
[PATCH v4 1/5] usb: gadget: bind UDC by name passed via usb_gadget_driver structure
Introduce new 'udc_name' member to usb_gadget_driver structure.
The 'udc_name' is a name of UDC that usb_gadget_driver should
be bound to. If udc_name is NULL, it will be bound to any
available UDC.
Signed-off-by: Ruslan Bilovol
---
drivers/usb/gadget/udc/udc-core.c | 24 +++-
include/linux/usb/gadget.h| 4
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 5a81cb0..da738ee 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -440,21 +440,35 @@ EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
{
struct usb_udc *udc = NULL;
- int ret;
+ int ret = -ENODEV;
if (!driver || !driver->bind || !driver->setup)
return -EINVAL;
mutex_lock(&udc_lock);
- list_for_each_entry(udc, &udc_list, list) {
- /* For now we take the first one */
- if (!udc->driver)
+ if (driver->udc_name) {
+ list_for_each_entry(udc, &udc_list, list) {
+ ret = strcmp(driver->udc_name, dev_name(&udc->dev));
+ if (!ret)
+ break;
+ }
+ if (ret)
+ ret = -ENODEV;
+ else if (udc->driver)
+ ret = -EBUSY;
+ else
goto found;
+ } else {
+ list_for_each_entry(udc, &udc_list, list) {
+ /* For now we take the first one */
+ if (!udc->driver)
+ goto found;
+ }
}
pr_debug("couldn't find an available UDC\n");
mutex_unlock(&udc_lock);
- return -ENODEV;
+ return ret;
found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 02476b3..6d26657 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -821,6 +821,8 @@ static inline int usb_gadget_disconnect(struct usb_gadget
*gadget)
* @reset: Invoked on USB bus reset. It is mandatory for all gadget drivers
* and should be called in_interrupt.
* @driver: Driver model state for this driver.
+ * @udc_name: A name of UDC this driver should be bound to. If udc_name is
NULL,
+ * this driver will be bound to any available UDC.
*
* Devices are disabled till a gadget driver successfully bind()s, which
* means the driver will handle setup() requests needed to enumerate (and
@@ -881,6 +883,8 @@ struct usb_gadget_driver {
/* FIXME support safe rmmod */
struct device_driverdriver;
+
+ char*udc_name;
};
--
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] usb: dwc2: pci: Select the generic PHY for dwc2-pci driver
The dwc2-pci driver requires the generic PHY. This fixes undefined reference issues when it is not selected. Reported-by: kbuild test robot Signed-off-by: John Youn --- This fixes issue with commit 9024c495 on -next. John drivers/usb/dwc2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index 3db204f..1bcb36a 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -62,6 +62,7 @@ config USB_DWC2_PCI depends on PCI default n select USB_DWC2_PLATFORM + select NOP_USB_XCEIV help The Designware USB2.0 PCI interface module for controllers connected to a PCI bus. -- 2.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phy: Add a driver for dm816x USB PHY
* Rusty Russell [150311 18:15]: > Tony Lindgren writes: > > * Paul Bolle [150311 04:16]: > > Oh, it should be just GPL v2 like most of the kernel. Probably copied > > the header from some other phy driver, will update that instead. > > Well, all my code is explicitly v2 or later. > > I'll leave it someone else to try to figure out the stats. I vote for > Jon! It seems I nowadays prefer a mix of GPLv2 with just a sprinkle of the later! Keeps people guessing you know :) 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
Please kindly read my message
Please kindly read my message Hello it is with tears that i am writing to you i need your help and assistance am an aging widow suffering from long time cancer of the throat and I inherited from my late husband, the sum of 9. 5 Millions Nine Million Five Hundred Thousand Dollars and I need someone like you a foreign partner that will withdraw this money then use for better investments and charity in your country , i contacted you to do this because i am seriously sick and i will not have time to do all i have stated because of my health and the doctors have already told me that i have few time to live so please if you are intrested kindly let me knowimmediately so that we can proceed because i am really suffering from this illness cancer so please have mercy and pity on me and help me get my funds transferred. Warmest Regards, Mme.sandra Reply to noura_jo...@live.fr or honoresandran...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
On Thu, Mar 12, 2015 at 6:15 AM, Lu Baolu wrote:
> When a device with an isochronous endpoint is plugged into the Intel
> xHCI host controller, and the driver submits multiple frames per URB,
> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
> but the last TD for the URB. This causes the host controller to place
> an event on the event ring, but not send an interrupt. When the last
> TD for the URB completes, BEI is cleared, and we get an interrupt for
> the whole URB.
>
> However, under Intel xHCI host controllers, if the event ring is full
> of events from transfers with BEI set, an "Event Ring is Full" event
> will be posted to the last entry of the event ring, but no interrupt
> is generated. Host will cease all transfer and command executions and
> wait until software completes handling the pending events in the event
> ring. That means xHC stops, but event of "event ring is full" is not
> notified. As the result, the xHC looks like dead to user.
>
> This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
> it should be backported to kernels as old as 3.0, that contains the
> commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
>
> Signed-off-by: Lu Baolu
> Cc: sta...@vger.kernel.org
> ---
> drivers/usb/host/xhci-pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index fd53c9e..2af32e2 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -115,6 +115,7 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> xhci->quirks |= XHCI_LPM_SUPPORT;
> xhci->quirks |= XHCI_INTEL_HOST;
> + xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> pdev->device ==
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
> @@ -130,7 +131,6 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> * PPT chipsets.
> */
> xhci->quirks |= XHCI_SPURIOUS_REBOOT;
> - xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
> --
> 2.1.0
>
Looks good for me to (tested with an HVR-950q on a 2013 Macbook Pro (Haswell).
Tested by: Devin Heitmueller
Thanks for your help,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu wrote:
> When a device with an isochronous endpoint is plugged into the Intel
> xHCI host controller, and the driver submits multiple frames per URB,
> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
> but the last TD for the URB. This causes the host controller to place
> an event on the event ring, but not send an interrupt. When the last
> TD for the URB completes, BEI is cleared, and we get an interrupt for
> the whole URB.
>
> However, under Intel xHCI host controllers, if the event ring is full
> of events from transfers with BEI set, an "Event Ring is Full" event
> will be posted to the last entry of the event ring, but no interrupt
> is generated. Host will cease all transfer and command executions and
> wait until software completes handling the pending events in the event
> ring. That means xHC stops, but event of "event ring is full" is not
> notified. As the result, the xHC looks like dead to user.
>
> This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
> it should be backported to kernels as old as 3.0, that contains the
> commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
>
> Signed-off-by: Lu Baolu
> Cc: sta...@vger.kernel.org
> ---
> drivers/usb/host/xhci-pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index fd53c9e..2af32e2 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -115,6 +115,7 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> xhci->quirks |= XHCI_LPM_SUPPORT;
> xhci->quirks |= XHCI_INTEL_HOST;
> + xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> pdev->device ==
> PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
> @@ -130,7 +131,6 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> * PPT chipsets.
> */
> xhci->quirks |= XHCI_SPURIOUS_REBOOT;
> - xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
> --
> 2.1.0
>
> --
This works for me...
Computer: Dell XPS13 9333
USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
(prog-if 30 [XHCI])
Kernel: 3.19.1
USB Device: Hauppauge USB-Live2
Please let me know if I can help in any other way.
Tested-by: Alistair Grant
Thanks!
Alistair
--
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 0/2] usb: dwc2: add support for big-endian Lantiq SoCs
Here are two patches needed to add support for mips based big-endian SoCs made by Lantiq to dwc2 driver. The first patch converts the readl/writel io-accessors of dwc2 to big-endian friendly versions and was discussed on the linux-usb ml already earlier. The second patch adds default fifo parameters for Lantiq SoCs to dwc2 which is needed to support devices equipped with smaller fifo sizes. Note: The only reason for the second patch to exist is that dynamic calculation algorithm in dwc2_calculate_dynamic_fifo does not cope well with fifo sizes below certain limit. Changes since previous version: * Patches updated to apply to latest dwc2 code * Fixing wrong comment style (as pointed out by Felipe Balbi) Antti Seppälä (2): usb: dwc2: Use platform endianness when accessing registers usb: dwc2: Add default fifo sizes for Lantiq SoCs Documentation/devicetree/bindings/usb/dwc2.txt | 1 + drivers/usb/dwc2/core.c| 341 + drivers/usb/dwc2/core.h| 29 ++- drivers/usb/dwc2/core_intr.c | 73 +++--- drivers/usb/dwc2/gadget.c | 312 +++--- drivers/usb/dwc2/hcd.c | 138 +- drivers/usb/dwc2/hcd.h | 15 +- drivers/usb/dwc2/hcd_ddma.c| 10 +- drivers/usb/dwc2/hcd_intr.c| 82 +++--- drivers/usb/dwc2/hcd_queue.c | 10 +- drivers/usb/dwc2/platform.c| 29 +++ 11 files changed, 545 insertions(+), 495 deletions(-) -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: dwc2: Add default fifo sizes for Lantiq SoCs
Lantiq SoCs define the total_fifo_size to be 552 dwords which is too
small for algorithm in dwc2_calculate_dynamic_fifo to work properly.
This patch provides sensible defaults for fifo sizes for Lantiq SoCs
to be used in dwc2 driver. The default values are taken from original
ifx-hcd driver.
Signed-off-by: Antti Seppälä
Signed-off-by: Vincent Pelletier
---
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/platform.c| 29 ++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
b/Documentation/devicetree/bindings/usb/dwc2.txt
index fd132cb..9182a9f 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -7,6 +7,7 @@ Required properties:
- rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
- "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc;
- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
+ - "lantiq,dwc2": DWC2 USB controllers found in Lantiq SoCs;
- snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index ae095f0..99d6b60 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -106,6 +106,34 @@ static const struct dwc2_core_params params_rk3066 = {
.uframe_sched = -1,
};
+static const struct dwc2_core_params params_ltq = {
+ .otg_cap= -1,
+ .otg_ver= -1,
+ .dma_enable = -1,
+ .dma_desc_enable= -1,
+ .speed = -1,
+ .enable_dynamic_fifo= -1,
+ .en_multiple_tx_fifo= -1,
+ .host_rx_fifo_size = 240, /* 240 DWORDs */
+ .host_nperio_tx_fifo_size = 240, /* 240 DWORDs */
+ .host_perio_tx_fifo_size= 32, /* 32 DWORDs */
+ .max_transfer_size = -1,
+ .max_packet_count = -1,
+ .host_channels = -1,
+ .phy_type = -1,
+ .phy_utmi_width = -1,
+ .phy_ulpi_ddr = -1,
+ .phy_ulpi_ext_vbus = -1,
+ .i2c_enable = -1,
+ .ulpi_fs_ls = -1,
+ .host_support_fs_ls_low_power = -1,
+ .host_ls_low_power_phy_clk = -1,
+ .ts_dline = -1,
+ .reload_ctl = -1,
+ .ahbcfg = -1,
+ .uframe_sched = -1,
+};
+
/**
* dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
* DWC_otg driver
@@ -130,6 +158,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
{ .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
+ { .compatible = "lantiq,dwc2", .data = ¶ms_ltq },
{ .compatible = "snps,dwc2", .data = NULL },
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
{},
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] usb: dwc2: Use platform endianness when accessing registers
This patch switches calls to readl/writel to their
dwc2_readl/dwc2_writel equivalents which preserve platform endianness.
This patch is necessary to access dwc2 registers correctly on big endian
systems such as the mips based SoCs made by Lantiq. Then dwc2 can be
used to replace ifx-hcd driver for Lantiq platforms found e.g. in
OpenWrt.
The patch was autogenerated with the following commands:
$EDITOR core.h
sed -i "s/\/dwc2_readl/g" *.c hcd.h hw.h
sed -i "s/\/dwc2_writel/g" *.c hcd.h hw.h
Some files were then hand-edited to fix checkpatch.pl warnings about
too long lines.
Signed-off-by: Antti Seppälä
Signed-off-by: Vincent Pelletier
---
drivers/usb/dwc2/core.c | 341 ++-
drivers/usb/dwc2/core.h | 29 +++-
drivers/usb/dwc2/core_intr.c | 73 -
drivers/usb/dwc2/gadget.c| 312 +++
drivers/usb/dwc2/hcd.c | 138 -
drivers/usb/dwc2/hcd.h | 15 +-
drivers/usb/dwc2/hcd_ddma.c | 10 +-
drivers/usb/dwc2/hcd_intr.c | 82 +--
drivers/usb/dwc2/hcd_queue.c | 10 +-
9 files changed, 515 insertions(+), 495 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index d5197d4..a7bad24 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -67,10 +67,10 @@ static void dwc2_enable_common_interrupts(struct dwc2_hsotg
*hsotg)
u32 intmsk;
/* Clear any pending OTG Interrupts */
- writel(0x, hsotg->regs + GOTGINT);
+ dwc2_writel(0x, hsotg->regs + GOTGINT);
/* Clear any pending interrupts */
- writel(0x, hsotg->regs + GINTSTS);
+ dwc2_writel(0x, hsotg->regs + GINTSTS);
/* Enable the interrupts in the GINTMSK */
intmsk = GINTSTS_MODEMIS | GINTSTS_OTGINT;
@@ -81,7 +81,7 @@ static void dwc2_enable_common_interrupts(struct dwc2_hsotg
*hsotg)
intmsk |= GINTSTS_CONIDSTSCHNG | GINTSTS_WKUPINT | GINTSTS_USBSUSP |
GINTSTS_SESSREQINT;
- writel(intmsk, hsotg->regs + GINTMSK);
+ dwc2_writel(intmsk, hsotg->regs + GINTMSK);
}
/*
@@ -104,10 +104,10 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg
*hsotg)
}
dev_dbg(hsotg->dev, "Initializing HCFG.FSLSPClkSel to %08x\n", val);
- hcfg = readl(hsotg->regs + HCFG);
+ hcfg = dwc2_readl(hsotg->regs + HCFG);
hcfg &= ~HCFG_FSLSPCLKSEL_MASK;
hcfg |= val << HCFG_FSLSPCLKSEL_SHIFT;
- writel(hcfg, hsotg->regs + HCFG);
+ dwc2_writel(hcfg, hsotg->regs + HCFG);
}
/*
@@ -125,7 +125,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
/* Wait for AHB master IDLE state */
do {
usleep_range(2, 4);
- greset = readl(hsotg->regs + GRSTCTL);
+ greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
"%s() HANG! AHB Idle GRSTCTL=%0x\n",
@@ -137,10 +137,10 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
/* Core Soft Reset */
count = 0;
greset |= GRSTCTL_CSFTRST;
- writel(greset, hsotg->regs + GRSTCTL);
+ dwc2_writel(greset, hsotg->regs + GRSTCTL);
do {
usleep_range(2, 4);
- greset = readl(hsotg->regs + GRSTCTL);
+ greset = dwc2_readl(hsotg->regs + GRSTCTL);
if (++count > 50) {
dev_warn(hsotg->dev,
"%s() HANG! Soft Reset GRSTCTL=%0x\n",
@@ -150,20 +150,20 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
} while (greset & GRSTCTL_CSFTRST);
if (hsotg->dr_mode == USB_DR_MODE_HOST) {
- gusbcfg = readl(hsotg->regs + GUSBCFG);
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
gusbcfg |= GUSBCFG_FORCEHOSTMODE;
- writel(gusbcfg, hsotg->regs + GUSBCFG);
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
} else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
- gusbcfg = readl(hsotg->regs + GUSBCFG);
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
gusbcfg |= GUSBCFG_FORCEDEVMODE;
- writel(gusbcfg, hsotg->regs + GUSBCFG);
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
} else if (hsotg->dr_mode == USB_DR_MODE_OTG) {
- gusbcfg = readl(hsotg->regs + GUSBCFG);
+ gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
- writel(gusbcfg, hsotg->regs + GUSBCFG);
+ dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
}
/*
@@ -186,9 +186,9 @@ static int dwc2_fs_phy_init(struct d
Re: [PATCH 18/22] usb: gadget: serial: %pF is only for function pointers
On Thu, 2015-03-12 at 15:36 +0300, Sergei Shtylyov wrote: > Hello. > > On 3/12/2015 6:13 AM, Scott Wood wrote: > > > Use %pS for actual addresses, otherwise you'll get bad output > > %pS or %ps? > > > on arches like ppc64 where %pF expects a function descriptor. > > %pF or %pf? And what is a function descriptor? %pS where %pF appeared, and %ps where %pf appeared (yes, I'll fix the copy-and-paste commit message). A function descriptor is a data structure used when a function pointer needs to contain more information than the instruction pointer to branch to, such as a TOC pointer. Example: http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES -Scott -- 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 18/22] usb: gadget: serial: %pF is only for function pointers
On Thu, Mar 12, 2015 at 1:40 PM, Scott Wood wrote: > No. __builtin_return_address() returns a pointer to an instruction, not > a function pointer descriptor. If you use %pF on the former, it'll > print instruction opcodes as if they were the address. Then you should mention this in the commit log. -- 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 18/22] usb: gadget: serial: %pF is only for function pointers
On Thu, 2015-03-12 at 12:51 -0300, Fabio Estevam wrote: > On Thu, Mar 12, 2015 at 12:13 AM, Scott Wood wrote: > > Use %pS for actual addresses, otherwise you'll get bad output > > on arches like ppc64 where %pF expects a function descriptor. > > From Documentation/printk-formats.txt: > > "On ia64, ppc64 and parisc64 architectures function pointers are > actually function descriptors which must first be resolved. The 'F' and > 'f' specifiers perform this resolution and then provide the same > functionality as the 'S' and 's' specifiers." > > ,so current code should work fine on ppc64, right? No. __builtin_return_address() returns a pointer to an instruction, not a function pointer descriptor. If you use %pF on the former, it'll print instruction opcodes as if they were the address. -Scott -- 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/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function
Hi,
On Thu, Mar 12, 2015 at 05:40:56AM +, yoshihiro shimoda wrote:
> Hi,
>
> > On Thu, Mar 12, 2015 at 04:33:41AM +, yoshihiro shimoda wrote:
> > > Hi Geert-san again,
> > >
> > > > Hi Geert-san,
> > > >
> > > > Thank you for the reply again!
> > > >
> > > > > Hi Shimoda-san,
> > > > >
> > > > > On Mon, Feb 16, 2015 at 2:52 AM, Yoshihiro Shimoda
> > > > > wrote:
> > > > > > According to the gadget.h, a "complete" function will always be
> > > > > > called
> > > > > > with interrupts disabled. However, sometimes usbhsg_queue_pop()
> > > > > > function
> > > > > > is called with interrupts enabled. So, this function should calls
> > > > > > local_irq_save() before this calls the
> > > > > > usb_gadget_giveback_request().
> > > > > > Otherwise, there is possible to cause a spinlock suspected in a
> > > > > > gadget
> > > > > > complete function.
> > > > >
> > > > > I still feel uneasy about adding the call to local_irq_save(), as the
> > > > > need for
> > > > > this is usually an indicator of another locking problem.
> > > >
> > > > I also think that I would like to avoid using local_irq_save().
> > > > But, I have no idea to resolve this issue for now.
> > >
> > > After I modified usb-dmac driver to use a tasklet instead of a kthread,
> > > this issue disappeared.
> > >
> > > My understanding is the followings:
> > > - According to the backtrace below, during usbhsf_dma_complete() was
> > > running,
> > > a softirq happened. After ncm_tx_tasklet() was called, the issue
> > > happened.
> > > http://thread.gmane.org/gmane.linux.usb.general/122023/focus=43729
> > >
> > > - This means that usbhsf_dma_complete() ran on a kthread. So, ncm driver
> > > is able
> > > to do the ncm_tx_tasklet().
> > >
> > > - After the current usb-dmac driver, since usbhsf_dma_complete() runs on
> > > a tasklet,
> > > ncm driver is not able to do the ncm_tx_tasklet during
> > > usbhsf_dma_complete() was running.
> > >
> > >
> > > So, I would like to recall this patch and I will resubmit this patch
> > > series as v3.
> >
> > try something like below:
> >
> > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
> > b/drivers/usb/renesas_usbhs/mod_gadget.c
> > index e0384af77e56..e9d75d85be59 100644
> > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> > @@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
> > /*
> > * queue push/pop
> > */
> > -static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > +static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
> > struct usbhsg_request *ureq,
> > int status)
> > {
> > @@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > usb_gadget_giveback_request(&uep->ep, &ureq->req);
> > }
> >
> > +static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > +struct usbhsg_request *ureq,
> > +int status)
> > +{
> > + usbhs_lock(priv, flags);
> > + __usbhsg_queue_pop(uep, ureq, status);
> > + usbhs_unlock(priv, flags);
> > +}
> > +
> > static void usbhsg_queue_done(struct usbhs_priv *priv, struct usbhs_pkt
> > *pkt)
> > {
> > struct usbhs_pipe *pipe = pkt->pipe;
> >
> >
> > then, for cases where lock is already held you call __usbhsg_queue_pop()
> > and for all other cases, call usbhsg_queue_pop().
>
> Thank you for the suggestion. However, we cannot use this
> usbhsg_queue_pop() because a gadget driver might call usb_ep_queue()
> in the "complete" function and this driver calls usbhs_lock() in the
> usb_ep_queue().
right, in that case just call __usbhs_queue_pop() directly.
> Perhaps my explanation was bad, but this issue was caused by the
> following conditions:
> - I use the renesas_usbhs driver as udc.
> - I use an old usb-dmac driver that the callback runs on a kthread.
> - I use the ncm driver. In this environment, the ncm driver might
> cause a spinlock suspected.
>
> As an old solution, I fixed the renesas_usbhs driver by this patch.
> However, if I use a new usb-dmac driver that the callback runs on a
> tasklet, I don't need this patch. (This is a new solution.)
then differentiate based on some revision register or something like
that ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 4/5] usb: common: otg-fsm: add HNP polling support
On Thu, Mar 12, 2015 at 10:30:23AM +0800, Li Jun wrote:
> Adds HNP polling timer when transits to host state, the OTG status request
> will be sent to peripheral after timeout, if host request flag is set, it will
> switch to peripheral state, otherwise it will repeat HNP polling every 1.5s
> and
> maintain the current session.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/common/usb-otg-fsm.c | 93
> ++
> include/linux/usb/otg-fsm.h | 14 ++
> 2 files changed, 107 insertions(+)
>
> diff --git a/drivers/usb/common/usb-otg-fsm.c
> b/drivers/usb/common/usb-otg-fsm.c
> index 61d538a..965b258 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -78,6 +78,8 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
> fsm->b_srp_done = 0;
> break;
> case OTG_STATE_B_PERIPHERAL:
> + if (fsm->otg->gadget)
> + fsm->otg->gadget->host_request_flag = 0;
> break;
> case OTG_STATE_B_WAIT_ACON:
> otg_del_timer(fsm, B_ASE0_BRST);
> @@ -107,6 +109,8 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
> case OTG_STATE_A_PERIPHERAL:
> otg_del_timer(fsm, A_BIDL_ADIS);
> fsm->a_bidl_adis_tmout = 0;
> + if (fsm->otg->gadget)
> + fsm->otg->gadget->host_request_flag = 0;
> break;
> case OTG_STATE_A_WAIT_VFALL:
> otg_del_timer(fsm, A_WAIT_VFALL);
> @@ -120,6 +124,93 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
> }
> }
>
> +static void otg_hnp_polling_work(struct work_struct *work)
> +{
> + struct otg_fsm *fsm = container_of(work, struct otg_fsm,
> + hnp_polling_work);
> + struct usb_device *udev;
> + u8 host_req_flag;
> + enum usb_otg_state state = fsm->otg->state;
> + int retval;
> +
> + if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
> + return;
> +
> + udev = usb_hub_find_child(fsm->otg->host->root_hub, 1);
> + if (!udev) {
> + dev_err(fsm->otg->host->controller,
> + "no usb dev connected, can't start HNP polling\n");
> + return;
> + }
> +
> + /* Get host request flag from connected USB device */
> + retval = usb_control_msg(udev,
> + usb_rcvctrlpipe(udev, 0),
> + USB_REQ_GET_STATUS,
> + USB_DIR_IN | USB_RECIP_DEVICE,
> + 0,
> + OTG_STS_SELECTOR,
> + &host_req_flag,
> + 1,
> + USB_CTRL_GET_TIMEOUT);
> + if (retval != 1) {
> + dev_err(&udev->dev, "Get one byte OTG status failed\n");
> + return;
> + }
> +
> + if (host_req_flag == 0) {
> + /* Continue HNP polling */
> + mod_timer(&fsm->hnp_polling_timer,
> + jiffies + msecs_to_jiffies(T_HOST_REQ_POLL));
> + return;
> + } else if (host_req_flag != HOST_REQUEST_FLAG) {
> + dev_err(&udev->dev, "host request flag %d is invalid\n",
> + host_req_flag);
> + return;
> + }
> +
> + /* Host request flag is set */
> + if (state == OTG_STATE_A_HOST) {
> + /* Set b_hnp_enable */
> + if (!fsm->otg->host->b_hnp_enable) {
> + retval = usb_control_msg(udev,
> + usb_sndctrlpipe(udev, 0),
> + USB_REQ_SET_FEATURE, 0,
> + USB_DEVICE_B_HNP_ENABLE,
> + 0, NULL, 0,
> + USB_CTRL_SET_TIMEOUT);
> + if (retval < 0) {
> + dev_err(&udev->dev,
> + "can't enable HNP %d\n", retval);
> + return;
> + }
> + fsm->otg->host->b_hnp_enable = 1;
> + }
> +
> + fsm->a_bus_req = 0;
> + } else if (state == OTG_STATE_B_HOST) {
> + fsm->b_bus_req = 0;
> + }
> +
> + otg_statemachine(fsm);
why isn't all of this...
> +}
> +
> +static void hnp_polling_timer_work(unsigned long arg)
> +{
> + struct otg_fsm *fsm = (struct otg_fsm *)arg;
> +
> + schedule_work(&fsm->hnp_polling_work);
here ? We would avoid a workstruct
> +}
> +
> +static void otg_start_hnp_polling(struct otg_fsm *fsm)
> +{
> + INIT_WORK(&fsm->hnp_polling_work, otg_hnp_polling_work);
> + setup_timer(&fsm->hnp_polling_timer, hnp_polling_timer_work,
> +
Re: [PATCH v2 2/5] usb: chipidea: udc: add OTG status request handling
Hi,
On Thu, Mar 12, 2015 at 10:30:21AM +0800, Li Jun wrote:
> From: Li Jun
>
> Peripheral answers OTG status selector request from host according to
> host_request_flag of gadget, length is 1.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/udc.c | 28 +++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 4254792..eed66bc 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -831,7 +831,17 @@ __acquires(hwep->lock)
> return -ENOMEM;
>
> req->complete = isr_get_status_complete;
> - req->length = 2;
> + if (setup->wIndex == OTG_STS_SELECTOR) {
> + if (ci_otg_is_fsm_mode(ci)) {
> + req->length = 1;
> + } else {
> + retval = -ENOTSUPP;
> + goto err_free_req;
> + }
> + } else {
> + req->length = 2;
> + }
this could still be done generically in composite.c
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 18/22] usb: gadget: serial: %pF is only for function pointers
On Thu, Mar 12, 2015 at 12:13 AM, Scott Wood wrote: > Use %pS for actual addresses, otherwise you'll get bad output > on arches like ppc64 where %pF expects a function descriptor. >From Documentation/printk-formats.txt: "On ia64, ppc64 and parisc64 architectures function pointers are actually function descriptors which must first be resolved. The 'F' and 'f' specifiers perform this resolution and then provide the same functionality as the 'S' and 's' specifiers." ,so current code should work fine on ppc64, right? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/22] usb: gadget: serial: %pF is only for function pointers
On Thu, Mar 12, 2015 at 12:27:07AM -0500, Scott Wood wrote:
> On Wed, 2015-03-11 at 23:45 -0500, Felipe Balbi wrote:
> > On Wed, Mar 11, 2015 at 10:13:53PM -0500, Scott Wood wrote:
> > > Use %pS for actual addresses, otherwise you'll get bad output
> > > on arches like ppc64 where %pF expects a function descriptor.
> > >
> > > Signed-off-by: Scott Wood
> > > Cc: linux-usb@vger.kernel.org
> > > Cc: Felipe Balbi
> > > ---
> > > drivers/usb/gadget/function/u_serial.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/gadget/function/u_serial.c
> > > b/drivers/usb/gadget/function/u_serial.c
> > > index 491082a..89179ab 100644
> > > --- a/drivers/usb/gadget/function/u_serial.c
> > > +++ b/drivers/usb/gadget/function/u_serial.c
> > > @@ -912,7 +912,7 @@ static int gs_put_char(struct tty_struct *tty,
> > > unsigned char ch)
> > > unsigned long flags;
> > > int status;
> > >
> > > - pr_vdebug("gs_put_char: (%d,%p) char=0x%x, called from %pf\n",
> > > + pr_vdebug("gs_put_char: (%d,%p) char=0x%x, called from %ps\n",
> > ^
> > S ??
>
> %ps is the non-function-pointer version of %pf. %pS is the
> non-function-pointer version of %pF. I didn't change the capitalization
> of any of these -- if that's warranted in some places, it's outside the
> scope of this treewide patchset.
then let's fix your commit log where you mention %pS but use %ps ;-)
--
balbi
signature.asc
Description: Digital signature
Re: Bug 46201 - FTDI driver "error from flowcontrol urb"
On Thu, 12 Mar 2015, Martin Stolpe wrote: > Hello, > > I'm affected by the bug described in > https://bugzilla.kernel.org/show_bug.cgi?id=46201 and would like to > help to triage the cause of this bug. Unfortunately I have no > experience in kernel debugging and my programming skills are rather > limited. Is there anything I can do to help? The error code in that bug report is -84, which indicates either that the device has stopped working or that the cable is no longer transmitting packets correctly. The fact that the log says that the device disconnected right after the errors occurred confirms this. It seems unlikely that this disconnection was caused by a bug in the driver, which leaves bad hardware as the remaining possibility. 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/1] usb: xhci: handle Config Error Change (CEC) in xhci driver
On 06.03.2015 10:12, Lu Baolu wrote:
> Linux xHCI driver doesn't report and handle port cofig error change.
> If Port Configure Error for root hub port occurs, CEC bit in PORTSC
> would be set by xHC and remains 1. This happends when the root port
> fails to configure its link partner, e.g. the port fails to exchange
> port capabilities information using Port Capability LMPs.
>
> Then the Port Status Change Events will be blocked until all status
> change bits(CEC is one of the change bits) are cleared('0') (refer to
> xHCI spec 4.19.2). Otherwise, the port status change event for this
> root port will not be generated anymore, then root port would look
> like dead for user and can't be recovered until a Host Controller
> Reset(HCRST).
>
> This patch is to check CEC bit in PORTSC in xhci_get_port_status()
> and set a Config Error in the return status if CEC is set. This will
> cause a ClearPortFeature request, where CEC bit is cleared in
> xhci_clear_port_change_bit().
>
> [Mathias Nyman contributed the idea. The commit log is based on patch
> posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2]
>
> Signed-off-by: Lu Baolu
> Cc: stable # v3.2+
Looks good, I'll add it to the queue,
-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
Bug 46201 - FTDI driver "error from flowcontrol urb"
Hello, I'm affected by the bug described in https://bugzilla.kernel.org/show_bug.cgi?id=46201 and would like to help to triage the cause of this bug. Unfortunately I have no experience in kernel debugging and my programming skills are rather limited. Is there anything I can do to help? Regards Martin -- 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] ARM: dts: remove usb2-phy on Exynos5 series SoC
Hi, On Thu, Mar 12, 2015 at 3:40 PM, Jaewon Kim wrote: > Exynos5 series SoC does not have usb2-phy on USB3.0 Controller. > It is controlled by only usb3-phy. So, this patch remove usb2-phy > property. Why would you want to remove the usb2-phy property ? The usb2-phy projected here is actually the UTMI+ phy which is present as a part of a hybrid PHY controller (that includes both UTMI+ as well as PIPE3 phys). And the exynos5-usbdrd phy driver also differentiates between the two PHYs. It does try to separate out the initializations for UTMI+ and PIPE3 phy, if you notice the functions: exynos5_usbdrd_utmi_init() and exynos5_usbdrd_pipe3_init(). I don't think this change seems valid. > > Signed-off-by: Jaewon Kim > --- > arch/arm/boot/dts/exynos5250.dtsi |4 ++-- > arch/arm/boot/dts/exynos5420.dtsi |8 > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/boot/dts/exynos5250.dtsi > b/arch/arm/boot/dts/exynos5250.dtsi > index 9bb1b0b..b58b169 100644 > --- a/arch/arm/boot/dts/exynos5250.dtsi > +++ b/arch/arm/boot/dts/exynos5250.dtsi > @@ -565,8 +565,8 @@ > compatible = "synopsys,dwc3"; > reg = <0x1200 0x1>; > interrupts = <0 72 0>; > - phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>; > - phy-names = "usb2-phy", "usb3-phy"; > + phys = <&usbdrd_phy 0>; > + phy-names = "usb3-phy"; > }; > }; > > diff --git a/arch/arm/boot/dts/exynos5420.dtsi > b/arch/arm/boot/dts/exynos5420.dtsi > index 9dc2e97..0df14bb 100644 > --- a/arch/arm/boot/dts/exynos5420.dtsi > +++ b/arch/arm/boot/dts/exynos5420.dtsi > @@ -845,8 +845,8 @@ > compatible = "snps,dwc3"; > reg = <0x1200 0x1>; > interrupts = <0 72 0>; > - phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>; > - phy-names = "usb2-phy", "usb3-phy"; > + phys = <&usbdrd_phy0 0>; > + phy-names = "usb3-phy"; > }; > }; > > @@ -871,8 +871,8 @@ > compatible = "snps,dwc3"; > reg = <0x1240 0x1>; > interrupts = <0 73 0>; > - phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>; > - phy-names = "usb2-phy", "usb3-phy"; > + phys = <&usbdrd_phy1 1>; > + phy-names = "usb3-phy"; > }; > }; > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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 18/22] usb: gadget: serial: %pF is only for function pointers
Hello.
On 3/12/2015 6:13 AM, Scott Wood wrote:
Use %pS for actual addresses, otherwise you'll get bad output
%pS or %ps?
on arches like ppc64 where %pF expects a function descriptor.
%pF or %pf? And what is a function descriptor?
Signed-off-by: Scott Wood
Cc: linux-usb@vger.kernel.org
Cc: Felipe Balbi
[...]
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index 491082a..89179ab 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -912,7 +912,7 @@ static int gs_put_char(struct tty_struct *tty, unsigned
char ch)
unsigned long flags;
int status;
- pr_vdebug("gs_put_char: (%d,%p) char=0x%x, called from %pf\n",
+ pr_vdebug("gs_put_char: (%d,%p) char=0x%x, called from %ps\n",
port->port_num, tty, ch, __builtin_return_address(0));
[...]
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
[no subject]
Proposal, Respond to my personal email; mrs.zhangxiao1962@outlook. com Yours Sincerely. Mrs. Zhang Xiao (Accounts book Keeper) Angang Steel Company Limited 396 Nan Zhong Hua Lu, Tie Dong District Anshan, Liaoning 114021, China. -- 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/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.
However, under Intel xHCI host controllers, if the event ring is full
of events from transfers with BEI set, an "Event Ring is Full" event
will be posted to the last entry of the event ring, but no interrupt
is generated. Host will cease all transfer and command executions and
wait until software completes handling the pending events in the event
ring. That means xHC stops, but event of "event ring is full" is not
notified. As the result, the xHC looks like dead to user.
This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
it should be backported to kernels as old as 3.0, that contains the
commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
Signed-off-by: Lu Baolu
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fd53c9e..2af32e2 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -115,6 +115,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
+ xhci->quirks |= XHCI_AVOID_BEI;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
@@ -130,7 +131,6 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
* PPT chipsets.
*/
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
- xhci->quirks |= XHCI_AVOID_BEI;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
--
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] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC
This patch adds driver data to support for Exynos5433 SoC.
The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
one more USB3.0 Host controller.
Signed-off-by: Jaewon Kim
---
.../devicetree/bindings/phy/samsung-phy.txt|3 ++-
drivers/phy/phy-exynos5-usbdrd.c | 10 ++
include/linux/mfd/syscon/exynos5-pmu.h |3 +++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 91e38cf..60c6f2a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
- compatible : Should be set to one of the following supported values:
- "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
- "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+ - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC.
- "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
- reg : Register offset and length of USB DRD PHY register set;
- clocks: Clock IDs array as required by the controller
@@ -139,7 +140,7 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
- - optional clocks: Exynos7 SoC has now following additional
+ - optional clocks: Exynos5433 & Exynos7 SoC has now following additional
gate clocks available:
- phy_pipe: for PIPE3 phy
- phy_utmi: for UTMI+ phy
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 0437401..597e7dd 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata
exynos5250_usbdrd_phy = {
.has_common_clk_gate= true,
};
+static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
+ .phy_cfg= phy_cfg_exynos5,
+ .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
+ .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
+ .has_common_clk_gate= false,
+};
+
static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
.phy_cfg= phy_cfg_exynos5,
.pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
@@ -638,6 +645,9 @@ static const struct of_device_id
exynos5_usbdrd_phy_of_match[] = {
.compatible = "samsung,exynos5420-usbdrd-phy",
.data = &exynos5420_usbdrd_phy
}, {
+ .compatible = "samsung,exynos5433-usbdrd-phy",
+ .data = &exynos5433_usbdrd_phy
+ }, {
.compatible = "samsung,exynos7-usbdrd-phy",
.data = &exynos7_usbdrd_phy
},
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h
b/include/linux/mfd/syscon/exynos5-pmu.h
index 00ef24b..9352adc 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -36,6 +36,9 @@
#define EXYNOS5420_MTCADC_PHY_CONTROL (0x724)
#define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
+/* Exynos5433 specific register definitions */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL (0x728)
+
#define EXYNOS5_PHY_ENABLE BIT(0)
#define EXYNOS5_MIPI_PHY_S_RESETN BIT(1)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: remove usb2-phy on Exynos5 series SoC
Exynos5 series SoC does not have usb2-phy on USB3.0 Controller. It is controlled by only usb3-phy. So, this patch remove usb2-phy property. Signed-off-by: Jaewon Kim --- arch/arm/boot/dts/exynos5250.dtsi |4 ++-- arch/arm/boot/dts/exynos5420.dtsi |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index 9bb1b0b..b58b169 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -565,8 +565,8 @@ compatible = "synopsys,dwc3"; reg = <0x1200 0x1>; interrupts = <0 72 0>; - phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>; - phy-names = "usb2-phy", "usb3-phy"; + phys = <&usbdrd_phy 0>; + phy-names = "usb3-phy"; }; }; diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 9dc2e97..0df14bb 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -845,8 +845,8 @@ compatible = "snps,dwc3"; reg = <0x1200 0x1>; interrupts = <0 72 0>; - phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>; - phy-names = "usb2-phy", "usb3-phy"; + phys = <&usbdrd_phy0 0>; + phy-names = "usb3-phy"; }; }; @@ -871,8 +871,8 @@ compatible = "snps,dwc3"; reg = <0x1240 0x1>; interrupts = <0 73 0>; - phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>; - phy-names = "usb2-phy", "usb3-phy"; + phys = <&usbdrd_phy1 1>; + phy-names = "usb3-phy"; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-mxc: i.MX35: add workaround for ENGcm11601
Hi Sascha,
On Wed, March 11, 2015 4:46 pm, Sascha Hauer wrote:
> On Wed, Mar 11, 2015 at 04:05:31PM +0100, Bas Vermeulen wrote:
>>
>> On Wed, March 11, 2015 4:01 pm, Sascha Hauer wrote:
>> > On Wed, Mar 11, 2015 at 03:52:53PM +0100, Bas Vermeulen wrote:
>> >> Hello,
>> >>
>> >> On Wed, March 11, 2015 2:51 pm, Sascha Hauer wrote:
>> >> > This driver normally is not used with device tree. Without
>> additional
>> >> > kernel changes the chipidea driver is used instead.
>> >>
>> >> I'm just forward-porting a patch I made for 2.6.31.14 to workaround
>> >> an issue we found. I'm unsure where to fit this in in the chipidea
>> >> driver.
>> >>
>> >> However, if you read the errata for the i.mx35, you will see the
>> problem
>> >> and the fix proposed. I have been unable to find that errata for
>> other
>> >> soc's in the family (but some google fu found somewhat similar issues
>> >> for
>> >> i.mx25 and i.mx51).
>> >>
>> >> I would still like to get this patch incorporated into the ehci-mxc
>> >> driver, as it might make it easier to find for people with the same
>> >> problem.
>> >
>> > If you start your board with device tree the ehci-mxc driver will
>> never
>> > be started, because noone ever registers the device. When you start
>> > without device tree (but instead with board file)
>> > of_machine_is_compatible("fsl,imx35") will always return false because
>> > there is no device tree. To trigger your fixup one would have to start
>> > the kernel via device tree and additionally create a board file which
>> > registers the ehci-mxc device. A rather unusual case.
>>
>> What should I use instead? I'm fine changing the patch, I'm just not
>> sure
>> what to use to make it conditional.
>
> A question is whether it should be conditional at all. We are currently
> hunting a very hard to trigger bug on the i.MX53 which could be this
> one. We are testing it and Michael will can send a (tested) patch later.
> However, this will probably take some weeks because as said the bugs
> takes very long to trigger.
Try communicating over two usb interfaces at the same time.
The problem is triggered by the AHB being interrupted by a higher priority
target while transferring with SINGLE transfers.
Our scenario uses a cdc-acm connection to a modem, and a different
connection to a tablet. The (short) communication with the modem (data
connection using ppp) hangs up relatively fast on the i.mx35.
Bas Vermeulen
--
Blackstar Embedded Services
Hoofdweg 128 * 9626AJ * Schildwolde * The Netherlands
T: +31 598 423928 * F: +31 598 423991 * M: +31 6 45622453
E-mail: bas.vermeu...@blackstar.nl
KvK: 01163970 * BTW-nummer: NL142605608B01
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
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: phy: Find the right match in devm_usb_phy_match
On Wed, Mar 11, 2015 at 12:55:42PM +0800, Axel Lin wrote:
> The res parameter passed to devm_usb_phy_match() is the location where the
> pointer to the usb_phy is stored, hence it needs to be dereferenced before
> comparing to the match data in order to find the correct match.
>
> Signed-off-by: Axel Lin
which commit introduced this bug ? (git blame helps).
Looks like this needs to Cc stable, right ? You should have something
like:
Fixes: 0123456789ab ("commit short log")
Cc: # vX.Y+
--
balbi
signature.asc
Description: Digital signature
[GIT PULL] USB fixes for v4.0-rc3
Hi Greg, This is likely my last pull for the -rc, but things may change. Let me know if you need any changes Patches tested on platforms I have access to. cheers The following changes since commit 9eccca0843205f87c00404b663188b88eb248051: Linux 4.0-rc3 (2015-03-08 16:09:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v4.0-rc3 for you to fetch changes up to 2c247804796bbcaa90087f2196f68fdc20a5fe04: Revert "usb: gadget: zero: Add support for interrupt EP" (2015-03-11 10:00:05 -0500) usb: fixes for v4.0-rc3 Revert interrupt endpoint support from g_zero as it regresses musb. A possible deadlock in isp1760 udc irq has been fixed. A fix to dwc2 for disconnect IRQ handling. We also have a new device ID for isp1760. Signed-off-by: Felipe Balbi Arnd Bergmann (1): usb: musb: fix Kconfig regression David Dueck (1): usb: phy: am335x-control: check return value of bus_find_device Felipe Balbi (1): Revert "usb: gadget: zero: Add support for interrupt EP" Sudeep Holla (2): usb: isp1760: fix possible deadlock in isp1760_udc_irq usb: isp1760: add peripheral/device controller chip id Valentin Rothberg (1): usb: isp1760: set IRQ flags properly Yunzhi Li (1): usb: dwc2: host: fix dwc2 disconnect bug drivers/usb/dwc2/core_intr.c | 3 + drivers/usb/gadget/function/f_loopback.c | 3 +- drivers/usb/gadget/function/f_sourcesink.c | 511 ++--- drivers/usb/gadget/function/g_zero.h | 13 +- drivers/usb/gadget/legacy/zero.c | 21 -- drivers/usb/isp1760/isp1760-core.c | 3 +- drivers/usb/isp1760/isp1760-udc.c | 16 +- drivers/usb/musb/Kconfig | 3 +- drivers/usb/phy/phy-am335x-control.c | 3 + 9 files changed, 40 insertions(+), 536 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to Intel ValleyView and LynxPoint LP
On 03/12/2015 03:54 PM, Greg Kroah-Hartman wrote:
On Thu, Mar 12, 2015 at 09:39:06AM +0800, Lu Baolu wrote:
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.
However, under some Intel xHCI host controllers like ValleyView and
Lynx Point LP, if the event ring is full of events from transfers with
BEI set, a "Event Ring is Full" event will be posted to the last entry
of the event ring, but no interrupt is generated. Host will cease all
transfer and command executions and wait until software completes
handling the pending events in event ring. That means xHC stops but
event of "event ring is full" is not notified. As the result, the xHC
looks like dead to user.
The patch is to apply XHCI_AVOID_BEI to Intel VallyView and Lynx Point
LP devices. And it should be backported to kernels as old as 3.0, that
contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port
switching.")
Signed-off-by: Lu Baolu
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-pci.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fd53c9e..5aa4893 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -40,6 +40,7 @@
#define PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI 0x22b5
#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI 0xa12f
#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
+#definePCI_DEVICE_ID_INTEL_VALLEYVIEW_XHCI 0x0f35
Minor nit, you added a tab where the rest of the file was using a space
:(
Yes, thanks for reminding.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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: musb: dsps: request phy using our device pointer
musb shouldn't have of_node and phy phandle is passed to dsps device, not musb's. Signed-off-by: Felipe Balbi --- drivers/usb/musb/musb_dsps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index baa757ba1353..a528d3be70c5 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -432,7 +432,7 @@ static int dsps_musb_init(struct musb *musb) musb->ctrl_base = reg_base; /* NOP driver needs change if supporting dual instance */ - musb->xceiv = devm_usb_get_phy_by_phandle(dev, "phys", 0); + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent, "phys", 0); if (IS_ERR(musb->xceiv)) return PTR_ERR(musb->xceiv); -- 2.3.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] phy: Add a driver for dm816x USB PHY
* Kishon Vijay Abraham I [150311 02:58]:
> Hi Tony,
>
> On Tuesday 10 March 2015 02:21 AM, Tony Lindgren wrote:
> >Add a minimal driver for dm816x USB. Otherwise we can just use
> >the existing musb_am335x and musb_dsps on dm816x.
>
> If we can use an existing driver, I'd prefer that.
Hmm that needs rewording.. Should say that with this phy
driver musb works with existing musb_dsps usb driver on
dm816x. There is no existing driver, the closest similar
thing is the legacy drivers/usb/musb/davinci.c that has
no separate phy driver.
> >+static int dm816x_usb_phy_power_off(struct phy *x)
> >+{
> >+struct dm816x_usb_phy *phy = phy_get_drvdata(x);
> >+
> >+pm_runtime_put(phy->dev);
>
> phy core takes care of invoking pm_runtime_put on power_off.
> So this function shouldn't be needed at all.
OK will remove the pm_runtime calls for all of them.
...
> >+phy->refclk = devm_clk_get(phy->dev, "refclk");
> >+if (IS_ERR(phy->refclk))
> >+return PTR_ERR(phy->refclk);
> >+
> >+generic_phy = devm_phy_create(phy->dev, NULL, &ops);
> >+if (IS_ERR(generic_phy))
> >+return PTR_ERR(generic_phy);
>
> Just invoke pm_runtime_enable before phy_create and phy core will take care of
> invoking all pm_runtime functions at appropriate time.
OK will.
Thanks,
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: [PATCH 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to Intel ValleyView and LynxPoint LP
On 03/12/2015 04:46 PM, Mathias Nyman wrote:
On 12.03.2015 03:39, Lu Baolu wrote:
When a device with an isochronous endpoint is plugged into the Intel
xHCI host controller, and the driver submits multiple frames per URB,
the xHCI driver will set the Block Event Interrupt (BEI) flag on all
but the last TD for the URB. This causes the host controller to place
an event on the event ring, but not send an interrupt. When the last
TD for the URB completes, BEI is cleared, and we get an interrupt for
the whole URB.
However, under some Intel xHCI host controllers like ValleyView and
Lynx Point LP, if the event ring is full of events from transfers with
BEI set, a "Event Ring is Full" event will be posted to the last entry
of the event ring, but no interrupt is generated. Host will cease all
transfer and command executions and wait until software completes
handling the pending events in event ring. That means xHC stops but
event of "event ring is full" is not notified. As the result, the xHC
looks like dead to user.
The patch is to apply XHCI_AVOID_BEI to Intel VallyView and Lynx Point
LP devices. And it should be backported to kernels as old as 3.0, that
contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port
switching.")
Maybe we should set the quirk for all Intel xHCI controllers.
So far the list includes Pantherpoint, Lynxpoint and valleyview.
I bet it concerns most Intel platforms.
Yes, I agree with you.
I will send out a new patch for this.
-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
--
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/1] usb: xhci: apply XHCI_AVOID_BEI quirk to Intel ValleyView and LynxPoint LP
On 12.03.2015 03:39, Lu Baolu wrote:
> When a device with an isochronous endpoint is plugged into the Intel
> xHCI host controller, and the driver submits multiple frames per URB,
> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
> but the last TD for the URB. This causes the host controller to place
> an event on the event ring, but not send an interrupt. When the last
> TD for the URB completes, BEI is cleared, and we get an interrupt for
> the whole URB.
>
> However, under some Intel xHCI host controllers like ValleyView and
> Lynx Point LP, if the event ring is full of events from transfers with
> BEI set, a "Event Ring is Full" event will be posted to the last entry
> of the event ring, but no interrupt is generated. Host will cease all
> transfer and command executions and wait until software completes
> handling the pending events in event ring. That means xHC stops but
> event of "event ring is full" is not notified. As the result, the xHC
> looks like dead to user.
>
> The patch is to apply XHCI_AVOID_BEI to Intel VallyView and Lynx Point
> LP devices. And it should be backported to kernels as old as 3.0, that
> contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port
> switching.")
>
Maybe we should set the quirk for all Intel xHCI controllers.
So far the list includes Pantherpoint, Lynxpoint and valleyview.
I bet it concerns most Intel platforms.
-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: ehci-mxc: i.MX35: add workaround for ENGcm11601
On Wed, Mar 11, 2015 at 03:52:53PM +0100, Bas Vermeulen wrote:
> Hello,
>
> On Wed, March 11, 2015 2:51 pm, Sascha Hauer wrote:
> > This driver normally is not used with device tree. Without additional
> > kernel changes the chipidea driver is used instead.
>
> I'm just forward-porting a patch I made for 2.6.31.14 to workaround
> an issue we found. I'm unsure where to fit this in in the chipidea driver.
>
> However, if you read the errata for the i.mx35, you will see the problem
> and the fix proposed. I have been unable to find that errata for other
> soc's in the family (but some google fu found somewhat similar issues for
> i.mx25 and i.mx51).
>
> I would still like to get this patch incorporated into the ehci-mxc
> driver, as it might make it easier to find for people with the same
> problem.
If you start your board with device tree the ehci-mxc driver will never
be started, because noone ever registers the device. When you start
without device tree (but instead with board file)
of_machine_is_compatible("fsl,imx35") will always return false because
there is no device tree. To trigger your fixup one would have to start
the kernel via device tree and additionally create a board file which
registers the ehci-mxc device. A rather unusual case.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: ehci-mxc: i.MX35: add workaround for ENGcm11601
Hello, On Wed, March 11, 2015 2:51 pm, Sascha Hauer wrote: > This driver normally is not used with device tree. Without additional > kernel changes the chipidea driver is used instead. I'm just forward-porting a patch I made for 2.6.31.14 to workaround an issue we found. I'm unsure where to fit this in in the chipidea driver. However, if you read the errata for the i.mx35, you will see the problem and the fix proposed. I have been unable to find that errata for other soc's in the family (but some google fu found somewhat similar issues for i.mx25 and i.mx51). I would still like to get this patch incorporated into the ehci-mxc driver, as it might make it easier to find for people with the same problem. Bas Vermeulen -- Blackstar Embedded Services Hoofdweg 128 * 9626AJ * Schildwolde * The Netherlands T: +31 598 423928 * F: +31 598 423991 * M: +31 6 45622453 E-mail: bas.vermeu...@blackstar.nl KvK: 01163970 * BTW-nummer: NL142605608B01 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD
On 11.03.2015 18:16, Jörg Otte wrote: > 2015-03-11 12:01 GMT+01:00 Jörg Otte : >> 2015-03-10 18:04 GMT+01:00 Mathias Nyman : >>> On 10.03.2015 17:36, Jörg Otte wrote: >>> >> I'd suspect one of these two patches: >> >> commit 45ba2154d12fc43b70312198ec47085f10be801a >> xhci: fix reporting of 0-sized URBs in control endpoint >> >> commit 27082e2654dc148078b0abdfc3c8e5ccbde0ebfa >> xhci: Clear the host side toggle manually when endpoint is 'soft >> reset' >> Revert the commits. The second one "xhci: Clear the host side..." is it ! >>> >>> Yes, thank you >>> >>> Seems that It wasn't mature enough, I'll revert it. >>> >>> From your logs I can see what went wrong, >>> >>> If you still have some time, could you try out a patch (attached) and see >>> if it solves the >>> issue for you. (on top of clean 4.0-rc3). I can't reproduce it with my own >>> USB DVB-T device >> >> Problems: >> error: patch failed: drivers/usb/host/xhci.c:2972 >> error: drivers/usb/host/xhci.c: patch does not apply >> >> For me the patch looks formally good. >> No idea why. > > OK, finally I got it applied successfully. > I can confirm now it works for me. > Great, 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] phy: Add a driver for dm816x USB PHY
Hi Tony,
On Tuesday 10 March 2015 02:21 AM, Tony Lindgren wrote:
Add a minimal driver for dm816x USB. Otherwise we can just use
the existing musb_am335x and musb_dsps on dm816x.
If we can use an existing driver, I'd prefer that.
Cc: Brian Hutchinson
Cc: Felipe Balbi
Signed-off-by: Tony Lindgren
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
@@ -0,0 +1,24 @@
+Device tree binding documentation for am816x USB PHY
+=
+
+Required properties:
+- compatible : should be "ti,dm816x-usb-phy"
+- reg : offset and length of the PHY register set.
+- reg-names : name for the phy registers
+- clocks : phandle to the clock
+- clock-names : name of the clock
+- syscon: phandle for the syscon node to access misc registers
+- #phy-cells : from the generic PHY bindings, must be 1
+- syscon: phandle for the syscon node to access misc registers
+
+Example:
+
+usb_phy0: usb-phy@20 {
+ compatible = "ti,dm8168-usb-phy";
+ reg = <0x20 0x8>;
+ reg-names = "phy";
+ clocks = <&main_fapll 6>;
+ clock-names = "refclk";
+ #phy-cells = <0>;
+ syscon = <&scm_conf>;
+};
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -35,6 +35,13 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF
select GENERIC_PHY
+config PHY_DM816X_USB
+ tristate "TI dm816x USB PHY driver"
+ depends on ARCH_OMAP2PLUS
+ select GENERIC_PHY
+ help
+ Enable this for dm81xx USB to work."
+
config PHY_EXYNOS_MIPI_VIDEO
tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
depends on HAS_IOMEM
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+= phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
--- /dev/null
+++ b/drivers/phy/phy-dm816x-usb.c
@@ -0,0 +1,295 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * TRM has two sets of USB_CTRL registers.. The correct register bits
+ * are in TRM section 24.9.8.2 USB_CTRL Register.
+ */
+#define DM816X_USB_CTRL_PHYCLKSRC BIT(8) /* 1 = PLL ref clock */
+#define DM816X_USB_CTRL_PHYSLEEP1 BIT(1)
+#define DM816X_USB_CTRL_PHYSLEEP0 BIT(0)
+
+#define DM816X_USBPHY_CTRL_TXRISETUNE 1
+#define DM816X_USBPHY_CTRL_TXVREFTUNE 0xc
+#define DM816X_USBPHY_CTRL_TXPREEMTUNE 0x2
+
+struct dm816x_usb_phy {
+ struct regmap *syscon;
+ struct device *dev;
+ unsigned int instance;
+ struct clk *refclk;
+ struct usb_phy phy;
+ unsigned int usb_ctrl; /* Shared between phy0 and phy1 */
+ unsigned int usbphy_ctrl;
+};
+
+static int dm816x_usb_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+ otg->host = host;
+ if (!host)
+ otg->state = OTG_STATE_UNDEFINED;
+
+ return 0;
+}
+
+static int dm816x_usb_phy_set_peripheral(struct usb_otg *otg,
+struct usb_gadget *gadget)
+{
+ otg->gadget = gadget;
+ if (!gadget)
+ otg->state = OTG_STATE_UNDEFINED;
+
+ return 0;
+}
+
+static int dm816x_usb_phy_power_off(struct phy *x)
+{
+ struct dm816x_usb_phy *phy = phy_get_drvdata(x);
+
+ pm_runtime_put(phy->dev);
phy core takes care of invoking pm_runtime_put on power_off.
So this function shouldn't be needed at all.
+
+ return 0;
+}
+
+static int dm816x_usb_phy_power_on(struct phy *x)
+{
+ struct dm816x_usb_phy *phy = phy_get_drvdata(x);
+
+ return pm_runtime_get_sync(phy->dev);
similarly on power_on, phy_core invokes pm_runtime_get_sync.
+}
+
+static int dm816x_usb_phy_init(struct phy *x)
+{
+ struct dm816x_usb_phy *phy = phy_get_drvdata(x);
+ unsigned int val;
+ int error;
+
+ error = pm_runtime_get_sync(phy->dev);
+ if (error)
+ return error;
not required.
+
+ if (clk_get_rate(phy->refclk) != 2400)
+ dev_warn(phy->dev, "nonstandard phy refclk\n");
+
+ /* Set PLL ref clock and put ph
Re: [PATCHv7 2/4] USB: gadget: atmel_usba_udc: Request an auto disabled Vbus signal IRQ instead of an auto enabled IRQ request followed by IRQ disable
Hello Felipe, On Tue, Mar 10, 2015 at 04:12:14PM -0500, Felipe Balbi wrote: > Hi, > > (dropping patch, my only context is subject line) > > "USB: gadget: atmel_usba_udc: Request an auto disabled Vbus signal IRQ > instead of an auto enabled IRQ request followed by IRQ disable" > > Holy crap, that's a pretty long patch *short* description. I'm trimming > it to: > > "usb: gadget: atmel_usba_udc: Request an auto disabled Vbus signal IRQ" I agree, lesson learned!, thanks for the heads up :) Cheers, Sylvain -- 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] udc: gadget: atmel_usba_udc: depend on COMMON_CLK_AT91
On 10/03/2015 at 16:23:53 -0500, Felipe Balbi wrote : > > Yeah, let's drop it for now but I have the feeling that this will > > break (I actually broke it when switching at91 to multiplatform). > > aha, that changes it. So you already have something which makes this > break ? Are you planning on sending that upstream any time soon ? > It has been sent but not merge and I need to send another version. > We could very well use that same series to merge this patch. Only when > it's needed ;-) > Like said, this is not an issue for now, I fixed it by simply having all the AT91 platform selecting COMMON_CLK_AT91. I just have the feeling that this is not quite future proof. So this is not urgent at all and I'll try to remember to resend when needed. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: [PATCH 1/2] usb: dwc2: Use platform endianness when accessing registers
Hi,
On Sat, Jan 31, 2015 at 01:18:46PM +0200, Antti Seppälä wrote:
> This patch switches calls to readl/writel to their
> dwc2_readl/dwc2_writel equivalents which preserve platform endianness.
>
> This patch is necessary to access dwc2 registers correctly on big endian
> systems such as the mips based SoCs made by Lantiq. Then dwc2 can be
I don't get it, why is it so that only mips needs this ? What's special
about mips' writel/readl implementation that it can't be used here ?
This works for everybody else.
Is it so that dwc2 and cpu endianness don't match here ?
> used to replace ifx-hcd driver for Lantiq platforms found e.g. in
> OpenWrt.
>
> The patch was autogenerated with the following commands:
> $EDITOR core.h
> sed -i "s/\/dwc2_readl/g" *.c hcd.h hw.h
> sed -i "s/\/dwc2_writel/g" *.c hcd.h hw.h
weren't readl() and writel() already supposed to handle endianness for
us?
> Some files were then hand-edited to fix checkpatch.pl warnings about
> too long lines.
>
> Signed-off-by: Antti Seppälä
> Signed-off-by: Vincent Pelletier
> ---
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 7a70a13..d2a9d15 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -44,16 +44,28 @@
> #include
> #include "hw.h"
>
> -#ifdef DWC2_LOG_WRITES
> -static inline void do_write(u32 value, void *addr)
> +static inline u32 dwc2_readl(const void __iomem *addr)
> {
> - writel(value, addr);
> - pr_info("INFO:: wrote %08x to %p\n", value, addr);
> + u32 value = __raw_readl(addr);
> +
> + /* In order to preserve endianness __raw_* operation is used. Therefore
> +a barrier is needed to ensure IO access is not re-ordered across
> +reads or writes */
wrong comment style.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to Intel ValleyView and LynxPoint LP
On Thu, Mar 12, 2015 at 09:39:06AM +0800, Lu Baolu wrote:
> When a device with an isochronous endpoint is plugged into the Intel
> xHCI host controller, and the driver submits multiple frames per URB,
> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
> but the last TD for the URB. This causes the host controller to place
> an event on the event ring, but not send an interrupt. When the last
> TD for the URB completes, BEI is cleared, and we get an interrupt for
> the whole URB.
>
> However, under some Intel xHCI host controllers like ValleyView and
> Lynx Point LP, if the event ring is full of events from transfers with
> BEI set, a "Event Ring is Full" event will be posted to the last entry
> of the event ring, but no interrupt is generated. Host will cease all
> transfer and command executions and wait until software completes
> handling the pending events in event ring. That means xHC stops but
> event of "event ring is full" is not notified. As the result, the xHC
> looks like dead to user.
>
> The patch is to apply XHCI_AVOID_BEI to Intel VallyView and Lynx Point
> LP devices. And it should be backported to kernels as old as 3.0, that
> contains the commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port
> switching.")
>
> Signed-off-by: Lu Baolu
> Cc: sta...@vger.kernel.org
> ---
> drivers/usb/host/xhci-pci.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index fd53c9e..5aa4893 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -40,6 +40,7 @@
> #define PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI 0x22b5
> #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI 0xa12f
> #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI 0x9d2f
> +#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_XHCI 0x0f35
Minor nit, you added a tab where the rest of the file was using a space
:(
--
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: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD
On 10.03.2015 19:29, Alan Stern wrote: > On Tue, 10 Mar 2015, Mathias Nyman wrote: > >> Yes, thank you >> >> Seems that It wasn't mature enough, I'll revert it. >> >> From your logs I can see what went wrong, >> >> If you still have some time, could you try out a patch (attached) and see if >> it solves the >> issue for you. (on top of clean 4.0-rc3). I can't reproduce it with my own >> USB DVB-T device > > Mathias: > > Your patch description says this: > >> The endpoint might already processesed some TRBs on the endpiont ring >> before we soft reset the endpoint. >> Make sure we set the dequeue pointer to where we were befere soft reset > > However, if a driver tries to issue an endpoint reset while there are > still some URBs queued, it is a bug. Host controller drivers shouldn't > have to worry about this -- xhci_endpoint_reset() should simply return > an error if the endpoint ring isn't empty. > > I suppose we should check for this in the USB core. I'll write a patch > and CC: you. > > Alan Stern > It's possible that there's something in usb core as well, but I think the following was what happened: 1. First a normal configure endpoint command is issued, it sets endpoint dequeue pointer to xxx400 = start of ring segment 2. two urbs get queued -> two TDs put on endpoint ring. 3. xhci executes those, ring is in running (idle) state. sw dequeue at xxx430, No TDs queued. Endpoint dequeue pointer is not written to the endpoint output context as the ring is still in running state (even if idle, not advancing with no TDs queued) it still shows xxx400 4. -> something happends, xhci_endpoint_reset() is called, we do a new configure endpoint to 'soft reset' the endpiont, but we copy the dequeue pointer from the old endpoint output context to the configure endpoint input context, which re-initializes the old dequeue xxx400 pointer to xhci hardware, and it starts executing the old TDs from the ring. 5. xhci driver notices that we get events for old TRBs that do not belong to the TD the driver thinks we should be handling -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: dwc2: host: fix dwc2 disconnect bug
On 3/9/2015 3:03 PM, Vincent Palatin wrote: > On Thu, Mar 5, 2015 at 11:17 PM, Yunzhi Li wrote: >> When dwc2 controller detects a disconnect interrupt, >> dwc2_hcd_disconnect() should be called immediately to do clean-up >> jobs and set port_connect_status_change flag to notify usb hub >> driver disconnect status. >> >> Signed-off-by: Yunzhi Li >> --- >> drivers/usb/dwc2/core_intr.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c >> index 02e3e2d..6cf0478 100644 >> --- a/drivers/usb/dwc2/core_intr.c >> +++ b/drivers/usb/dwc2/core_intr.c >> @@ -377,6 +377,9 @@ static void dwc2_handle_disconnect_intr(struct >> dwc2_hsotg *hsotg) >> dwc2_is_host_mode(hsotg) ? "Host" : "Device", >> dwc2_op_state_str(hsotg)); >> >> + if (hsotg->op_state == OTG_STATE_A_HOST) >> + dwc2_hcd_disconnect(hsotg); >> + >> /* Change to L3 (OFF) state */ >> hsotg->lx_state = DWC2_L3; >> >> -- >> 2.0.0 > > Tested-by: Vincent Palatin > > It's fixing real issues on my DWC2-based system where the USB device > lock was staying busy for minutes after a hub disconnection. > Acked-by: John Youn -- 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: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD
2015-03-10 15:03 GMT+01:00 Jörg Otte : > 2015-03-10 14:06 GMT+01:00 Mathias Nyman : >> On 10.03.2015 11:40, Jörg Otte wrote: >>> If I plug in my USB DVB-T stick I get the following in dmesg: >>> >>> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm >>> state. >>> dvb-usb: will pass the complete MPEG2 transport stream to the software >>> demuxer. >>> DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) >>> usb 1-1: DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 >>> Highspeed DVB-T Receiver)... >>> input: IR-receiver inside an USB DVB receiver as >>> /devices/pci:00/:00:14.0/usb1/1-1/input/input17 >>> dvb-usb: schedule remote query interval to 50 msecs. >>> xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of >>> current TD ep_index 1 comp_code 1 >>> xhci_hcd :00:14.0: Looking for event-dma 000207540400 >>> trb-start 000207540420 trb-end 000207540420 seg-start >>> 0002075404 >>> xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part of >>> current TD ep_index 1 comp_code 1 >>> xhci_hcd :00:14.0: Looking for event-dma 000207540410 >>> trb-start 000207540420 trb-end 000207540420 seg-start >>> 0002075404 >>> dvb-usb: bulk message failed: -110 (2/0) >>> >>> and DVB-T is not functional. The problem came in with: >>> >>> 1163d50 Merge tag 'usb-4.0-rc3' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb >>> >>> I never had this xhci_hcd error before so this is a regression. >>> >>> >>> Thanks, Jörg >> >> Oh, thanks. >> >> Looks like we get an event for a TRB we just moved past. >> >> Any chance you could take a log with xhci debugging enabled before attaching >> the DVB-T >> stick? >> >> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control >> >> > > here it comes attached. > > >> I'd suspect one of these two patches: >> >> commit 45ba2154d12fc43b70312198ec47085f10be801a >> xhci: fix reporting of 0-sized URBs in control endpoint >> >> commit 27082e2654dc148078b0abdfc3c8e5ccbde0ebfa >> xhci: Clear the host side toggle manually when endpoint is 'soft reset' >> Revert the commits. The second one "xhci: Clear the host side..." is it ! Thanks, Jörg -- 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
