RE: [PATCH v9 0/9] usbip: exporting devices

[fx IWATA NOBUO]

Hello,

> I know that usbip is insecure but personally I think that this series
> makes it much more insecure.

Later, I remembered USB/IP has TCP wrappers option.
It is activated with ./configure --with-tcp-wrappers and 
 /etc/hosts.[deny|allow].

And I tested and found a BUG in my patch which program names for TCP
 wrappers is not properly set.

I posted patch set as v11 including the BUG correction and description
 about TCP wrappers in the cover letter.

Thank you,

n.iwata
//
> -Original Message-
> From: Krzysztof Opasiak [mailto:k.opas...@samsung.com]
> Sent: Wednesday, August 10, 2016 2:28 AM
> To: fx IWATA NOBUO; valentina.mane...@gmail.com; shuah...@samsung.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
> Cc: fx MICHIMURA TADAO
> Subject: Re: [PATCH v9 0/9] usbip: exporting devices
> 
> 
> 
> On 07/11/2016 09:23 AM, Nobuo Iwata wrote:
> > Dear all,
> >
> > This series of patches adds exporting device operation to USB/IP.
> >
> > 1. Overview
> >
> > Exporting devices may not be a new idea. The request and response PDU
> > have been defined in tools/usbip/usbip/src/usbip_network.h.
> > #define OP_EXPORT   0x06
> > #define OP_REQ_EXPORT   (OP_REQUEST | OP_EXPORT)
> > #define OP_REP_EXPORT   (OP_REPLY   | OP_EXPORT)
> > # struct op_export_request
> > # struct op_export_reply
> > #define OP_UNEXPORT 0x07
> > #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT)
> > #define OP_REP_UNEXPORT (OP_REPLY   | OP_UNEXPORT)
> > # struct op_unexport_request
> > # struct op_unexport_reply
> >
> > But they have not been used yet. This series adds new operations:
> > 'connect' and 'disconnect' using these PDUs.
> >
> > EXISTING) - invites devices from application(vhci)-side
> >  +--+
> +--+
> >  device--+ STUB | | application/VHCI |
> >  +--+
> +--+
> >  1) usbipd ... start daemon
> >  = = =
> >  2) usbip list --local
> >  3) usbip bind
> > <--- list bound devices ---   4) usbip list --remote
> > <--- import a device --   5) usbip attach
> >  = = =
> >X disconnected 6) usbip detach
> >  7) usbip unbind
> >
> > NEW) - dedicates devices from device(stb)-side
> >  +--+
> +--+
> >  device--+ STUB | | application/VHCI |
> >  +--+
> +--+
> >   1) usbipa ... start
> > daemon  = = =
> >  2) usbip list --local
> >  3) usbip connect --- export a device -->
> >  = = =
> >  4) usbip disconnect  --- un-export a device --->
> >
> >  Bind and unbind are done in connect and disconnect internally.
> >
> > 2. The use cases
> >
> > EXISTING)
> >
> > In existing way, computers in small distance, having same user
> > account, can be easily managed by a same user. Bind in local machine
> > and attach in remote machine by the user. The devices can be exporsed
> > automatically in the local machine, for example, at strat up. They can
> > be attached from remote.
> >
> > When there are distributes linux nodes with USB devices in internet,
> > they are exposed by bind operation at start upr, server behind
> > firewall can list and attach the devices.
> >Internet
> >  Exposed   +--+++++
> >  +--+  |Linux |+   |Router, ||Service |
> > +|device|--|Controller||---|proxy,  ||on  |
> > |+--+  +--+|   |firewall||Linux   |
> > +--++--+   ++++
> ><--- attach(import)
> >   USB/IP + WS proxy   WS proxy + USB/IP
> >
> > NEW)
> >
> > Assuming that a server computer which runs application and VHCI is in
> > a server room and device side machines are small distributed nodes
> > outside of the server room, the operator of the server compter is
> > different form the distributed nodes. The server computer may be in
> > unattended operation. In the new way, after the daemon has been
> > started, device can be connected with connect command in the
> > distributed nodes. If the distributed nodes doesn't have user
> > interface, the connect command can be executed from start up procedure.
> >
> > In another senario to connect devices to a Linux based cloud service
> > using WebSocket proxy, it's needed to establish connection from a
> > device inside of firewall to a service outside. Exporting is suitable
> > for the senario.
> >
> >Home/SOHO/Intranet   Internet
> >+--+ ++   ++
> >  +--+  |Linux |+|Router, |   |Internet|
> > +|device|--|Controller|||proxy,  |---|service |
> > |+--+  +--+||firewall|   

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Lukas Wunner]

On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > In short, Pierre's USB host controller doesn't send wakeup signals from
> > runtime suspend, because the firmware limits the runtime-suspend state
> > to D0 and the controller can't issue PME# from the D0 state.  In this
> > situation we would prefer to avoid suspending the controller at all,
> > rather than have it go into runtime suspend and then stop working.

As Alan has correctly pointed out below, there are PCI devices which
do not support PME but should still be runtime suspended, e.g. because
they have some non-standard mechanism to sideband signal wakeup or
because they can detect when they need to resume even if they're in
a low-power state.

AFAIUI, this device should not be runtime suspended at all because it
doesn't generate a PME interrupt and thus stays suspended forever.

The PCI core doesn't allow runtime PM by default.  Rather it calls
pm_runtime_forbid() when the device is added (see pci_pm_init(), called
indirectly from pci_device_add()).  PCI drivers need to explicitly call
pm_runtime_allow(), typically from their ->probe hook.

If this xHC cannot signal wakeup, it shouldn't allow runtime PM in the
first place.  Simple as that.

The USB core has a function usb_enable_autosuspend() which does nothing
else but call pm_runtime_allow().  This is called in a couple of places,
I guess the relevant caller here is drivers/usb/core/hub.c:hub_probe().
I'd suggest to amend that function so that runtime PM isn't allowed
if the host controller can't signal plug events from pci_target_state().

This approach is better than returning -EBUSY from the ->runtime_suspend
hook because the PM core doesn't waste CPU cycles by repeatedly calling
->runtime_suspend in vain, always getting -EBUSY back.

HTH,

Lukas

> > 
> > On Wed, 5 Oct 2016, Mathias Nyman wrote:
> > 
> > > On 04.10.2016 17:11, Alan Stern wrote:
> > > > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> > > >
> > > >> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> > > >>> Hi Mathias,
> > > >>>
> > > >>> Just to know: does that mean the firmware from Asus is faulty in 
> > > >>> here? Do you
> > > >>> think I should contact Asus about this?
> > > >>>
> > > >>
> > > >> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI 
> > > >> DSDT firmware version.
> > > >>
> > > >> But we still want the driver to handle cases like this.
> > > >> Just wrote the patch.
> > > >> Adding Alan Stern to CC for PM sanity feedback on it:
> > > >>
> > > >> ---
> > > >>
> > > >> Author: Mathias Nyman 
> > > >> Date:   Tue Oct 4 13:07:59 2016 +0300
> > > >>
> > > >>   xhci: Prevent a non-responsive xhci suspend state.
> > > >>
> > > >>   ACPI may limit the lowest possible runtime suspend PCI D-state 
> > > >> to D0.
> > > >>   If xHC is not capable of generating PME# events in D0 we end
> > > >>   up with a non-responsive runtime suspended host without PME# 
> > > >> capability
> > > >>   and with interrupts disabled, unable to detect or wake up when a
> > > >>   new usb device is connected.
> > > >>
> > > >>   This was triggered on a ASUS TP301UA machine.
> > > >>
> > > >>   Reported-by: Pierre de Villemereuil 
> > > >>   Signed-off-by: Mathias Nyman 
> > > >>
> > > >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > > >> index d7b0f97..08b021c 100644
> > > >> --- a/drivers/usb/host/xhci-pci.c
> > > >> +++ b/drivers/usb/host/xhci-pci.c
> > > >> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, 
> > > >> bool do_wakeup)
> > > >>   if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
> > > >>   xhci_ssic_port_unused_quirk(hcd, true);
> > > >>
> > > >> +   /* Prevent a non-responsive PCI D0 state without PME# wake 
> > > >> capability */
> > > >> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> > > >> +   if (!pci_pme_capable(pdev, PCI_D0))
> > > >> +   return -EBUSY;
> > > >> +
> > > >>   ret = xhci_suspend(xhci, do_wakeup);
> > > >>   if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
> > > >>   xhci_ssic_port_unused_quirk(hcd, false);
> > > >
> > > > I've got three comments about this proposal.
> > > >
> > > > First, this logic should not apply during system suspend, only during
> > > > runtime suspend.  You don't want to abort putting a laptop to sleep
> > > > just because the xHCI controller can't generate wakeup signals.
> > > 
> > > Yes, I assume it would be ok change usb core to pass down something like
> > > pm_message_t to suspend_common() so that we could do this.
> > > hcd_pci_runetime_suspend()  -> suspend_common()  -> 
> > > hcd->driver->pci_suspend()
> > > 
> > > Assuming this workaround should stay in xhci-pci.c
> > 
> > If necessary, it could be moved 

Re: [PATCH] usb/core: Added devspec sysfs entry for devices behind usb hub

[Vijay Kumar]

On 10/4/2016 2:49 PM, Greg KH wrote:

On Tue, Oct 04, 2016 at 12:04:40PM -0700, Vijay Kumar wrote:

Grub finds incorrect of_node path for devices behind usb hub.
Added devspec sysfs entry for devices behind usb hub so that
right of_node path is returned during grub sysfs walk for these
devices.

Signed-off-by: Vijay Kumar 

---
  drivers/usb/core/sysfs.c |   15 +++
  1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index c953a0f..84d66d5 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "usb.h"
  
  /* Active configuration fields */

@@ -104,6 +105,17 @@ static ssize_t bConfigurationValue_store(struct device 
*dev,
  static DEVICE_ATTR_IGNORE_LOCKDEP(bConfigurationValue, S_IRUGO | S_IWUSR,
bConfigurationValue_show, bConfigurationValue_store);
  
+#ifdef CONFIG_OF

+static ssize_t devspec_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   struct device_node *of_node = dev->of_node;
+
+   return sprintf(buf, "%s\n", of_node_full_name(of_node));
+}
+static DEVICE_ATTR_RO(devspec);
+#endif

Any way to do this without the #ifdef?

Thanks for your comment. I looked into it again and find that grub would
report ofpath incorrectly if CONFIG_OF not defined but devspec sysfs 
file exists.

I see pci-sysfs.c has  also defines devspec in same way.


And you need to also update Documentation/ABI if you add a new sysfs
file.


Sure,  if you agree with my above comment then should I make Document/ABI
changes in a separate patch?

Thanks,
Vijay

--
To unsubscribe from this list: send the line "unsubscribe 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: USB hot-plug not working (ASUS TP301UA-C4028T)

[Bjorn Helgaas]

[+cc Rafael, Lukas]

On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> [Adding Bjorn and linux-pci to the CC: list]
> 
> In short, Pierre's USB host controller doesn't send wakeup signals from
> runtime suspend, because the firmware limits the runtime-suspend state
> to D0 and the controller can't issue PME# from the D0 state.  In this
> situation we would prefer to avoid suspending the controller at all,
> rather than have it go into runtime suspend and then stop working.
> 
> On Wed, 5 Oct 2016, Mathias Nyman wrote:
> 
> > On 04.10.2016 17:11, Alan Stern wrote:
> > > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> > >
> > >> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> > >>> Hi Mathias,
> > >>>
> > >>> Just to know: does that mean the firmware from Asus is faulty in here? 
> > >>> Do you
> > >>> think I should contact Asus about this?
> > >>>
> > >>
> > >> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI 
> > >> DSDT firmware version.
> > >>
> > >> But we still want the driver to handle cases like this.
> > >> Just wrote the patch.
> > >> Adding Alan Stern to CC for PM sanity feedback on it:
> > >>
> > >> ---
> > >>
> > >> Author: Mathias Nyman 
> > >> Date:   Tue Oct 4 13:07:59 2016 +0300
> > >>
> > >>   xhci: Prevent a non-responsive xhci suspend state.
> > >>
> > >>   ACPI may limit the lowest possible runtime suspend PCI D-state to 
> > >> D0.
> > >>   If xHC is not capable of generating PME# events in D0 we end
> > >>   up with a non-responsive runtime suspended host without PME# 
> > >> capability
> > >>   and with interrupts disabled, unable to detect or wake up when a
> > >>   new usb device is connected.
> > >>
> > >>   This was triggered on a ASUS TP301UA machine.
> > >>
> > >>   Reported-by: Pierre de Villemereuil 
> > >>   Signed-off-by: Mathias Nyman 
> > >>
> > >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > >> index d7b0f97..08b021c 100644
> > >> --- a/drivers/usb/host/xhci-pci.c
> > >> +++ b/drivers/usb/host/xhci-pci.c
> > >> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, 
> > >> bool do_wakeup)
> > >>   if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
> > >>   xhci_ssic_port_unused_quirk(hcd, true);
> > >>
> > >> +   /* Prevent a non-responsive PCI D0 state without PME# wake 
> > >> capability */
> > >> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> > >> +   if (!pci_pme_capable(pdev, PCI_D0))
> > >> +   return -EBUSY;
> > >> +
> > >>   ret = xhci_suspend(xhci, do_wakeup);
> > >>   if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
> > >>   xhci_ssic_port_unused_quirk(hcd, false);
> > >
> > > I've got three comments about this proposal.
> > >
> > > First, this logic should not apply during system suspend, only during
> > > runtime suspend.  You don't want to abort putting a laptop to sleep
> > > just because the xHCI controller can't generate wakeup signals.
> > 
> > Yes, I assume it would be ok change usb core to pass down something like
> > pm_message_t to suspend_common() so that we could do this.
> > hcd_pci_runetime_suspend()  -> suspend_common()  -> 
> > hcd->driver->pci_suspend()
> > 
> > Assuming this workaround should stay in xhci-pci.c
> 
> If necessary, it could be moved into hcd_pci_runtime_suspend().  But I 
> would prefer to put it in the PCI core.
> 
> > > Second, this really has nothing to do with the D0 state.  The same
> > > logic should apply to whatever state is chosen for runtime suspend: If
> > > the controller can't generate PME# wakeup signals in that state then
> > > the suspend should be aborted.
> > 
> > PCI code actually does this for us, it will walk down the D-states until
> > it finds one that support PME#, but stop at D0 end return D0 even if D0
> > does not support PME#.
> 
> That sounds like a bug.  Or rather, accepting D0 as the target state
> when it doesn't support PME# is the bug.
> 
> > Unfortunately that is done in a static function in pci/pci.c.
> > 
> > static pci_power_t pci_target_state(struct pci_dev *dev)
> > {
> >  pci_power_t target_state = PCI_D3hot;
> > 
> > if (platform_pci_power_manageable(dev)) {
> >  /*
> >   * Call the platform to choose the target state of the 
> > device
> >   * and enable wake-up from this state if supported.
> >   */
> >  pci_power_t state = platform_pci_choose_state(dev);
> > 
> > switch (state) {
> > case PCI_POWER_ERROR:
> >  case PCI_UNKNOWN:
> >  break;
> >  case PCI_D1:
> >  case PCI_D2:
> >  if (pci_no_d1d2(dev))
> > break;
> >  default:
> >  

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

[Adding Bjorn and linux-pci to the CC: list]

In short, Pierre's USB host controller doesn't send wakeup signals from
runtime suspend, because the firmware limits the runtime-suspend state
to D0 and the controller can't issue PME# from the D0 state.  In this
situation we would prefer to avoid suspending the controller at all,
rather than have it go into runtime suspend and then stop working.

On Wed, 5 Oct 2016, Mathias Nyman wrote:

> On 04.10.2016 17:11, Alan Stern wrote:
> > On Tue, 4 Oct 2016, Mathias Nyman wrote:
> >
> >> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> >>> Hi Mathias,
> >>>
> >>> Just to know: does that mean the firmware from Asus is faulty in here? Do 
> >>> you
> >>> think I should contact Asus about this?
> >>>
> >>
> >> Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI DSDT 
> >> firmware version.
> >>
> >> But we still want the driver to handle cases like this.
> >> Just wrote the patch.
> >> Adding Alan Stern to CC for PM sanity feedback on it:
> >>
> >> ---
> >>
> >> Author: Mathias Nyman 
> >> Date:   Tue Oct 4 13:07:59 2016 +0300
> >>
> >>   xhci: Prevent a non-responsive xhci suspend state.
> >>
> >>   ACPI may limit the lowest possible runtime suspend PCI D-state to D0.
> >>   If xHC is not capable of generating PME# events in D0 we end
> >>   up with a non-responsive runtime suspended host without PME# 
> >> capability
> >>   and with interrupts disabled, unable to detect or wake up when a
> >>   new usb device is connected.
> >>
> >>   This was triggered on a ASUS TP301UA machine.
> >>
> >>   Reported-by: Pierre de Villemereuil 
> >>   Signed-off-by: Mathias Nyman 
> >>
> >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> >> index d7b0f97..08b021c 100644
> >> --- a/drivers/usb/host/xhci-pci.c
> >> +++ b/drivers/usb/host/xhci-pci.c
> >> @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
> >> do_wakeup)
> >>   if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
> >>   xhci_ssic_port_unused_quirk(hcd, true);
> >>
> >> +   /* Prevent a non-responsive PCI D0 state without PME# wake 
> >> capability */
> >> +   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
> >> +   if (!pci_pme_capable(pdev, PCI_D0))
> >> +   return -EBUSY;
> >> +
> >>   ret = xhci_suspend(xhci, do_wakeup);
> >>   if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
> >>   xhci_ssic_port_unused_quirk(hcd, false);
> >
> > I've got three comments about this proposal.
> >
> > First, this logic should not apply during system suspend, only during
> > runtime suspend.  You don't want to abort putting a laptop to sleep
> > just because the xHCI controller can't generate wakeup signals.
> 
> Yes, I assume it would be ok change usb core to pass down something like
> pm_message_t to suspend_common() so that we could do this.
> hcd_pci_runetime_suspend()  -> suspend_common()  -> hcd->driver->pci_suspend()
> 
> Assuming this workaround should stay in xhci-pci.c

If necessary, it could be moved into hcd_pci_runtime_suspend().  But I 
would prefer to put it in the PCI core.

> > Second, this really has nothing to do with the D0 state.  The same
> > logic should apply to whatever state is chosen for runtime suspend: If
> > the controller can't generate PME# wakeup signals in that state then
> > the suspend should be aborted.
> 
> PCI code actually does this for us, it will walk down the D-states until
> it finds one that support PME#, but stop at D0 end return D0 even if D0
> does not support PME#.

That sounds like a bug.  Or rather, accepting D0 as the target state
when it doesn't support PME# is the bug.

> Unfortunately that is done in a static function in pci/pci.c.
> 
> static pci_power_t pci_target_state(struct pci_dev *dev)
> {
>  pci_power_t target_state = PCI_D3hot;
> 
>   if (platform_pci_power_manageable(dev)) {
>  /*
>   * Call the platform to choose the target state of the device
>   * and enable wake-up from this state if supported.
>   */
>  pci_power_t state = platform_pci_choose_state(dev);
> 
>   switch (state) {
>   case PCI_POWER_ERROR:
>  case PCI_UNKNOWN:
>  break;
>  case PCI_D1:
>  case PCI_D2:
>  if (pci_no_d1d2(dev))
>   break;
>  default:
>   target_state = state;
>  }
>  } else if (!dev->pm_cap) {
>  target_state = PCI_D0;
>  } else if (device_may_wakeup(>dev)) {
>  /*
>   * Find the deepest state from which the device can generate
>   * wake-up 

Re: PROBLEM: am3517 usb-ohci not working

[Tony Lindgren]

* Łukasz Pułka  [161004 23:36]:
> 
> Can you point me what else should I check to make USB HS working in ohci mode?

Sounds like you're pretty close, in addition to the
pin muxing and PHY configuration, check also that you
have proper VBUS coming to the ports.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7

[Stefan Tauner]

This adds support to ftdi_sio for the Infineon TriBoard TC2X7
engineering board for first-generation Aurix SoCs with Tricore CPUs.
Mere addition of the device IDs does the job.

Signed-off-by: Stefan Tauner 
---
 drivers/usb/serial/ftdi_sio.c | 3 ++-
 drivers/usb/serial/ftdi_sio_ids.h | 5 +++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index b2d767e..0ff7f38 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -986,7 +986,8 @@ static const struct usb_device_id id_table_combined[] = {
/* ekey Devices */
{ USB_DEVICE(FTDI_VID, FTDI_EKEY_CONV_USB_PID) },
/* Infineon Devices */
-   { USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
+   { USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, 
INFINEON_TRIBOARD_TC1798_PID, 1) },
+   { USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, 
INFINEON_TRIBOARD_TC2X7_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
/* Active Research (Actisense) devices */
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index f87a938..21011c0 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -626,8 +626,9 @@
 /*
  * Infineon Technologies
  */
-#define INFINEON_VID   0x058b
-#define INFINEON_TRIBOARD_PID  0x0028 /* DAS JTAG TriBoard TC1798 V1.0 */
+#define INFINEON_VID   0x058b
+#define INFINEON_TRIBOARD_TC1798_PID   0x0028 /* DAS JTAG TriBoard TC1798 V1.0 
*/
+#define INFINEON_TRIBOARD_TC2X7_PID0x0043 /* DAS JTAG TriBoard TC2X7 V1.0 
*/
 
 /*
  * Acton Research Corp.
-- 
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] USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7

[Oliver Neukum]

On Wed, 2016-10-05 at 10:29 +0200, Stefan Tauner wrote:
> On Wed, 05 Oct 2016 09:31:29 +0200
> Oliver Neukum  wrote:
> 
> > On Fri, 2016-09-30 at 17:39 +0200, Stefan Tauner wrote:
> > > Signed-off-by: Stefan Tauner   
> > 
> > A minimal change log entry would be good.
> 
> Hi Oliver,
> 
> I thought about it but there is really not much to say about it that I
> deem important. What kind of information are you looking for/expecting?

Something like:

This adds support for device X to driver Y. Mere addition of the device
IDs does the job.

HTH
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] phy: nop: Add a new phy driver for No-Op transceiver

[Kishon Vijay Abraham I]

Hi,

On Tuesday 04 October 2016 04:13 PM, Vivek Gautam wrote:
> No-Op phy transceiver can be used on platforms that have
> controllers which themselves provide PHY functionality and
> there's no separate PHY controller available.
> 
> This driver provides a basic skeleton for a nop-phy driver.
> This can be further extended to add required features.
> 
> Inspired by phy-generic driver in drivers/usb/phy.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Kishon Vijay Abraham I 
> Cc: Felipe Balbi 
> ---
> 
> Hi Kishon, Felipe,
> 
> This patch has been lying in my tree for sometime.
> This introduces a skeletal nop-phy driver based on generic
> phy framework.
> I mainly use this driver when I have only one phy driver available
> for testing for a controller that uses more than one phy.
> 
> But this can be further extended to add any feature support for
> controllers that don't have a separate PHY controller and that
> themselves provide the PHY functionality, a purpose similar
> to what drivers/usb/phy/phy-generic.c driver serves.
> 
> Do you think we have a requirement for such a driver in the generic
> phy layer? I hope this driver can do some good.
> Let me know your comments on this.
> 
> Thanks
> Vivek
> 
>  Documentation/devicetree/bindings/phy/phy-nop.txt |  22 +++
>  drivers/phy/Kconfig   |  10 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-nop.c | 193 
> ++
>  4 files changed, 226 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-nop.txt
>  create mode 100644 drivers/phy/phy-nop.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-nop.txt 
> b/Documentation/devicetree/bindings/phy/phy-nop.txt
> new file mode 100644
> index 000..6cb6779
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-nop.txt
> @@ -0,0 +1,22 @@
> +Generic No-Op PHY
> +-
> +
> +Required properties:
> + - compatible: compatible list, contains "phy-nop".
> + - #phy-cells: must be 0.
> +
> +Optional properties:
> + - clocks: a list of phandles and clock-specifier pairs,
> +one for each entry in clock-names.
> + - clock-names: must be "main_clk" for phy core clock,
> + "ref_clk" for phy reference clk.
> + - resets: a list of phandles and reset controller specifier pairs,
> +one for each entry in reset-names.
> + - reset-names: must be  "phy" for reset of phy block.
> + - vdd-supply: Phandle to a regulator supply to PHY core block.
> +
> +Example:
> + phy_nop: phy_nop {
> + compatible = "phy-nop";
> + #phy-cells = <0>;
> + };

I don't think this qualifies to be modeled as dt. device tree should try to
represent HW and not workaround SW issues by creating dummy nodes. For such
cases phy_optional_get should suffice?

I'm more towards having a simple-phy, along the lines of [1]

[1] -> https://patchwork.kernel.org/patch/8153691/

Thanks
Kishon
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..1923c4f 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -489,4 +489,14 @@ config PHY_NS2_PCIE
>   help
> Enable this to support the Broadcom Northstar2 PCIe PHY.
> If unsure, say N.
> +
> +config PHY_NOP
> + tristate "No-Operation PHY transceiver driver"
> + depends on OF || COMPILE_TEST
> + select GENERIC_PHY
> + help
> +   Enable this to support the generic no-operation PHY
> +   transeiver. This driver can be used with consumers
> +   requiring a no-op phy for few of the handlers.
> +
>  endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a534cf5..d6e0e60 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -60,3 +60,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) += 
> phy-pistachio-usb.o
>  obj-$(CONFIG_PHY_CYGNUS_PCIE)+= phy-bcm-cygnus-pcie.o
>  obj-$(CONFIG_ARCH_TEGRA) += tegra/
>  obj-$(CONFIG_PHY_NS2_PCIE)   += phy-bcm-ns2-pcie.o
> +obj-$(CONFIG_PHY_NOP)+= phy-nop.o
> diff --git a/drivers/phy/phy-nop.c b/drivers/phy/phy-nop.c
> new file mode 100644
> index 000..cab01a1
> --- /dev/null
> +++ b/drivers/phy/phy-nop.c
> @@ -0,0 +1,193 @@
> +/*
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[NeilBrown]

On Wed, Oct 05 2016, Felipe Balbi wrote:

> Hi Baolin,
>
> Baolin Wang  writes:
 But you do!
 The mA number from the USB configuration is passed to usb_gadget_vbus_draw.
 Your patch passes that to usb_charger_set_cur_limit_by_type()
 which calls __usb_charger_set_cur_limit_by_type() which will set the
 cur_limit for whichever type uchger->type currently is.

 So when it is not relevant, your code *does* set some current limit.
>>>
>>> Suppose the charger type is DCP(it is not relevant to the mA number
>>> from the USB configuration ), it will not do the USB enumeration, then
>>> no USB configuration from host to set current.
>>
>> From the talking, there are some issues (thanks for Neil's comments)
>> need to be fixed as below:
>> 1. Need to add the method getting charger type from extcon subsystem.
>> 2. Need to remove the method getting charger type from power supply.
>> 3. There are still some different views about reporting the maximum
>> current or minimum current to power driver.
>>
>> Now the current v16 patchset can work well on my Spreadtrum platform
>> and Jun's NXP platform, if you like to apply this patchset then I can

I'm really curious how much testing this has had.  Have you actually
plugged in different cable types (SDP DCP DCP ACA) and has each one been
detected correctly?  Because I cannot see how that could happen with the
code you have posted.

>> send out new patches to fix above issues. If you don't like that, I
>> can send out new version patchset to fix above issues. Could you  give
>> me some suggestions what should I do next step? Thanks.
>
> Merge window just opened, nothing will happen for about 2 weeks. How
> about you send a new version after merge window closes and we go from
> there? Fixing 1 and 2 is needed. 3 we need to consider more
> carefully. Perhaps report both minimum and maximum somehow?
>
> Neil, comments?

This probably seems a bit harsh, but I really think the current patchset
should be discarded and the the project started again with a clear
vision of what is required.  What we currently have is too confused.

To respond to the points:
>> 1. Need to add the method getting charger type from extcon subsystem.

Yes.  This should be the only way to get the charger type.

>> 2. Need to remove the method getting charger type from power supply.

Also need to remove the ->get_charger_type() method as there is no
credible use-case for this.

>> 3. There are still some different views about reporting the maximum
>> current or minimum current to power driver.

I think those were resolved.  There was some confusion over whether a
particular power manager wanted to be told the maximum or the minimum,
but I think both have a clear use case in different hardware.

Also: We don't want another notifier_chain.  The usb_notifier combined
with the extcon notifier are sufficient.  Possibly it would be sensible
to replace the usb notifier with a new new notifier chain, but don't add
something without first cleaning up what is there.

Also: resolve the question of whether it could ever make sense to have
 more than one "usb_charger" in a system.  If it doesn't, make it an
 obvious singleton.  If it does, make it clear how the correct
 usb_charger is chosen.

Also: think very carefully before exposing any details through sysfs.
  Some of the details are already visible, either in sys/class/extcon
  or sys/class/power_supply.  Don't duplicate without good reason.


NeilBrown



>
> -- 
> balbi


signature.asc
Description: PGP signature

Re: [PATCH] USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7

[Stefan Tauner]

On Wed, 05 Oct 2016 09:31:29 +0200
Oliver Neukum  wrote:

> On Fri, 2016-09-30 at 17:39 +0200, Stefan Tauner wrote:
> > Signed-off-by: Stefan Tauner   
> 
> A minimal change log entry would be good.

Hi Oliver,

I thought about it but there is really not much to say about it that I
deem important. What kind of information are you looking for/expecting?

KR
-- 
Dipl.-Ing. Stefan Tauner
Research and Development
Embedded Systems Department

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 6, 1200 Vienna, Austria
T: +43 1 333 40 77-316
E: stefan.tau...@technikum-wien.at
I: embsys.technikum-wien.at
I: www.technikum-wien.at
--
To unsubscribe from this list: send the line "unsubscribe 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: USB hot-plug not working (ASUS TP301UA-C4028T)

[Mathias Nyman]

On 04.10.2016 17:11, Alan Stern wrote:

On Tue, 4 Oct 2016, Mathias Nyman wrote:


On 03.10.2016 23:54, Pierre de Villemereuil wrote:

Hi Mathias,

Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?



Probably, _S0W, _DSM  and XFLT code for xHCI are useless in that ACPI DSDT 
firmware version.

But we still want the driver to handle cases like this.
Just wrote the patch.
Adding Alan Stern to CC for PM sanity feedback on it:

---

Author: Mathias Nyman 
Date:   Tue Oct 4 13:07:59 2016 +0300

  xhci: Prevent a non-responsive xhci suspend state.

  ACPI may limit the lowest possible runtime suspend PCI D-state to D0.
  If xHC is not capable of generating PME# events in D0 we end
  up with a non-responsive runtime suspended host without PME# capability
  and with interrupts disabled, unable to detect or wake up when a
  new usb device is connected.

  This was triggered on a ASUS TP301UA machine.

  Reported-by: Pierre de Villemereuil 
  Signed-off-by: Mathias Nyman 

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index d7b0f97..08b021c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
do_wakeup)
  if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
  xhci_ssic_port_unused_quirk(hcd, true);

+   /* Prevent a non-responsive PCI D0 state without PME# wake capability */
+   if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0)
+   if (!pci_pme_capable(pdev, PCI_D0))
+   return -EBUSY;
+
  ret = xhci_suspend(xhci, do_wakeup);
  if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED))
  xhci_ssic_port_unused_quirk(hcd, false);


I've got three comments about this proposal.

First, this logic should not apply during system suspend, only during
runtime suspend.  You don't want to abort putting a laptop to sleep
just because the xHCI controller can't generate wakeup signals.


Yes, I assume it would be ok change usb core to pass down something like
pm_message_t to suspend_common() so that we could do this.
hcd_pci_runetime_suspend()  -> suspend_common()  -> hcd->driver->pci_suspend()

Assuming this workaround should stay in xhci-pci.c



Second, this really has nothing to do with the D0 state.  The same
logic should apply to whatever state is chosen for runtime suspend: If
the controller can't generate PME# wakeup signals in that state then
the suspend should be aborted.


PCI code actually does this for us, it will walk down the D-states until
it finds one that support PME#, but stop at D0 end return D0 even if D0
does not support PME#.

Unfortunately that is done in a static function in pci/pci.c.

static pci_power_t pci_target_state(struct pci_dev *dev)
{
pci_power_t target_state = PCI_D3hot;

if (platform_pci_power_manageable(dev)) {
/*
 * Call the platform to choose the target state of the device
 * and enable wake-up from this state if supported.
 */
pci_power_t state = platform_pci_choose_state(dev);

switch (state) {
case PCI_POWER_ERROR:
case PCI_UNKNOWN:
break;
case PCI_D1:
case PCI_D2:
if (pci_no_d1d2(dev))
break;
default:
target_state = state;
}
} else if (!dev->pm_cap) {
target_state = PCI_D0;
} else if (device_may_wakeup(>dev)) {
/*
 * Find the deepest state from which the device can generate
 * wake-up events, make it the target state and enable device
 * to generate PME#.
 */
if (dev->pme_support) {
while (target_state
  && !(dev->pme_support & (1 << target_state)))
target_state--;
}
}

return target_state;
}

The best I can do from xhci is call pci_choose_state() which will call
platform_pci_choose_state(), but won't do the PME# checking and
D-state decrement to D0 .

If pci_choose_state() returns D0 from a runtime suspend callback
(and yes, should make sure its runtime suspend, not system suspend)
I can pretty much assume pci_target_state will do the same.



Third, the same reasoning applies to every PCI device that relies on
PME#, not just to xHCI controllers.  Therefore the new code should be
added to drivers/pci/pci-driver.c:pci_pm_runtime_suspend(), not to
xhci-pci.c.


Yes, that would be the preferred solution.
I was not sure we can do that. pci-driver.c 

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Felipe,

On 5 October 2016 at 15:47, Felipe Balbi  wrote:
>
> Hi Baolin,
>
> Baolin Wang  writes:
 But you do!
 The mA number from the USB configuration is passed to usb_gadget_vbus_draw.
 Your patch passes that to usb_charger_set_cur_limit_by_type()
 which calls __usb_charger_set_cur_limit_by_type() which will set the
 cur_limit for whichever type uchger->type currently is.

 So when it is not relevant, your code *does* set some current limit.
>>>
>>> Suppose the charger type is DCP(it is not relevant to the mA number
>>> from the USB configuration ), it will not do the USB enumeration, then
>>> no USB configuration from host to set current.
>>
>> From the talking, there are some issues (thanks for Neil's comments)
>> need to be fixed as below:
>> 1. Need to add the method getting charger type from extcon subsystem.
>> 2. Need to remove the method getting charger type from power supply.
>> 3. There are still some different views about reporting the maximum
>> current or minimum current to power driver.
>>
>> Now the current v16 patchset can work well on my Spreadtrum platform
>> and Jun's NXP platform, if you like to apply this patchset then I can
>> send out new patches to fix above issues. If you don't like that, I
>> can send out new version patchset to fix above issues. Could you  give
>> me some suggestions what should I do next step? Thanks.
>
> Merge window just opened, nothing will happen for about 2 weeks. How
> about you send a new version after merge window closes and we go from
> there? Fixing 1 and 2 is needed. 3 we need to consider more

Sure. I will send out the new version with fixing these issues. Thanks.

> carefully. Perhaps report both minimum and maximum somehow?
>
> Neil, comments?
>
> --
> balbi



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Anand Moon]

Hi Vivek,

On 5 October 2016 at 10:15, Vivek Gautam  wrote:
> Hi Anand,
>
>
> On Tue, Oct 4, 2016 at 8:39 PM, Anand Moon  wrote:
>> Hi Vivek,
>>
>
> [snip]
>
>>
>> What I feel is that their need to be some reset of usb phy so that
>> device are assigned to respective bus ports.
>
> The phy resets are what we do in the phy-exynos5-usbdrd driver. In
> addition to what we
> have currently in this phy driver, we just need the phy calibration
> patch [1] for phy configurations.
>
> [1] https://lkml.org/lkml/2015/2/2/259

Yes I am only using the above patch.
If you dont mind please resend this patch again.

>
>> odroid@odroid:~$ lsusb -t
>> /:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
>> /:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
>> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
>
> This shows the ethernet device gets detected on the high-speed port of one
> of the controller.
> The lsusb output for kernel v4.7.x posted by Michael show that the
> ethernet device got detected on super-speed port of the controller.
> So, there seems to be a difference between the two.
> Or, is this how it is behaving ?

With other patches it miss behaves and the ethernet land onto another bus
port
.


> Is this lsusb output on 4.8 kernel with the patch [1] ?

Yes correct.

>
>> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
>> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 
>> 5000M
>> |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 
>> 5000M
>> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M
>> |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
>>
>>
>> Bus 06.Port should register the Realtek Ethernet r8153 device.
>> But I am not able to trace out how it's should happen.
>
> If i understand, below is how the configuration looks like on the board?
>
> +---+
> +-->|   |
> |   |   Bus 6   |---+
> +---+   |(super-speed)  |   |
> |   |   +---+   |
> |Controller |   | > Ethernet device
> |2  |   |
> |   |   +---+   |
> +---+   |   |   |
> |   |   Bus 5   |---+
> +-->|   (high-speed)|
> +---+
>
>
> +---+
> +-->|   |
> |   |   Bus 4   |---+
> +---+   |(super-speed)  |   |
> |   |   +---+   |
> |Controller |   | > (On board
> hub ?? _OR_ external hub with downstream devices) ???
> |1  |   |
> |   |   +---+   |
> +---+   |   |   |
> |   |   Bus 3   |---+
> +-->|   (high-speed)|
> +---+
>
[snip]

Yes this is correct mapping of usb ports and ethernet on the board.

Below is the schematic of the board.

http://dn.odroid.com/5422/ODROID-XU4/Schematics/XU4_MAIN_REV0.1_20151202.pdf

I have couple of questions so if you can help me out.

1 > Their is no vbus pin connector to the usb ports ?

2 > I have also tried to configure usbdrd_dwc3_0/1 nodes with no luck
snps,usb3_lpm_capable;
snps,dis_u3_susphy_quirk;
snps,dis_u2_susphy_quirk;

3 > do you feel their could be way to reset the USB PHY (ethenet)
   either though the DTS using gpio and pincrt

4 > how should be the port mapping done to the usb hub.
  Odroid XU4 has 2 usb 3.0 and 1 ehci port.
  Odroid XU3 has 1 usb 3.0 and 1 usb 3.0 otg port and 4 ehci
port


I would like to know how to debug low level debug of USB connection.
so that we could solve the issue.

Thanks for you help in looking to this, please guide me.
Attach is the logs of lsusb -v and console output.

-Best Regards
Anand Moon
odroid@odroid:~$ lsusb -v

Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3
  bMaxPacketSize0 9
  idVendor  

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Felipe Balbi]

Hi Baolin,

Baolin Wang  writes:
>>> But you do!
>>> The mA number from the USB configuration is passed to usb_gadget_vbus_draw.
>>> Your patch passes that to usb_charger_set_cur_limit_by_type()
>>> which calls __usb_charger_set_cur_limit_by_type() which will set the
>>> cur_limit for whichever type uchger->type currently is.
>>>
>>> So when it is not relevant, your code *does* set some current limit.
>>
>> Suppose the charger type is DCP(it is not relevant to the mA number
>> from the USB configuration ), it will not do the USB enumeration, then
>> no USB configuration from host to set current.
>
> From the talking, there are some issues (thanks for Neil's comments)
> need to be fixed as below:
> 1. Need to add the method getting charger type from extcon subsystem.
> 2. Need to remove the method getting charger type from power supply.
> 3. There are still some different views about reporting the maximum
> current or minimum current to power driver.
>
> Now the current v16 patchset can work well on my Spreadtrum platform
> and Jun's NXP platform, if you like to apply this patchset then I can
> send out new patches to fix above issues. If you don't like that, I
> can send out new version patchset to fix above issues. Could you  give
> me some suggestions what should I do next step? Thanks.

Merge window just opened, nothing will happen for about 2 weeks. How
about you send a new version after merge window closes and we go from
there? Fixing 1 and 2 is needed. 3 we need to consider more
carefully. Perhaps report both minimum and maximum somehow?

Neil, comments?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] USB: xhci: add port test modes support for USB2

[Felipe Balbi]

Hi,

Guoqing Zhang  writes:
> For USB2 ports, the port test modes TEST_J_State, Test_K_State,
> Test_Packet and Test_SE0_NAK can be enabled as described in USB2
> spec.
>
> Signed-off-by: Guoqing Zhang 
> ---
>  drivers/usb/host/xhci-hub.c | 55 
> +++--
>  1 file changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index d61fcc4..ccc558c 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -873,16 +873,18 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   u16 wIndex, char *buf, u16 wLength)
>  {
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + struct xhci_command *command;
>   int max_ports;
>   unsigned long flags;
>   u32 temp, status;
> - int retval = 0;
> + int i, retval = 0;
>   __le32 __iomem **port_array;
>   int slot_id;
>   struct xhci_bus_state *bus_state;
>   u16 link_state = 0;
>   u16 wake_mask = 0;
>   u16 timeout = 0;
> + u16 selector = 0;
>  
>   max_ports = xhci_get_ports(hcd, _array);
>   bus_state = >bus_state[hcd_index(hcd)];
> @@ -956,6 +958,8 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   link_state = (wIndex & 0xff00) >> 3;
>   if (wValue == USB_PORT_FEAT_REMOTE_WAKE_MASK)
>   wake_mask = wIndex & 0xff00;
> + if (wValue == USB_PORT_FEAT_TEST)
> + selector = (wIndex & 0xff00) >> 8;
>   /* The MSB of wIndex is the U1/U2 timeout */
>   timeout = (wIndex & 0xff00) >> 8;
>   wIndex &= 0xff;
> @@ -1014,7 +1018,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   break;
>   case USB_PORT_FEAT_LINK_STATE:
>   temp = readl(port_array[wIndex]);
> -

trailing change

>   /* Disable port */
>   if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
>   xhci_dbg(xhci, "Disable port %d\n", wIndex);
> @@ -1131,6 +1134,54 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   temp |= PORT_U2_TIMEOUT(timeout);
>   writel(temp, port_array[wIndex] + PORTPMSC);
>   break;
> + case USB_PORT_FEAT_TEST:
> + /* 4.19.6 Port Test Modes (USB2 Test Mode) */
> + if (hcd->speed != HCD_USB2)
> + goto error;
> + /* FIXME: Test_Force_Enable case to be implemented */
> + if (!selector || selector > 4)

Why don't you use our macros?

if (selector < TEST_J || selector > TEST_PACKET)
goto error;

> + goto error;
> + /* Disable all Device Slots */
> + for (i = 0; i < MAX_HC_SLOTS; i++) {
> + if (!xhci->dcbaa->dev_context_ptrs[i])
> + continue;
> + command = xhci_alloc_command(xhci, false,
> + false, GFP_KERNEL);
> + if (!command)
> + return -ENOMEM;
> + if (xhci_queue_slot_control(xhci, command,
> + TRB_DISABLE_SLOT, i)) {
> + xhci_err(xhci,
> + "Disable slot[%d] fail!\n", i);
> + goto error;
> + }
> + xhci_dbg(xhci, "Disable Slot[%d].\n", i);
> + }
> + /* Put all ports to the Disable state by clear PP */
> + xhci_dbg(xhci, "Disable all port (PP = 0)\n");
> + for (i = 0; i < max_ports; i++) {
> + temp = readl(port_array[i]);
> + temp &= ~PORT_POWER;
> + writel(temp, port_array[i]);
> + }
> + /* Stop the controller */
> + xhci_dbg(xhci, "Stop controller\n");
> + temp = readl(>op_regs->command);
> + temp &= ~CMD_RUN;
> + writel(temp, >op_regs->command);
> + if (xhci_handshake(>op_regs->status,
> + STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC)) {
> + xhci_warn(xhci, "Stop controller timeout\n");
> + return -ETIMEDOUT;
> + }
> + /* Disable runtime PM for test mode */
> + 

Re: [PATCH] USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7

[Oliver Neukum]

On Fri, 2016-09-30 at 17:39 +0200, Stefan Tauner wrote:
> Signed-off-by: Stefan Tauner 

A minimal change log entry would be good.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Felipe,

>> But you do!
>> The mA number from the USB configuration is passed to usb_gadget_vbus_draw.
>> Your patch passes that to usb_charger_set_cur_limit_by_type()
>> which calls __usb_charger_set_cur_limit_by_type() which will set the
>> cur_limit for whichever type uchger->type currently is.
>>
>> So when it is not relevant, your code *does* set some current limit.
>
> Suppose the charger type is DCP(it is not relevant to the mA number
> from the USB configuration ), it will not do the USB enumeration, then
> no USB configuration from host to set current.

>From the talking, there are some issues (thanks for Neil's comments)
need to be fixed as below:
1. Need to add the method getting charger type from extcon subsystem.
2. Need to remove the method getting charger type from power supply.
3. There are still some different views about reporting the maximum
current or minimum current to power driver.

Now the current v16 patchset can work well on my Spreadtrum platform
and Jun's NXP platform, if you like to apply this patchset then I can
send out new patches to fix above issues. If you don't like that, I
can send out new version patchset to fix above issues. Could you  give
me some suggestions what should I do next step? Thanks.

>
> --
> Baolin.wang
> Best Regards



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe 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: USB will randomly stop working

[Greg KH]

On Tue, Oct 04, 2016 at 11:07:20PM -0700, Ashton Holmes wrote:
> On Tue, Oct 4, 2016 at 10:18 PM, Greg KH  wrote:
> > On Tue, Oct 04, 2016 at 05:15:17PM -0700, Ashton Holmes wrote:
> >> On Tue, Oct 4, 2016 at 12:11 AM, Greg KH  
> >> wrote:
> >> >> Also my knowledge of git isn't that extensive and I got the source
> >> >> from the download on the site not from the git repo so it tells me
> >> >> there's no .git file but if I can figure out how to run that I'll give
> >> >> it a go.
> >> >
> >> > You can pull Linus's tree from git.kernel.org by doing:
> >> > git clone 
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >> >
> >> > and using your .config in that tree.
> >> >
> >> > There is lots of documentation of how to use 'git bisect' but if you
> >> > have any questions, please let us know.
> >>
> >> Alright this is the output of git bisect
> >> e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit
> >
> > That's a great start, but that's the first bad one, you need to now use
> > 'git bisect bad' and it will keep going and narrow it down to the commit
> > that causes the problem itself.
> 
> All the tutorials I saw ended when it got to the first bad commit. I
> went through and compiled 13 different kernels or so so wouldn't that
> be the commit that introduced the issue or am I missing something?

No, that's one "leaf" of the tree that does not work (it's a merge
commit so maybe something in that merge caused the issue).  You need to
keep going and find the real actual commit that caused the problem.  You
will probably run into a few 'good' and 'bad' commits from here on and
eventually git bisect will spit out a "this is the bad commit" message.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PROBLEM: am3517 usb-ohci not working

[Łukasz Pułka]

Hi,

I am trying to make 4.4 kernel working with old am3517 SOM
(http://www.dave.eu/products/som/texas_instruments/am3505-am3517_lizard).

Most of the peripherals are working know - however I got stuck with
usb ohci driver.

Both USB HS ports are connected to ISP1105, hardware is working with
old 2.6.32 based firmware.
I copied the MUXing (muxing is done by u-boot) and TLL/PHY
initialization from old kernel.

My DT entries are:

/ {
hsusb1_power: hsusb1_power_reg {
compatible = "regulator-fixed";
regulator-name = "hsusb1_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};

hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};

hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
vcc-supply = <_power>;
};

hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
vcc-supply = <_power>;
};
};


 {
port1-mode = "ohci-phy-6pin-datse0";
port2-mode = "ohci-phy-6pin-datse0";
};

 {
status = "disabled";
};


CORE_120M_FCLK clock is enabled.

Interrupts are working and kernel is notified when I plug in usb
drive. However usb device is it not enumerated.

I got following debug messages:
usb usb1-port1: Cannot enable. Maybe the USB cable is bad?

and finally:
usb usb1-port1: unable to enumerate USB device

also I can see log like this:
ohci-omap3 48064400.ohci: GetStatus roothub.portstatus [0] =
0x00120101 PRSC PESC PPS CCS

GetStatus message appears multiple times when usb device is plugged in.

I can see FSLSLINESTATE in TLL_CHANNEL_CONF changes when usb device is
connected:

./devmem2 0x48062040
Read at address  0x48062040 (0xb6f9b040): 0x1CDB

Can you point me what else should I check to make USB HS working in ohci mode?

Thank you  and best regards,
Luke
--
To unsubscribe from this list: send the line "unsubscribe 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: USB will randomly stop working

[Ashton Holmes]

On Tue, Oct 4, 2016 at 10:18 PM, Greg KH  wrote:
> On Tue, Oct 04, 2016 at 05:15:17PM -0700, Ashton Holmes wrote:
>> On Tue, Oct 4, 2016 at 12:11 AM, Greg KH  wrote:
>> >> Also my knowledge of git isn't that extensive and I got the source
>> >> from the download on the site not from the git repo so it tells me
>> >> there's no .git file but if I can figure out how to run that I'll give
>> >> it a go.
>> >
>> > You can pull Linus's tree from git.kernel.org by doing:
>> > git clone 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> >
>> > and using your .config in that tree.
>> >
>> > There is lots of documentation of how to use 'git bisect' but if you
>> > have any questions, please let us know.
>>
>> Alright this is the output of git bisect
>> e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit
>
> That's a great start, but that's the first bad one, you need to now use
> 'git bisect bad' and it will keep going and narrow it down to the commit
> that causes the problem itself.

All the tutorials I saw ended when it got to the first bad commit. I
went through and compiled 13 different kernels or so so wouldn't that
be the commit that introduced the issue or am I missing something?

> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html