Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

[Kunihiko Hayashi]

Hi,

On Thu, 25 Jan 2018 11:09:30 +0900  wrote:

> Hello Felipe,
> 
> On Wed, 24 Jan 2018 14:58:12 +0200  wrote:
> 
> > 
> > Hi,
> > 
> > Kunihiko Hayashi  writes:
> > > Hello Felipe,
> > >
> > > Thank you for your comments.
> > >
> > > On Tue, 23 Jan 2018 15:12:36 +0200  wrote:
> > >
> > >> 
> > >> Hi,
> > >> 
> > >> Kunihiko Hayashi  writes:
> > >> > Add a specific glue layer for UniPhier SoC platform to support
> > >> > USB host mode. It manages hardware operating sequences to enable 
> > >> > multiple
> > >> > clock gates and assert resets, and to prepare to use dwc3 controller
> > >> > on the SoC.
> > >> >
> > >> > This patch also handles the physical layer that has same register space
> > >> > as the glue layer, because it needs to integrate initialziation 
> > >> > sequence
> > >> > between glue and phy.
> > >> >
> > >> > In case of some SoCs, since some initialization values for PHY are
> > >> > included in nvmem, this patch includes the way to get the values from 
> > >> > nvmem.
> > >> >
> > >> > It supports PXs2 and LD20 SoCs.
> > >> >
> > >> > Signed-off-by: Kunihiko Hayashi 
> > >> > Signed-off-by: Motoya Tanigawa 
> > >> > Signed-off-by: Masami Hiramatsu 
> > >> > ---
> > >> >  drivers/usb/dwc3/Kconfig |   9 +
> > >> >  drivers/usb/dwc3/Makefile|   1 +
> > >> >  drivers/usb/dwc3/dwc3-uniphier.c | 554 
> > >> > +++
> > >> >  3 files changed, 564 insertions(+)
> > >> >  create mode 100644 drivers/usb/dwc3/dwc3-uniphier.c
> > >
> > > ...snip...
> > >
> > >> > +
> > >> > +static void dwc3u_ssphy_testio_write(struct dwc3u_priv *priv, int 
> > >> > port,
> > >> > +   u32 data)
> > >> 
> > >> anything with sshphy or hsphy in the name should probably be part of a
> > >> PHY driver using drivers/phy/ framework.
> > >
> > > I can try to separate phy control from this driver.
> > > However, phy registers belongs to "dwc3-glue" IO map area (65b0),
> > > and this area also contains a reset bit for "dwc3-core" hardware.
> > >
> > > Although the phy driver is called from dwc3-core driver,
> > > we need to deassert the reset bit before probing dwc3-core driver.
> > >
> > > As shown later, I think that it's difficut to determine the order of
> > > initializing the registers in this area.
> > >
> > >> > +static void dwc3u_vbus_disable(struct dwc3u_priv *priv)
> > >> > +{
> > >> > +  int i;
> > >> > +
> > >> > +  for (i = 0; i < priv->nvbus; i++) {
> > >> > +  dwc3u_maskwrite(priv, VBUS_CONTROL(i),
> > >> > +  DRVVBUS_REG_EN | DRVVBUS_REG,
> > >> > +  DRVVBUS_REG_EN | 0);
> > >> > +  }
> > >> > +}
> > >> 
> > >> drivers/regulator maybe?
> > >
> > > VBUS_CONTROL register is used for determing whether "dwc3-glue" hardware
> > > enables vbus connected with "regulator" hardware.
> > >
> > > The regulator driver should manage "regulator" hardware, and
> > > I don't think that the driver should manage this register.
> > >
> > >> > +static void dwc3u_reset_init(struct dwc3u_priv *priv)
> > >> > +{
> > >> > +  dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0);
> > >> > +  usleep_range(1000, 2000);
> > >> > +  dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, LINK_RESET);
> > >> > +}
> > >> > +
> > >> > +static void dwc3u_reset_clear(struct dwc3u_priv *priv)
> > >> > +{
> > >> > +  dwc3u_maskwrite(priv, RESET_CTL, LINK_RESET, 0);
> > >> > +}
> > >> 
> > >> drivers/reset ?
> > >
> > > The reset driver manages "sysctrl" IO map area in our SoC.
> > >
> > > RESET_CTL register belongs to "dwc3-glue" IO map area,
> > > and the kernel can't access this area until enabling usb clocks and
> > > deasserting usb resets in "sysctrl".
> > >
> > > I think that "dwc3-glue" register control should be separated from
> > > "sysctrl".
> > 
> > Just split your address space and treat your glue as a device with
> > several children:
> > 
> > glue@65b0 {
> > compatible = "foo"
> 
> Just to confirm, instead of SoC-specific glue driver, dwc3-of-simple.c
> should handle compatible "foo", right?

I understood this the answer was no.
We can define glue node as "simple-mfd" and/or "syscon", and the node
can include another function nodes like phy, sysctrl, and even dwc3-of-simple.

> > 
> > phy@bar {
> > ...
> > };
> > 
> > sysctrl@baz {
> > ...
> > };
> > 
> > dwc3@foo {
> > compatible = "snps, dwc3";
> > ...
> > };
> > };
> > 
> > Then you know that you can let dwc3/core.c handle the PHY for you. If we
> > need to teach dwc3/core.c about regulators, we can do that. But we don't
> > need SoC-specific hacks ;-)
> 
> I also don't think that dwc3/core.c should have any 

Darlehen Geld für Einzelpersonen und Fachleute in weniger als 72 Stunden

[Peter Schuster]

Hallo,

Sind Sie in einer schwierigen Situation, für die Sie sich für ein
Darlehen suchen? Benötigen Sie eine Finanzierung, um eine Schuld zu
begleichen oder eine Aktivität zu finanzieren? Haben Sie einen
Verbraucherkredit, eine Hypothek, einen persönlichen Kredit, eine
Hypothek, Investition Darlehen, Schuldenkonsolidierung Darlehen oder
andere braucht?

Ich bin ein einzelner Investor. I zur Verfügung stellen die Kredit
kurz-, mittel- und langfristige. Ihr Finanzierungsbedingungen sind
sehr einfach und meine Zinssatz beträgt 3% pro Jahr.

Für alle Anfragen, bleibe ich zur Verfügung, um Ihre Fragen zu beantworten.

Danke, dass Sie mir per E-Mail an Sie von  :   klaus.peterschus...@outlook.de

Mit freundlichen Grüßen.

Peter Schuster

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

Re: [PATCH 2/2] usb: chipidea: imx: Fix ULPI on imx53

[Peter Chen]

On Wed, Jan 24, 2018 at 06:14:39PM +0100, Sebastian Reichel wrote:
> Traditionally, PORTSC should be set before initializing ULPI phys. But
> setting PORTSC before powering on the phy results in a kernel freeze
> on imx53 based GE PPD. As a workaround this initializes the phy early
> in the imx platform code and disables phy power management from the
> core.
> 
> Signed-off-by: Fabien Lahoudere 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index de155c80eb70..e431c5aafe35 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
>   struct clk *clk;
>   struct imx_usbmisc_data *usbmisc_data;
>   bool supports_runtime_pm;
> + bool override_phy_control;
>   bool in_lpm;
>   /* SoC before i.mx6 (except imx23/imx28) needs three clks */
>   bool need_three_clks;
> @@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   int ret;
>   const struct of_device_id *of_id;
>   const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
> + struct device_node *np = pdev->dev.of_node;
>  
>   of_id = of_match_device(ci_hdrc_imx_dt_ids, >dev);
>   if (!of_id)
> @@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device 
> *pdev)
>   }
>  
>   pdata.usb_phy = data->phy;
> +
> + if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
> + of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
> + pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
> + data->override_phy_control = true;
> + usb_phy_init(pdata.usb_phy);
> + }
> +
>   pdata.flags |= imx_platform_flag->flags;
>   if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
>   data->supports_runtime_pm = true;
> @@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device 
> *pdev)
>   pm_runtime_put_noidle(>dev);
>   }
>   ci_hdrc_remove_device(data->ci_pdev);
> + if (data->override_phy_control)
> + usb_phy_shutdown(data->phy);
>   imx_disable_unprepare_clks(>dev);
>  
>   return 0;
> -- 

Applied both, thanks.

-- 

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: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Thu, Jan 25, 2018 at 10:20:02PM +, Mike Lothian wrote:
> I've just tried this and the USB-C device was detected :D This is the
> first time it's ever been detected after boot
> 
> 02:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 03:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 03:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 03:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 39:00.0 USB controller: Intel Corporation DSL6340 USB 3.1 Controller
> [Alpine Ridge]
>Subsystem: Device :
>Kernel driver in use: xhci_hcd

Yes, this is how it should work. All those PCI bridges + xHCI are
hotplugged when you plug in a USB-C device.
--
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-C Devices only show up if connected at boot

[Mika Westerberg]

On Thu, Jan 25, 2018 at 09:31:08PM +, Mike Lothian wrote:
> I've tried with and without those being set, neither help,  having
> CONFIG_HOTPLUG_PCI_ACPI=y on causes my NVMe drive to disappear after
> suspend

You *must* have those set, othewise the xHCI will not work. Can you do
so that you enable those options, boot without anything connected to the
USB-C port. Then when the system is up and running plug in your USB-C
device and see if it works or not. If it does not then send me full dmesg.

NVMe missing after suspend is a different issue, though.

> I'll switch back into windows and check I've the latest firmware for
> Thunderbolt, is there a way to do that on linux too?

I don't think that is needed since hotplug works in Windows. You can
upgrade NVM from Linux as well. See Documentation/admin-guide/thunderbolt.rst.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Fengguang Wu]

On Fri, Jan 26, 2018 at 10:58:56AM +1100, Benjamin Herrenschmidt wrote:

On Wed, 2018-01-24 at 11:30 +0800, kbuild test robot wrote:

Hi Benjamin,

I love your patch! Perhaps something to improve:

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.15-rc9 next-20180119]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]


This seems to be bogosity in m32r more than problems with the driver...


url:
https://github.com/0day-ci/linux/commits/Benjamin-Herrenschmidt/usb-gadget-Add-an-EP-dispose-callback-for-EP-lifetime-tracking/20180124-065635
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r

All warnings (new ones prefixed by >>):

   In file included from arch/m32r/include/uapi/asm/byteorder.h:8:0,
from arch/m32r/include/asm/bitops.h:22,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from drivers/usb/gadget/udc/aspeed-vhub/core.c:14:
   include/linux/byteorder/big_endian.h:8:2: warning: #warning inconsistent 
configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
 ^~~


Not sure what that one is, looks like some toolchain or arch problem...


   In file included from include/linux/printk.h:329:0,
from include/linux/kernel.h:14,
from drivers/usb/gadget/udc/aspeed-vhub/core.c:14:
   drivers/usb/gadget/udc/aspeed-vhub/core.c: In function 'ast_vhub_irq':
> > drivers/usb/gadget/udc/aspeed-vhub/core.c:127:16: warning: format '%x' 
expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' 
[-Wformat=]

 UDCVDBG(vhub, "irq status=%08x, ep_acks=%08x ep_nacks=%08x\n",


This is rather bogus too. m32r's readl() is returning unsigned long, it
should be unsigned int or u32.


Unfortunately m32r is marked orphaned in MAINTAINERS. We could stop
testing it if no one will step up to fix its issues.

Thanks,
Fengguang
--
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

[resend] Questions about "usb usb8-port1: cannot disable (err = -32)"

[Yoshihiro Shimoda]

I resent this email with adding Mathias, Alan and Greg as CC.

-Original Message-
From: Yoshihiro Shimoda, Sent: Thursday, January 18, 2018 6:03 PM
To: linux-usb@vger.kernel.org
Subject: Questions about "usb usb8-port1: cannot disable (err = -32)"

Hi,

My environment (R-Car H3) outputs the following error when I disconnected
a usb 3.0 SSD device from the xhci host controller.

[  267.755777] xhci-hcd ee00.usb: Cannot set link state.
[  267.761188] usb usb8-port1: cannot disable (err = -32)
[  267.772166] usb 8-1: USB disconnect, device number 2

But, the environment can detect connection again.

I investigate this issue and found the following commit is related:
  37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices

The xhci-hub.c has the following code:
if ((temp & PORT_PE) == 0 ||
(link_state > USB_SS_PORT_LS_U3)) {
xhci_warn(xhci, "Cannot set link state.\n");
goto error;
}

And, the code above will be called by hub_set_port_link_state(..., 
USB_SS_PORT_LS_U3)
in hub_port_disable():
/*
 * USB-3 does not have a similar link state as USB-2 that will avoid negotiating
 * a connection with a plugged-in cable but will signal the host when the cable
 * is unplugged. Disable remote wake and set link state to U3 for USB-3 devices
 */
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_device *hdev = hub->hdev;
int ret = 0;

if (!hub->error) {
if (hub_is_superspeed(hub->hdev)) {
hub_usb3_port_prepare_disable(hub, port_dev);
ret = hub_set_port_link_state(hub, port_dev->portnum,
  USB_SS_PORT_LS_U3);

The hub_port_disable() will be called by port_event():
   /*
 * Warm reset a USB3 protocol port if it's in
 * SS.Inactive state.
 */
if (hub_port_warm_reset_required(hub, port1, portstatus)) {
dev_dbg(_dev->dev, "do warm reset\n");
if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|| udev->state == USB_STATE_NOTATTACHED) {
if (hub_port_reset(hub, port1, NULL,
HUB_BH_RESET_TIME, true) < 0)
hub_port_disable(hub, port1, 1);

However, according to Figure 35 in xhci spec, the PED will be set to 0
after the usb3 root hub enters "Error" or "Disconnected" state.
So, IIUC, a usb driver should not call hub_set_port_link_state() in such a case.

Question 1:
 - Is my understanding correct?

Question 2:
 - How do I resolve the issue? (I don't have any idea for now...)

Best regards,
Yoshihiro Shimoda

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

Re: [PATCH v3 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

On Wed, 2018-01-24 at 11:30 +0800, kbuild test robot wrote:
> Hi Benjamin,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on balbi-usb/next]
> [also build test WARNING on v4.15-rc9 next-20180119]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]

This seems to be bogosity in m32r more than problems with the driver...

> url:
> https://github.com/0day-ci/linux/commits/Benjamin-Herrenschmidt/usb-gadget-Add-an-EP-dispose-callback-for-EP-lifetime-tracking/20180124-065635
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> config: m32r-allyesconfig (attached as .config)
> compiler: m32r-linux-gcc (GCC) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m32r 
> 
> All warnings (new ones prefixed by >>):
> 
>In file included from arch/m32r/include/uapi/asm/byteorder.h:8:0,
> from arch/m32r/include/asm/bitops.h:22,
> from include/linux/bitops.h:38,
> from include/linux/kernel.h:11,
> from drivers/usb/gadget/udc/aspeed-vhub/core.c:14:
>include/linux/byteorder/big_endian.h:8:2: warning: #warning inconsistent 
> configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
> #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
>  ^~~

Not sure what that one is, looks like some toolchain or arch problem...

>In file included from include/linux/printk.h:329:0,
> from include/linux/kernel.h:14,
> from drivers/usb/gadget/udc/aspeed-vhub/core.c:14:
>drivers/usb/gadget/udc/aspeed-vhub/core.c: In function 'ast_vhub_irq':
> > > drivers/usb/gadget/udc/aspeed-vhub/core.c:127:16: warning: format '%x' 
> > > expects argument of type 'unsigned int', but argument 5 has type 'long 
> > > unsigned int' [-Wformat=]
> 
>  UDCVDBG(vhub, "irq status=%08x, ep_acks=%08x ep_nacks=%08x\n",

This is rather bogus too. m32r's readl() is returning unsigned long, it
should be unsigned int or u32.

>^
>include/linux/dynamic_debug.h:135:39: note: in definition of macro 
> 'dynamic_dev_dbg'
>   __dynamic_dev_dbg(, dev, fmt, \
>   ^~~
>drivers/usb/gadget/udc/aspeed-vhub/vhub.h:405:28: note: in expansion of 
> macro 'dev_dbg'
> #define UDCVDBG(u, fmt...) dev_dbg(&(u)->pdev->dev, fmt)
>^~~
>drivers/usb/gadget/udc/aspeed-vhub/core.c:127:2: note: in expansion of 
> macro 'UDCVDBG'
>  UDCVDBG(vhub, "irq status=%08x, ep_acks=%08x ep_nacks=%08x\n",
>  ^~~
>drivers/usb/gadget/udc/aspeed-vhub/core.c:127:16: warning: format '%x' 
> expects argument of type 'unsigned int', but argument 6 has type 'long 
> unsigned int' [-Wformat=]
>  UDCVDBG(vhub, "irq status=%08x, ep_acks=%08x ep_nacks=%08x\n",
>^
>include/linux/dynamic_debug.h:135:39: note: in definition of macro 
> 'dynamic_dev_dbg'
>   __dynamic_dev_dbg(, dev, fmt, \
>   ^~~
>drivers/usb/gadget/udc/aspeed-vhub/vhub.h:405:28: note: in expansion of 
> macro 'dev_dbg'
> #define UDCVDBG(u, fmt...) dev_dbg(&(u)->pdev->dev, fmt)
>^~~
>drivers/usb/gadget/udc/aspeed-vhub/core.c:127:2: note: in expansion of 
> macro 'UDCVDBG'
>  UDCVDBG(vhub, "irq status=%08x, ep_acks=%08x ep_nacks=%08x\n",
>  ^~~
> --
>In file included from arch/m32r/include/uapi/asm/byteorder.h:8:0,
> from arch/m32r/include/asm/bitops.h:22,
> from include/linux/bitops.h:38,
> from include/linux/kernel.h:11,
> from drivers/usb/gadget/udc/aspeed-vhub/epn.c:14:
>include/linux/byteorder/big_endian.h:8:2: warning: #warning inconsistent 
> configuration, needs CONFIG_CPU_BIG_ENDIAN [-Wcpp]
> #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
>  ^~~
>In file included from include/linux/printk.h:329:0,
> from include/linux/kernel.h:14,
> from drivers/usb/gadget/udc/aspeed-vhub/epn.c:14:
>drivers/usb/gadget/udc/aspeed-vhub/epn.c: In function 
> 'ast_vhub_epn_kick_desc':
> > > drivers/usb/gadget/udc/aspeed-vhub/vhub.h:409:3: warning: format '%x' 
> > > expects argument of type 'unsigned int', but argument 7 has type 'long 
> > > unsigned int' [-Wformat=]
> 
>   "%s:EP%d " fmt,\
>   ^
>include/linux/dynamic_debug.h:135:39: note: in definition of macro 
> 'dynamic_dev_dbg'
>   __dynamic_dev_dbg(, dev, fmt, \
>   ^~~
>drivers/usb/gadget/udc/aspeed-vhub/vhub.h:408:2: note: in expansion of 
> macro 'dev_dbg'
>   

[PATCH v4 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.

The hub itself has HW provided dedicated EP0 and EP1 (the latter for
hub interrupts). It also has dedicated EP0s for each function. For
other endpoints, there's a pool of 15 "generic" endpoints that are
shared among the ports.

The driver relies on my previous patch adding a "dispose" EP op to
handle EP allocation between ports. EPs are allocated from the shared
pool in the UDC "match_ep" callback and assigned to the UDC instance
(added to the gadget ep_list).

When the composite driver gets unbound, the new hook will allow the UDC
to clean things up and return those EPs to the shared pool.

Signed-off-by: Benjamin Herrenschmidt 
---
v4. - Fix missing unlock ast_vhub_udc_wakeup() error path
- Make "irq" signed to deal with error from platform_get_irq
- Fix Makefile for module builds
- Fix a missing endian conversion

v3. - Rebased
- Add clk stuff

v2. - Cosmetic fixes
- Properly "allocate" device addresses instead of using a never
  reset counter
- Move .dtsi updates to a different patch

foo

goo
---
 drivers/usb/gadget/udc/Kconfig  |   2 +
 drivers/usb/gadget/udc/Makefile |   1 +
 drivers/usb/gadget/udc/aspeed-vhub/Kconfig  |   6 +
 drivers/usb/gadget/udc/aspeed-vhub/Makefile |   3 +
 drivers/usb/gadget/udc/aspeed-vhub/core.c   | 429 ++
 drivers/usb/gadget/udc/aspeed-vhub/dev.c| 580 +++
 drivers/usb/gadget/udc/aspeed-vhub/ep0.c| 474 
 drivers/usb/gadget/udc/aspeed-vhub/epn.c| 840 
 drivers/usb/gadget/udc/aspeed-vhub/hub.c| 822 +++
 drivers/usb/gadget/udc/aspeed-vhub/vhub.h   | 496 
 10 files changed, 3653 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Kconfig
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Makefile
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/core.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/dev.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/ep0.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/epn.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/hub.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/vhub.h

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 1e9567091d86..14cf31a2703a 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -439,6 +439,8 @@ config USB_GADGET_XILINX
  dynamically linked module called "udc-xilinx" and force all
  gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig"
+
 #
 # LAST -- dummy/emulated controller
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index ce865b129fd6..897f648f3cf1 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_USB_MV_U3D)  += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
 obj-$(CONFIG_USB_SNP_UDC_PLAT) += snps_udc_plat.o
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub/
 obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Kconfig 
b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
new file mode 100644
index ..cb022c885425
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
@@ -0,0 +1,6 @@
+config USB_ASPEED_VHUB
+   tristate "Aspeed vHub UDC driver"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   help
+ USB peripheral controller for the Aspeed AST2500 family
+ SoCs supporting the "vHub" functionality and USB2.0
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Makefile 
b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
new file mode 100644
index ..4256266c0a8a
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub.o
+aspeed-vhub-y  := core.o ep0.o epn.o dev.o hub.o
+
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c 
b/drivers/usb/gadget/udc/aspeed-vhub/core.c
new file mode 100644
index ..31ed2b6e241b
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
@@ -0,0 +1,429 @@
+/*
+ * aspeed-vhub -- Driver for Aspeed SoC "vHub" USB gadget
+ *
+ * core.c - Top level support
+ *
+ * Copyright 2017 IBM Corporation
+ *
+ * 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.
+ */
+
+#include 
+#include 

[PATCH v4 1/2] usb/gadget: Add an EP dispose() callback for EP lifetime tracking

[Benjamin Herrenschmidt]

Some UDC may want to allocate endpoints dynamically, either because
the HW supports an arbitrary large number or because (like the Aspeed
BMC SoCs), the pool of HW endpoints is shared between multiple gadgets.

The allocation side can be done rather easily using the existing
match_ep() UDC hook.

However we have no good place to "free" them.

This implements a "simple" variant of this, which calls an EP dispose
callback on all EPs associated with a gadget when the composite device
gets unbound.

This is required by my upcoming Aspeed vHub driver.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/usb/gadget/composite.c | 8 
 include/linux/usb/gadget.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 77c7ecca816a..ec99c9cfc1a2 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2172,6 +2172,7 @@ int composite_os_desc_req_prepare(struct 
usb_composite_dev *cdev,
 void composite_dev_cleanup(struct usb_composite_dev *cdev)
 {
struct usb_gadget_string_container *uc, *tmp;
+   struct usb_ep  *ep, *tmp_ep;
 
list_for_each_entry_safe(uc, tmp, >gstrings, list) {
list_del(>list);
@@ -2193,6 +2194,13 @@ void composite_dev_cleanup(struct usb_composite_dev 
*cdev)
}
cdev->next_string_id = 0;
device_remove_file(>gadget->dev, _attr_suspended);
+
+   /* Dispose EPs if the UDC driver tracks lifetime */
+   list_for_each_entry_safe(ep, tmp_ep,
+>gadget->ep_list, ep_list) {
+   if (ep->ops->dispose)
+   ep->ops->dispose(ep);
+   }
 }
 
 static int composite_bind(struct usb_gadget *gadget,
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 66a5cff7ee14..e3424234b23a 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -129,6 +129,7 @@ struct usb_ep_ops {
int (*enable) (struct usb_ep *ep,
const struct usb_endpoint_descriptor *desc);
int (*disable) (struct usb_ep *ep);
+   void (*dispose) (struct usb_ep *ep);
 
struct usb_request *(*alloc_request) (struct usb_ep *ep,
gfp_t gfp_flags);
-- 
2.14.3

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

Re: USB-C Devices only show up if connected at boot

[Mike Lothian]

On 25 January 2018 at 21:31, Mike Lothian  wrote:
>
> Hi
>
> I've tried with and without those being set, neither help,  having
> CONFIG_HOTPLUG_PCI_ACPI=y on causes my NVMe drive to disappear after
> suspend
>
> I'll switch back into windows and check I've the latest firmware for
> Thunderbolt, is there a way to do that on linux too?
>
> Thanks
>
> Mike

So I noticed on one of the other bugs regarding NVMe devices going
missing after suspend that issuing a echo 1 > /sys/bus/pci/rescan got
them to reappear

I've just tried this and the USB-C device was detected :D This is the
first time it's ever been detected after boot

02:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
   Kernel driver in use: pcieport
03:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
   Kernel driver in use: pcieport
03:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
   Kernel driver in use: pcieport
03:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
[Alpine Ridge 2C 2015]
   Kernel driver in use: pcieport
39:00.0 USB controller: Intel Corporation DSL6340 USB 3.1 Controller
[Alpine Ridge]
   Subsystem: Device :
   Kernel driver in use: xhci_hcd

Here's the output of lsusb -v

lsusb -v

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   3.10
 bDeviceClass9 Hub
 bDeviceSubClass 0
 bDeviceProtocol 3
 bMaxPacketSize0 9
 idVendor   0x1d6b Linux Foundation
 idProduct  0x0003 3.0 root hub
 bcdDevice4.15
 iManufacturer   3 Linux 4.15.0-rc8-agd5f+ xhci-hcd
 iProduct2 xHCI Host Controller
 iSerial 1 :39:00.0
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   31
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  0
   bmAttributes 0xe0
 Self Powered
 Remote Wakeup
   MaxPower0mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   1
 bInterfaceClass 9 Hub
 bInterfaceSubClass  0
 bInterfaceProtocol  0 Full speed (or root) hub
 iInterface  0
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x81  EP 1 IN
   bmAttributes3
 Transfer TypeInterrupt
 Synch Type   None
 Usage Type   Data
   wMaxPacketSize 0x0004  1x 4 bytes
   bInterval  12
   bMaxBurst   0
Hub Descriptor:
 bLength  12
 bDescriptorType  42
 nNbrPorts 2
 wHubCharacteristic 0x000a
   No power switching (usb 1.0)
   Per-port overcurrent protection
 bPwrOn2PwrGood   10 * 2 milli seconds
 bHubContrCurrent  0 milli Ampere
 bHubDecLat  0.0 micro seconds
 wHubDelay 0 nano seconds
 DeviceRemovable0x00
Hub Port Status:
  Port 1: .02a0 lowspeed L1
  Port 2: .02a0 lowspeed L1
Binary Object Store Descriptor:
 bLength 5
 bDescriptorType15
 wTotalLength   43
 bNumDeviceCaps  2
 SuperSpeed USB Device Capability:
   bLength10
   bDescriptorType16
   bDevCapabilityType  3
   bmAttributes 0x02
 Latency Tolerance Messages (LTM) Supported
   wSpeedsSupported   0x0008
 Device can operate at SuperSpeed (5Gbps)
   bFunctionalitySupport   3
 Lowest fully-functional device speed is SuperSpeed (5Gbps)
   bU1DevExitLat  10 micro seconds
   bU2DevExitLat 512 micro seconds
 SuperSpeedPlus USB Device Capability:
   bLength28
   bDescriptorType16
   bDevCapabilityType 10
   bmAttributes 0x0023
 Sublink Speed Attribute count 3
 Sublink Speed ID count 1
   wFunctionalitySupport   0x0001
   bmSublinkSpeedAttr[0]   0x00050034
 Speed Attribute ID: 4 5Gb/s Symmetric RX SuperSpeed
   bmSublinkSpeedAttr[1]   0x000500b4
 Speed Attribute ID: 4 5Gb/s Symmetric TX SuperSpeed
   bmSublinkSpeedAttr[2]   0x000a4035
 Speed Attribute ID: 5 10Gb/s Symmetric RX SuperSpeedPlus
   bmSublinkSpeedAttr[3]   0x000a40b5
 Speed Attribute ID: 5 10Gb/s Symmetric TX SuperSpeedPlus
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
 Self Powered

Bus 003 Device 003: ID 18d1:4ee2 Google Inc. Nexus Device (debug)
Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass0
 bDeviceSubClass 0
 bDeviceProtocol 0
 

Re: USB-C Devices only show up if connected at boot

[Mike Lothian]

On Thu, 25 Jan 2018 at 10:52 Mika Westerberg
 wrote:
>
> On Thu, Jan 25, 2018 at 12:35:49PM +0200, Heikki Krogerus wrote:
> > +Mika
> >
> > On Tue, Jan 23, 2018 at 05:43:27PM +, Mike Lothian wrote:
> > > On Tue, 23 Jan 2018 at 17:30 Greg KH  wrote:
> > > >
> > > > On Tue, Jan 23, 2018 at 05:12:03PM +, Mike Lothian wrote:
> > > > > Hi
> > > > >
> > > > > I raised https://bugzilla.kernel.org/show_bug.cgi?id=198557 but was
> > > > > informed by Greg bugs should be raised on the mailing list not in
> > > > > bugzilla
> > > > >
> > > > > So USB-C devices only show up in dmesg or for use if they are
> > > > > connected during boot
> > > > >
> > > > > Once booted and the device is disconnected the following message
> > > > > appears in the dmesg:
> > > > >
> > > > > [  100.814687] usb 3-1: USB disconnect, device number 3
> > > > > [  100.882840] xhci_hcd :39:00.0: xHCI host controller not
> > > > > responding, assume dead
> > > > > [  100.882843] xhci_hcd :39:00.0: HC died; cleaning up
> > > > >
> > > > > No further connections or disconnections display anything further in
> > > > > the dmesg, the device works fine if connected via USB-A
> > > > >
> > > > > I've witnessed this behaviour since getting the laptop at the end of
> > > > > 2015 so this isn't a regression
> > > >
> > > > Is there a BIOS update for the laptop?  This has been seen a lot in the
> > > > past on lots of different laptops but was always resolved by the BIOS
> > > > update (the latest one for mine also updates the xhci controller as
> > > > well.)
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > >
> > > Hi
> > >
> > > I've applied all BIOS updates for my laptop including the pulled one
> > > for Spectre/Meltdown & ME bugs the other week
> > > http://www.dell.com/support/home/uk/en/ukdhs1/product-support/servicetag/8k5w662/drivers
> > >
> > > If it helps, I don't have this issue in Windows but I rarely have it 
> > > booted
> > >
> > > I thought it might have something to do with an ACPI failure (see bug
> > > https://bugzilla.kernel.org/show_bug.cgi?id=198051)
> >
> > Did you update the Thunderbolt firmware?
> >
> > Mika, perhaps you can provide steps how to do that?
>
> If it works in Windows then I suspect this is not related to the
> firmware.
>
> Mike, do you have PCI hotplug enabled in your .config? Following needs
> to be set:
>
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_ACPI=y
>
> If not, please enabled them and try again.


Hi

I've tried with and without those being set, neither help,  having
CONFIG_HOTPLUG_PCI_ACPI=y on causes my NVMe drive to disappear after
suspend

I'll switch back into windows and check I've the latest firmware for
Thunderbolt, is there a way to do that on linux too?

Thanks

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

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

[kbuild test robot]

Hi Kunihiko,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.15-rc9 next-20180119]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kunihiko-Hayashi/usb-dwc3-add-UniPhier-dwc3-glue-layer-support/20180126-035928
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/usb//dwc3/dwc3-uniphier.c: In function 'dwc3u_probe':
>> drivers/usb//dwc3/dwc3-uniphier.c:428:12: error: implicit declaration of 
>> function 'of_clk_get_parent_count'; did you mean 'clk_get_parent'? 
>> [-Werror=implicit-function-declaration]
 nr_clks = of_clk_get_parent_count(node);
   ^~~
   clk_get_parent
   cc1: some warnings being treated as errors

vim +428 drivers/usb//dwc3/dwc3-uniphier.c

   401  
   402  static int dwc3u_probe(struct platform_device *pdev)
   403  {
   404  struct device *dev = >dev;
   405  struct device_node *node;
   406  struct dwc3u_priv *priv;
   407  struct resource *res;
   408  struct clk *clk;
   409  int i, nr_clks;
   410  int ret = 0;
   411  
   412  priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
   413  if (!priv)
   414  return -ENOMEM;
   415  
   416  priv->data = of_device_get_match_data(dev);
   417  if (WARN_ON(!priv->data))
   418  return -EINVAL;
   419  
   420  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   421  priv->base = devm_ioremap_resource(dev, res);
   422  if (IS_ERR(priv->base))
   423  return PTR_ERR(priv->base);
   424  
   425  priv->dev = dev;
   426  
   427  node = dev->of_node;
 > 428  nr_clks = of_clk_get_parent_count(node);
   429  if (!nr_clks) {
   430  dev_err(dev, "failed to get clock property\n");
   431  return -ENODEV;
   432  }
   433  
   434  priv->clks = devm_kcalloc(priv->dev, nr_clks, sizeof(struct clk 
*),
   435GFP_KERNEL);
   436  if (!priv->clks)
   437  return -ENOMEM;
   438  
   439  for (i = 0; i < nr_clks; i++) {
   440  clk = of_clk_get(node, i);
   441  if (IS_ERR(clk)) {
   442  ret = PTR_ERR(clk);
   443  goto out_clk_disable;
   444  }
   445  ret = clk_prepare_enable(clk);
   446  if (ret < 0) {
   447  clk_put(clk);
   448  goto out_clk_disable;
   449  }
   450  priv->clks[i] = clk;
   451  priv->nclks = i;
   452  }
   453  
   454  priv->rst = 
devm_reset_control_array_get_optional_shared(priv->dev);
   455  if (IS_ERR(priv->rst)) {
   456  ret = PTR_ERR(priv->rst);
   457  goto out_clk_disable;
   458  }
   459  ret = reset_control_deassert(priv->rst);
   460  if (ret)
   461  goto out_clk_disable;
   462  
   463  ret = dwc3u_init(priv);
   464  if (ret)
   465  goto out_rst_assert;
   466  
   467  platform_set_drvdata(pdev, priv);
   468  
   469  ret = of_platform_populate(node, NULL, NULL, priv->dev);
   470  if (ret)
   471  goto out_exit;
   472  
   473  return 0;
   474  
   475  out_exit:
   476  dwc3u_exit(priv);
   477  out_rst_assert:
   478  reset_control_assert(priv->rst);
   479  out_clk_disable:
   480  dwc3u_disable_clk(priv);
   481  
   482  return ret;
   483  }
   484  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [RFC/RFT usb-next v1 1/6] usb: mtu3: remove custom USB PHY handling

[Martin Blumenstingl]

Hi,

On Thu, Jan 25, 2018 at 3:47 AM, Chunfeng Yun  wrote:
> Hi,
>
> On Thu, 2018-01-25 at 01:16 +0100, Martin Blumenstingl wrote:
>> The new PHY wrapper is now wired up in the core HCD code. This means
>> that PHYs are now controlled (initialized, enabled, disabled, exited)
>> without requiring any host-driver specific code.
>> Remove the custom USB PHY handling from the mtu3 driver as the core HCD
>> code now handles this.
>>
>> Signed-off-by: Martin Blumenstingl 
>> ---
>>  drivers/usb/mtu3/mtu3_plat.c | 101 
>> ---
>>  1 file changed, 101 deletions(-)
>>
>> diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
>> index 628d5ce356ca..a894ddf25bcd 100644
>> --- a/drivers/usb/mtu3/mtu3_plat.c
>> +++ b/drivers/usb/mtu3/mtu3_plat.c
>> @@ -44,62 +44,6 @@ int ssusb_check_clocks(struct ssusb_mtk *ssusb, u32 
>> ex_clks)
>>   return 0;
>>  }
>>
>> -static int ssusb_phy_init(struct ssusb_mtk *ssusb)
>> -{
>> - int i;
>> - int ret;
>> -
>> - for (i = 0; i < ssusb->num_phys; i++) {
>> - ret = phy_init(ssusb->phys[i]);
>> - if (ret)
>> - goto exit_phy;
>> - }
>> - return 0;
>> -
>> -exit_phy:
>> - for (; i > 0; i--)
>> - phy_exit(ssusb->phys[i - 1]);
>> -
>> - return ret;
>> -}
>> -
>> -static int ssusb_phy_exit(struct ssusb_mtk *ssusb)
>> -{
>> - int i;
>> -
>> - for (i = 0; i < ssusb->num_phys; i++)
>> - phy_exit(ssusb->phys[i]);
>> -
>> - return 0;
>> -}
>> -
>> -static int ssusb_phy_power_on(struct ssusb_mtk *ssusb)
>> -{
>> - int i;
>> - int ret;
>> -
>> - for (i = 0; i < ssusb->num_phys; i++) {
>> - ret = phy_power_on(ssusb->phys[i]);
>> - if (ret)
>> - goto power_off_phy;
>> - }
>> - return 0;
>> -
>> -power_off_phy:
>> - for (; i > 0; i--)
>> - phy_power_off(ssusb->phys[i - 1]);
>> -
>> - return ret;
>> -}
>> -
>> -static void ssusb_phy_power_off(struct ssusb_mtk *ssusb)
>> -{
>> - unsigned int i;
>> -
>> - for (i = 0; i < ssusb->num_phys; i++)
>> - phy_power_off(ssusb->phys[i]);
>> -}
>> -
>>  static int ssusb_clks_enable(struct ssusb_mtk *ssusb)
>>  {
>>   int ret;
>> @@ -162,24 +106,8 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
>>   if (ret)
>>   goto clks_err;
>>
>> - ret = ssusb_phy_init(ssusb);
>> - if (ret) {
>> - dev_err(ssusb->dev, "failed to init phy\n");
>> - goto phy_init_err;
>> - }
>> -
>> - ret = ssusb_phy_power_on(ssusb);
>> - if (ret) {
>> - dev_err(ssusb->dev, "failed to power on phy\n");
>> - goto phy_err;
>> - }
>> -
>>   return 0;
>>
>> -phy_err:
>> - ssusb_phy_exit(ssusb);
>> -phy_init_err:
>> - ssusb_clks_disable(ssusb);
>>  clks_err:
>>   regulator_disable(ssusb->vusb33);
>>  vusb33_err:
>> @@ -190,8 +118,6 @@ static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
>>  {
>>   ssusb_clks_disable(ssusb);
>>   regulator_disable(ssusb->vusb33);
>> - ssusb_phy_power_off(ssusb);
>> - ssusb_phy_exit(ssusb);
>>  }
>>
>>  static void ssusb_ip_sw_reset(struct ssusb_mtk *ssusb)
>> @@ -222,7 +148,6 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
>> struct ssusb_mtk *ssusb)
>>   struct device *dev = >dev;
>>   struct regulator *vbus;
>>   struct resource *res;
>> - int i;
>>   int ret;
>>
>>   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
>> @@ -249,25 +174,6 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
>> struct ssusb_mtk *ssusb)
>>   if (IS_ERR(ssusb->dma_clk))
>>   return PTR_ERR(ssusb->dma_clk);
>>
>> - ssusb->num_phys = of_count_phandle_with_args(node,
>> - "phys", "#phy-cells");
>> - if (ssusb->num_phys > 0) {
>> - ssusb->phys = devm_kcalloc(dev, ssusb->num_phys,
>> - sizeof(*ssusb->phys), GFP_KERNEL);
>> - if (!ssusb->phys)
>> - return -ENOMEM;
>> - } else {
>> - ssusb->num_phys = 0;
>> - }
>> -
>> - for (i = 0; i < ssusb->num_phys; i++) {
>> - ssusb->phys[i] = devm_of_phy_get_by_index(dev, node, i);
>> - if (IS_ERR(ssusb->phys[i])) {
>> - dev_err(dev, "failed to get phy-%d\n", i);
>> - return PTR_ERR(ssusb->phys[i]);
>> - }
>> - }
>> -
>>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ippc");
>>   ssusb->ippc_base = devm_ioremap_resource(dev, res);
>>   if (IS_ERR(ssusb->ippc_base))
>> @@ -457,7 +363,6 @@ static int __maybe_unused mtu3_suspend(struct device 
>> *dev)
>>   return 0;
>>
>>   ssusb_host_disable(ssusb, true);
>> - ssusb_phy_power_off(ssusb);
>>   ssusb_clks_disable(ssusb);
>>   

[PATCH 4.4 0/4] Backport missing sccurity and deadlock fix

[Shuah Khan]

As I started backporting security fixes, I found a deadlock bug that was
fixed in a later release. This patch series contains backports for all
these problems.

Andrew Goodbody (1):
  usb: usbip: Fix possible deadlocks reported by lockdep

Shuah Khan (3):
  usbip: fix stub_rx: get_pipe() to validate endpoint number
  usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input
  usbip: prevent leaking socket pointer address in messages

 drivers/usb/usbip/stub_dev.c |  3 +-
 drivers/usb/usbip/stub_rx.c  | 46 
 drivers/usb/usbip/usbip_common.c | 15 ++-
 drivers/usb/usbip/usbip_event.c  |  5 ++-
 drivers/usb/usbip/vhci_hcd.c | 90 +++-
 drivers/usb/usbip/vhci_rx.c  | 30 --
 drivers/usb/usbip/vhci_sysfs.c   | 19 +
 drivers/usb/usbip/vhci_tx.c  | 14 ---
 8 files changed, 134 insertions(+), 88 deletions(-)

-- 
2.14.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 4.4 1/4] usb: usbip: Fix possible deadlocks reported by lockdep

[Shuah Khan]

From: Andrew Goodbody 

Upstream commit 21619792d1ec ("usb: usbip: Fix possible deadlocks
reported by lockdep")

Change spin_lock calls to spin_lock_irqsave to prevent
attmpted recursive lock taking in interrupt context.

This patch fixes Bug 109351
  https://bugzilla.kernel.org/show_bug.cgi?id=109351

Signed-off-by: Andrew Goodbody 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/usbip_event.c |  5 ++-
 drivers/usb/usbip/vhci_hcd.c| 88 -
 drivers/usb/usbip/vhci_rx.c | 30 --
 drivers/usb/usbip/vhci_sysfs.c  | 19 +
 drivers/usb/usbip/vhci_tx.c | 14 ---
 5 files changed, 91 insertions(+), 65 deletions(-)

diff --git a/drivers/usb/usbip/usbip_event.c b/drivers/usb/usbip/usbip_event.c
index 64933b993d7a..2580a32bcdff 100644
--- a/drivers/usb/usbip/usbip_event.c
+++ b/drivers/usb/usbip/usbip_event.c
@@ -117,11 +117,12 @@ EXPORT_SYMBOL_GPL(usbip_event_add);
 int usbip_event_happened(struct usbip_device *ud)
 {
int happened = 0;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (ud->event != 0)
happened = 1;
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
return happened;
 }
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index f9af04d7f02f..0aaa8e524afd 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -121,9 +121,11 @@ static void dump_port_status_diff(u32 prev_status, u32 
new_status)
 
 void rh_port_connect(int rhport, enum usb_device_speed speed)
 {
+   unsigned long   flags;
+
usbip_dbg_vhci_rh("rh_port_connect %d\n", rhport);
 
-   spin_lock(_controller->lock);
+   spin_lock_irqsave(_controller->lock, flags);
 
the_controller->port_status[rhport] |= USB_PORT_STAT_CONNECTION
| (1 << USB_PORT_FEAT_C_CONNECTION);
@@ -139,22 +141,24 @@ void rh_port_connect(int rhport, enum usb_device_speed 
speed)
break;
}
 
-   spin_unlock(_controller->lock);
+   spin_unlock_irqrestore(_controller->lock, flags);
 
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
 }
 
 static void rh_port_disconnect(int rhport)
 {
+   unsigned long   flags;
+
usbip_dbg_vhci_rh("rh_port_disconnect %d\n", rhport);
 
-   spin_lock(_controller->lock);
+   spin_lock_irqsave(_controller->lock, flags);
 
the_controller->port_status[rhport] &= ~USB_PORT_STAT_CONNECTION;
the_controller->port_status[rhport] |=
(1 << USB_PORT_FEAT_C_CONNECTION);
 
-   spin_unlock(_controller->lock);
+   spin_unlock_irqrestore(_controller->lock, flags);
usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
 }
 
@@ -182,13 +186,14 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
int retval;
int rhport;
int changed = 0;
+   unsigned long   flags;
 
retval = DIV_ROUND_UP(VHCI_NPORTS + 1, 8);
memset(buf, 0, retval);
 
vhci = hcd_to_vhci(hcd);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
if (!HCD_HW_ACCESSIBLE(hcd)) {
usbip_dbg_vhci_rh("hw accessible flag not on?\n");
goto done;
@@ -209,7 +214,7 @@ static int vhci_hub_status(struct usb_hcd *hcd, char *buf)
usb_hcd_resume_root_hub(hcd);
 
 done:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
return changed ? retval : 0;
 }
 
@@ -236,6 +241,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
struct vhci_hcd *dum;
int retval = 0;
int rhport;
+   unsigned long   flags;
 
u32 prev_port_status[VHCI_NPORTS];
 
@@ -254,7 +260,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 
dum = hcd_to_vhci(hcd);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
 
/* store old status and compare now and old later */
if (usbip_dbg_flag_vhci_rh) {
@@ -408,7 +414,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
}
usbip_dbg_vhci_rh(" bye\n");
 
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
return retval;
 }
@@ -431,6 +437,7 @@ static void vhci_tx_urb(struct urb *urb)
 {
struct vhci_device *vdev = get_vdev(urb->dev);
struct vhci_priv *priv;
+   unsigned long flags;
 
if (!vdev) {
pr_err("could not get virtual device");
@@ -443,7 +450,7 @@ static void vhci_tx_urb(struct urb *urb)
return;
}
 
-   spin_lock(>priv_lock);
+   spin_lock_irqsave(>priv_lock, 

[PATCH 4.4 2/4] usbip: fix stub_rx: get_pipe() to validate endpoint number

[Shuah Khan]

Upstream commit 635f545a7e8b ("usbip: fix stub_rx: get_pipe() to validate
endpoint number")

get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().

Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.

Reported-by: Secunia Research 
Cc: stable 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_rx.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 7de54a66044f..e617c90661b4 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -344,15 +344,15 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
 
+   if (epnum < 0 || epnum > 15)
+   goto err_ret;
+
if (dir == USBIP_DIR_IN)
ep = udev->ep_in[epnum & 0x7f];
else
ep = udev->ep_out[epnum & 0x7f];
-   if (!ep) {
-   dev_err(>interface->dev, "no such endpoint?, %d\n",
-   epnum);
-   BUG();
-   }
+   if (!ep)
+   goto err_ret;
 
epd = >desc;
if (usb_endpoint_xfer_control(epd)) {
@@ -383,9 +383,10 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
return usb_rcvisocpipe(udev, epnum);
}
 
+err_ret:
/* NOT REACHED */
-   dev_err(>interface->dev, "get pipe, epnum %d\n", epnum);
-   return 0;
+   dev_err(>udev->dev, "get pipe() invalid epnum %d\n", epnum);
+   return -1;
 }
 
 static void masking_bogus_flags(struct urb *urb)
@@ -451,6 +452,9 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct usb_device *udev = sdev->udev;
int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
 
+   if (pipe == -1)
+   return;
+
priv = stub_priv_alloc(sdev, pdu);
if (!priv)
return;
-- 
2.14.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 4.4 4/4] usbip: prevent leaking socket pointer address in messages

[Shuah Khan]

Upstream commit 90120d15f4c3 ("usbip: prevent leaking socket pointer
address in messages")

usbip driver is leaking socket pointer address in messages. Remove
the messages that aren't useful and print sockfd in the ones that
are useful for debugging.

Signed-off-by: Shuah Khan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_dev.c |  3 +--
 drivers/usb/usbip/usbip_common.c | 15 ---
 drivers/usb/usbip/vhci_hcd.c |  2 +-
 3 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index a3ec49bdc1e6..ec38370ffcab 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -163,8 +163,7 @@ static void stub_shutdown_connection(struct usbip_device 
*ud)
 * step 1?
 */
if (ud->tcp_socket) {
-   dev_dbg(>udev->dev, "shutdown tcp_socket %p\n",
-   ud->tcp_socket);
+   dev_dbg(>udev->dev, "shutdown sockfd %d\n", ud->sockfd);
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
 
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index 9752b93f754e..1838f1b2c2fa 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -317,18 +317,14 @@ int usbip_recv(struct socket *sock, void *buf, int size)
struct msghdr msg;
struct kvec iov;
int total = 0;
-
/* for blocks of if (usbip_dbg_flag_xmit) */
char *bp = buf;
int osize = size;
 
-   usbip_dbg_xmit("enter\n");
-
-   if (!sock || !buf || !size) {
-   pr_err("invalid arg, sock %p buff %p size %d\n", sock, buf,
-  size);
+   if (!sock || !buf || !size)
return -EINVAL;
-   }
+
+   usbip_dbg_xmit("enter\n");
 
do {
sock->sk->sk_allocation = GFP_NOIO;
@@ -341,11 +337,8 @@ int usbip_recv(struct socket *sock, void *buf, int size)
msg.msg_flags  = MSG_NOSIGNAL;
 
result = kernel_recvmsg(sock, , , 1, size, MSG_WAITALL);
-   if (result <= 0) {
-   pr_debug("receive sock %p buf %p size %u ret %d total 
%d\n",
-sock, buf, size, result, total);
+   if (result <= 0)
goto err;
-   }
 
size -= result;
buf += result;
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 0aaa8e524afd..00d68945548e 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -778,7 +778,7 @@ static void vhci_shutdown_connection(struct usbip_device 
*ud)
 
/* need this? see stub_dev.c */
if (ud->tcp_socket) {
-   pr_debug("shutdown tcp_socket %p\n", ud->tcp_socket);
+   pr_debug("shutdown sockfd %d\n", ud->sockfd);
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
 
-- 
2.14.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 4.4 3/4] usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input

[Shuah Khan]

Upstream commit c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path
to handle malicious input")

Harden CMD_SUBMIT path to handle malicious input that could trigger
large memory allocations. Add checks to validate transfer_buffer_length
and number_of_packets to protect against bad input requesting for
unbounded memory allocations. Validate early in get_pipe() and return
failure.

Reported-by: Secunia Research 
Cc: stable 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/usbip/stub_rx.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index e617c90661b4..56cacb68040c 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -338,11 +338,13 @@ static struct stub_priv *stub_priv_alloc(struct 
stub_device *sdev,
return priv;
 }
 
-static int get_pipe(struct stub_device *sdev, int epnum, int dir)
+static int get_pipe(struct stub_device *sdev, struct usbip_header *pdu)
 {
struct usb_device *udev = sdev->udev;
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
+   int epnum = pdu->base.ep;
+   int dir = pdu->base.direction;
 
if (epnum < 0 || epnum > 15)
goto err_ret;
@@ -355,6 +357,7 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
goto err_ret;
 
epd = >desc;
+
if (usb_endpoint_xfer_control(epd)) {
if (dir == USBIP_DIR_OUT)
return usb_sndctrlpipe(udev, epnum);
@@ -377,6 +380,27 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
}
 
if (usb_endpoint_xfer_isoc(epd)) {
+   /* validate packet size and number of packets */
+   unsigned int maxp, packets, bytes;
+
+#define USB_EP_MAXP_MULT_SHIFT  11
+#define USB_EP_MAXP_MULT_MASK   (3 << USB_EP_MAXP_MULT_SHIFT)
+#define USB_EP_MAXP_MULT(m) \
+   (((m) & USB_EP_MAXP_MULT_MASK) >> USB_EP_MAXP_MULT_SHIFT)
+
+   maxp = usb_endpoint_maxp(epd);
+   maxp *= (USB_EP_MAXP_MULT(
+   __le16_to_cpu(epd->wMaxPacketSize)) + 1);
+   bytes = pdu->u.cmd_submit.transfer_buffer_length;
+   packets = DIV_ROUND_UP(bytes, maxp);
+
+   if (pdu->u.cmd_submit.number_of_packets < 0 ||
+   pdu->u.cmd_submit.number_of_packets > packets) {
+   dev_err(>udev->dev,
+   "CMD_SUBMIT: isoc invalid num packets %d\n",
+   pdu->u.cmd_submit.number_of_packets);
+   return -1;
+   }
if (dir == USBIP_DIR_OUT)
return usb_sndisocpipe(udev, epnum);
else
@@ -385,7 +409,7 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
 
 err_ret:
/* NOT REACHED */
-   dev_err(>udev->dev, "get pipe() invalid epnum %d\n", epnum);
+   dev_err(>udev->dev, "CMD_SUBMIT: invalid epnum %d\n", epnum);
return -1;
 }
 
@@ -450,7 +474,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct stub_priv *priv;
struct usbip_device *ud = >ud;
struct usb_device *udev = sdev->udev;
-   int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
+   int pipe = get_pipe(sdev, pdu);
 
if (pipe == -1)
return;
-- 
2.14.1

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

Re: [PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Thu, Jan 25, 2018 at 10:34 AM, David R. Bild  wrote:
> On Thu, Jan 11, 2018 at 4:27 AM, Oliver Neukum  wrote:
>>
>> Am Mittwoch, den 10.01.2018, 10:58 -0600 schrieb  David R. Bild :
>
>> > +static void xapea00x_tpm_probe(struct work_struct *work)
>> > +{
>> > + struct xapea00x_async_probe *probe = work_to_probe(work);
>> > + struct xapea00x_device *dev = probe->dev;
>> > + struct spi_master *spi_master = dev->spi_master;
>> > + struct spi_device *tpm;
>> > + int retval;
>> > +
>> > + tpm = spi_new_device(spi_master, _board_info);
>> > + mutex_lock(>usb_mutex);
>> > + if (!dev->interface) {
>> > + retval = -ENODEV;
>> > + goto out;
>> > + }
>> > + if (!tpm) {
>>
>> Why test this under a mutex?
>>
>
> dev->interface being NULL/non-NULL is used as a flag to determine if
> the USB device has been unregistered.  So, the mutex needs to be held
> when dereferencing dev->interface subsequently.
>
> Performing the test before acquiring the lock would be a race condition.
>

I'm realizing I misunderstood this comment --- you're referring to
testing "!tpm", not testing "!dev->interface".

It's because the in the failure case (!tpm), I want the error message
to include the "dev->interface->dev" identifier.  But that
dereferencing is only safe if "dev->interface" isn't NULL.

>> > + retval = -ENODEV;
>> > + dev_err(>interface->dev,
>> > + "unable to add spi device for TPM\n");
>> > + goto err;
>> > + }
>> > +


Thanks much,
David
--
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

uvcvideo: Failed to resubmit video URB (-1).

[Cristian]

Hello,

Open bug in bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=198575

dmesg:
[ 6529.509530] uvcvideo: Failed to resubmit video URB (-1).

Regards,
-- 
Cristian
[0.00] microcode: microcode updated early to revision 0x29, date = 
2013-06-12
[0.00] Linux version 4.15.0-041500rc9-generic (kernel@tangerine) (gcc 
version 7.2.0 (Ubuntu 7.2.0-8ubuntu3)) #201801212130 SMP Mon Jan 22 02:31:37 
UTC 2018
[0.00] Command line: 
BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-041500rc9-generic 
root=UUID=707d0f89-4b1d-4432-9d50-6058dc4c1ee9 ro rootflags=subvol=@ quiet 
splash vt.handoff=7
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xc42a9fff] usable
[0.00] BIOS-e820: [mem 0xc42aa000-0xc44abfff] reserved
[0.00] BIOS-e820: [mem 0xc44ac000-0xd33eefff] usable
[0.00] BIOS-e820: [mem 0xd33ef000-0xdaeeefff] reserved
[0.00] BIOS-e820: [mem 0xdaeef000-0xdaf9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data
[0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable
[0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffd0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00031f5f] usable
[0.00] BIOS-e820: [mem 0x00031f60-0x00031f7f] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.7 present.
[0.00] DMI: SAMSUNG ELECTRONICS CO., LTD. 
530U3C/530U4C/SAMSUNG_NP1234567890, BIOS P14AAJ 04/15/2013
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x31f600 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0 mask F8000 write-back
[0.00]   2 base 08000 mask FC000 write-back
[0.00]   3 base 0C000 mask FE000 write-back
[0.00]   4 base 0DC00 mask FFC00 uncachable
[0.00]   5 base 0DB00 mask FFF00 uncachable
[0.00]   6 base 1 mask F write-back
[0.00]   7 base 2 mask F write-back
[0.00]   8 base 3 mask FE000 write-back
[0.00]   9 base 31F80 mask FFF80 uncachable
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: last_pfn = 0xdb000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f0100-0x000f010f] mapped at [
(ptrval)]
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.00] reserving inaccessible SNB gfx pages
[0.00] BRK [0x2253a000, 0x2253afff] PGTABLE
[0.00] BRK [0x2253b000, 0x2253bfff] PGTABLE
[0.00] BRK [0x2253c000, 0x2253cfff] PGTABLE
[

Re: [PATCH 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

On Thu, Jan 11, 2018 at 4:27 AM, Oliver Neukum  wrote:
>
> Am Mittwoch, den 10.01.2018, 10:58 -0600 schrieb  David R. Bild :
> > This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
> > hardware module for authenticating IoT devices and gateways.
> >

Thanks for the review. Fixed a couple of definite bugs.

Responses (or requests for clarification) for some of your comments
follow.  The others are fixed in a v2, which I'll sent once you answer
my clarifying questions.

> > +static int xapea00x_br_bulk_write(struct xapea00x_device *dev,
> > +   struct xapea00x_br_bulk_command *header,
> > +   const void *data, int len)
> > +{
> > + u8 *buf;
> > + unsigned int pipe;
> > + int buf_len, actual_len, retval;
> > +
> > + buf_len = sizeof(struct xapea00x_br_bulk_command) + len;
> > + buf = kzalloc(buf_len, GFP_KERNEL);
>
> Why zeroed? You copy all over it.

It's easiest to audit the code for incorrect usages of kalloc if we
just always use kzalloc.

This device isn't used very frequently --- once shortly after boot if
used correctly and once each time the internet connection is
re-established if used poorly.  Each use sends just a couple KB
between device and host.  So I'd rather optimize for ease of
functional correctness and safety than saving the few cycles needed to
zero something that is immediately overwritten.

Same logic for using kzfree everywhere, even on structures or buffers
that don't contain user or other potentially sensitive data.

> > + memcpy(buf, header, sizeof(struct xapea00x_br_bulk_command));
> > + memcpy(buf + sizeof(struct xapea00x_br_bulk_command), data, len);
> > +
> > + pipe = usb_sndbulkpipe(dev->udev, dev->bulk_out->bEndpointAddress);
> > + retval = usb_bulk_msg(dev->udev, pipe, buf, buf_len, _len,
> > +   XAPEA00X_BR_USB_TIMEOUT);
> > + if (retval) {
> > + dev_warn(>interface->dev,
> > +  "%s: usb_bulk_msg() failed with %d\n",
> > +  __func__, retval);
> > + goto free_buf;
>
> Does this make any sense?

It does to me.  What specifically do you think is odd?

> > + }
> > +
> > + retval = 0;
> > +
> > +free_buf:
> > + kzfree(buf);
> > +
> > +out:
> > + return retval;
> > +}

> > +static int xapea00x_br_ctrl_write(struct xapea00x_device *dev, u8 bRequest,
> > +   u16 wValue, u16 wIndex, u8 *data, u16 len)
>
> Combine with xapea00x_br_bulk_write()?

No.  xapea00x_br_bulk_write and xapea00x_br_ctrl_write conceptually do
very different things and take very different parameters.

> > +static int xapea00x_spi_setup(struct spi_device *spi)
> > +{
> > + struct xapea00x_device *dev;
> > + int retval;
> > +
> > + dev = spi_master_get_devdata(spi->master);
> > +
> > + mutex_lock(>usb_mutex);
> > + if (!dev->interface) {
> > + retval = -ENODEV;
> > + goto out;
> > + }
> > +
> > + /* Verify that this is the TPM device */
> > + if (spi->chip_select != 0) {
> > + retval = -EINVAL;
> > + goto err;
> > + }
> > +
> > + /*
> > +  * Disable auto chip select for the TPM channel.
> > +  * Must be done after setting the SPI parameters.
> > +  */
> > + retval = xapea00x_br_disable_cs(dev, 0);
> > + if (retval)
> > + goto err;
> > +
> > + /* De-assert chip select for the TPM channel. */
> > + retval = xapea00x_br_deassert_cs(dev, 0);
> > + if (retval)
> > + goto err;
> > +
> > + dev_dbg(>interface->dev, "configured spi channel for tpm\n");
> > + retval = 0;
> > + goto out;
>
> The control flow is innovative.

Thanks ;)

I've removed the "retval = 0;" as that is unnecessary.  Otherwise, do
you have a better control flow that doesn't involve repeating either
the following "dev_err" or "mutex_unlock".  I've found this style to
be the safest in the face of future changes.

> > +
> > +err:
> > + dev_err(>interface->dev,
> > + "configuring SPI channel failed with %d\n", retval);
> > +
> > +out:
> > + mutex_unlock(>usb_mutex);
> > + return retval;
> > +}
> > +

> > + /* Deassert chip select, if requested */
> > + if (!cs_hold)
> > + retval = xapea00x_br_deassert_cs(dev, 0);
> > +
> > + /* Delay for the requested time */
> > + udelay(delay_usecs);
>
> Ouch. Do we really need to unconditionally delay?
> How about saving the time and using udelay only when required?

A delay before a subsequent SPI operation is required. The exact time
is specified by the SPI chip datasheet.  The bookkeeping needed to
determine if the delay was met implicitly and thus avoid the explicit
delay would be complex and error prone.  No one does it this way ---
an unconditional udelay is standard for spi controller drivers in the
kernel as far as I know.

Luckily, for most devices 

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

[Bin Liu]

Maxim,

On Thu, Jan 25, 2018 at 07:24:02PM +0300, Maxim Uvarov wrote:
> [1] says that issue is with back ported driver to 3.12.10. Can the
> latest kernel be tested on the same hw?

Agreed that it should be tested with the latest kernel. But my concern
now is if stopping scheduling urbs on errors is a right thing to do,
that is why I asked if you can re-test your usecase with reverting the
commit. I am unable to reproduce the original issue you had.

Thanks,
-Bin.
--
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: MUSB patch (don't start next rx urb if current one failed)

[Tomas Paukrt]

Hi Bin,

thanks. I have reverted commit 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/musb/musb_host.c?id=dbac5d07d13e330e6706813c9fde477140fb5d80 
and communication with both RT2800 and SMSC9500 was much more stable, 
but we still had less frequent issues with SMSC9500, so I looked at 
usbnet and smsc95xx drivers and found out that execution of 
*usb_clear_halt* is not enough if stalling endpoint is detected (bit 
MUSB_TXCSR_H_RXSTALL is set) and the chip must be reset, but none of 
these two drivers do it. The reset is mentioned in Microship's 
documentation and also used in their driver, so maybe someone can adapt 
smsc95xx driver to reset the chip properly. I also found out that 
execution of *unlink_urbs* from *usbnet_deferred_kevent * often leads to 
various errors ("queue 0 timed out", "Could not flush host TX2 fifo") or 
even system freeze, so it seems that MUSB driver still has some issue 
with fifo flushing.


Best regards

Tomas


Dne 25.1.2018 v 15:59 Bin Liu napsal(a):

+ cc:linux-usb

Hi Tomas,

It is always a good idea to cc linux-usb list when sending emails to an
individual. (otherwise, for example in my setup the emails go to the
Junk folder if a mailing list is not in to/cc.)

On Thu, Jan 18, 2018 at 03:47:12PM +0100, Tomas Paukrt wrote:

Hi Bin,

I have found out that your patch 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/musb/musb_host.c?id=dbac5d07d13e330e6706813c9fde477140fb5d80
is causing at least issues with SMSC9500 Ethernet chips and RT2800
WiFi chips. Error EPROTO sometimes happens during communication with
these chips and it leads to stopping communication.

We have kernel 3.12.10 with backported selected patches including
yours. Do we miss some patch that should restart sending URBs? In
our situation sending URBs just stop after first failure and is not
resumed unless we execute for example "ifconfig eth2 down" and
"ifconfig eth2 up".

Sorry for causing the regression. I will loop you in another email
thread to try to find a solution.

Regards,
-Bin.
.



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

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

[Maxim Uvarov]

[1] says that issue is with back ported driver to 3.12.10. Can the
latest kernel be tested on the same hw?

Maxim.

2018-01-25 18:45 GMT+03:00 Bin Liu :
> Hi Yegor and Max,
>
> On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote:
>> On Tue, May 3, 2016 at 3:48 PM, Bin Liu  wrote:
>> > Hi,
>> >
>> > On Tue, May 03, 2016 at 12:03:52PM +0200, Yegor Yefremov wrote:
>> >> On Thu, Apr 28, 2016 at 4:37 PM, Bin Liu  wrote:
>> >> > Hi,
>> >> >
>> >> > On Thu, Apr 28, 2016 at 09:51:37AM +0300, Maxim Uvarov wrote:
>> >> >
>> >> > [snip]
>> >> >
>> >> >> Hello Bin,
>> >> >>
>> >> >> yes, it also works with that reset and go to finish:
>> >> >>
>> >> >> diff --git a/drivers/usb/musb/musb_host.c 
>> >> >> b/drivers/usb/musb/musb_host.c
>> >> >> index c3d5fc9..8cd98e7 100644
>> >> >> --- a/drivers/usb/musb/musb_host.c
>> >> >> +++ b/drivers/usb/musb/musb_host.c
>> >> >> @@ -1599,6 +1599,10 @@ void musb_host_rx(struct musb *musb, u8 epnum)
>> >> >> status = -EPROTO;
>> >> >> musb_writeb(epio, MUSB_RXINTERVAL, 0);
>> >> >>
>> >> >> +   rx_csr &= ~MUSB_RXCSR_H_ERROR;
>> >> >> +   musb_writew(epio, MUSB_RXCSR, rx_csr);
>> >> >> +
>> >> >> +   goto finish;
>> >> >> } else if (rx_csr & MUSB_RXCSR_DATAERROR) {
>> >> >>
>> >> >> if (USB_ENDPOINT_XFER_ISOC != qh->type) {
>> >> >>
>> >> >
>> >> > Thanks for testing it.
>> >>
>> >> Have tested your patch and now both FT4232 and Huawei don't freeze on 
>> >> removal.
>> >>
>> >> Bin, Max thanks for fixing this issue.
>> >>
>> >> Tested-by: Yegor Yefremov 
>> >
>> > Thanks for testing.
>> >
>> > Can you please test the patch [1] instead? I'd like to use it as the
>> > fix.
>> >
>> > [1] http://marc.info/?l=linux-usb=146222355213935=2
>>
>> The patch behaves the same as the previous one.
>
> Sorry for bringing up this old thread, but it seems to be too aggressive
> to stop scheduling further urbs on errors [1]. So is it possible for you
> to re-test your usecase by reverting commit
>
> dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one 
> failed")
>
> to see if only commit
>
> b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
>
> itself solves your issue?
>
> I know you have tested the patch in [2], which is similar to commit
> b5801212229f, but tha latter doesn't have 'goto finish' which does dma
> cleanup on errors, it makes more sense to me. But I'd like to have you
> tested with reverting dbac5d07d13e to be sure.
>
> [1] https://marc.info/?l=linux-usb=151689238420622=2
> [2] https://marc.info/?l=linux-kernel=146185425805967=2
>
> thanks,
> -Bin.
>



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

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

[Roger Quadros]

Hi,

On 24/01/18 14:19, Roger Quadros wrote:
> On 23/01/18 14:41, Roger Quadros wrote:
>> Hi Manu,
>>
>> On 23/01/18 05:45, Manu Gautam wrote:
>>> Hi,
>>>
>>>
>>> On 1/22/2018 6:31 PM, Roger Quadros wrote:
 Adding/removing host/gadget controller before .pm_complete()
 causes a lock-up. Let's prevent any dual-role state change
 between .pm_prepare() and .pm_complete() to fix this.
>>>
>>> What kind of lock-up are you seeing? Some hardware lockup or software 
>>> deadlock?
>>> IMO using a freezable_wq for drd_work should address that?
>>>
>>
>> I was seeing a software deadlock. freezable_wq is a good idea. I'll try it 
>> out.
> 
> using freezable_wq doesn't get rid of the deadlock.
> If I use freezable_wq plus add some delay before I do a dwc3_host_init()
> in the work function then it starts to work.
> 
> As dependence on delay looks fragile so I'll stick to the current 
> implementation
> based on .pm_prepare/complete().
> 

So I was able to reproduce the lock up with my series as well. On further 
investigation
this is what I see.

There are 2 different scenarios.

1) controller in host mode prior to system suspend and switches to device mode 
during resume.

In this case when we call dwc3_host_exit() before tasks are thawed
xhci_plat_remove() seems to lock up at the second usb_remove_hcd() call.
This issue is resolved by using system_freezable_wq for the _dwc3_set_mode() 
function.


2) controller in device mode prior to system suspend and switches to host mode 
during resume.

In this case we sleep indefinitely in _dwc3_set_mode due to
dwc3_set_mode()->dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->dwc3_gadget_stop()->wait_event_lock_irq()

This is not resolved by moving the dwc3_set_mode() call to .pm_complete() nor 
via the system_freezable_wq.

One way I could fix this is like so.

Felipe, could you please suggest a better way?
Maybe we need to do this in dwc3_gadget_exit() before calling 
usb_del_gadget_udc() ?

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b417d9a..0c903c1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -109,6 +109,7 @@ static void __dwc3_set_mode(struct work_struct *work)
struct dwc3 *dwc = work_to_dwc(work);
unsigned long flags;
int ret;
+   int epnum;
 
if (!dwc->desired_dr_role)
return;
@@ -124,6 +125,17 @@ static void __dwc3_set_mode(struct work_struct *work)
dwc3_host_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_DEVICE:
+   spin_lock_irqsave(>lock, flags);
+   for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
+   struct dwc3_ep  *dep = dwc->eps[epnum];
+
+   if (!dep)
+   continue;
+
+   dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
dwc3_gadget_exit(dwc);
dwc3_event_buffers_cleanup(dwc);
break;
-- 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT usb-next v1 3/6] usb: host: ehci-platform: remove custom USB PHY handling

[Alan Stern]

On Thu, 25 Jan 2018, Martin Blumenstingl wrote:

> The new PHY wrapper is now wired up in the core HCD code. This means
> that PHYs are now controlled (initialized, enabled, disabled, exited)
> without requiring any host-driver specific code.
> Remove the custom USB PHY handling from the ehci-platform driver as the
> core HCD code now handles this.
> 
> Signed-off-by: Martin Blumenstingl 
> ---

For patches 3/6 and 4/6:

Acked-by: 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: [BUG] SD card reader disappears after suspend

[Alan Stern]

On Thu, 25 Jan 2018, Samuel Sadok wrote:

> 2018-01-23 17:31 GMT+01:00 Alan Stern :
> > On Tue, 23 Jan 2018, Samuel Sadok wrote:
> >
> >> Thanks Alan,
> >>
> >> While I was at it I also enabled debug logs for xhci_hcd and xhci_pci.
> >>
> >> $ echo module usbcore =p > /sys/kernel/debug/dynamic_debug/control
> >> $ echo module xhci_hcd =p > /sys/kernel/debug/dynamic_debug/control
> >> $ echo module xhci_pci =p > /sys/kernel/debug/dynamic_debug/control
> >> $ modprobe usbmon
> >> $ cat /sys/kernel/debug/usb/usbmon/0u > /tmp/usbmon.log
> >> $ # press power button
> >>
> >> dmesg: https://gist.github.com/anonymous/29b81574abf40605f999cfeefe98e341
> >> usbmon: https://gist.github.com/anonymous/55b6d9bbf8b8c8627230b10d2b09dcb6
> >>
> >> Both logs were collected at the same time so the timestamps should match.
> >
> > In fact they do, quite closely.  But there is a noticeable gap in the
> > usbmon trace, between lines 197 and 198 (the timestamp jumps from
> > 35923531 to 38925126) and there obviously was a lot of activity on bus
> > 1 in between.
> 
> Yes you're right, that's inconvenient because the "failed to disable
> LTM" message occurs exactly in this gap. Are gaps like this expected /
> known? Any ideas on how to mitigate them? (I kinda want to avoid
> soldering an external bus monitor to the mainboard :) )

The text interface to usbmon uses a fixed-size buffer, and the size is
a little on the low side if you're dealing with large latencies (which
of course are unavoidable during a suspend/resume scenario).  The size
is determined by EVENT_MAX, defined around line 40 in
drivers/usb/mon/mon_text.c:

#define EVENT_MAX  (4*PAGE_SIZE / sizeof(struct mon_event_text))

Just change the 4 to something considerably larger and you should be in 
good shape.

> >> Resume starts at dmesg line 1255.
> >> As far as I can judge, the earliest indication of something going
> >> wrong is line 1514:
> >> [ 36.087176] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
> >> unaddressed device
> >> [ 36.087180] usb 2-4: Disable of device-initiated U1 failed.
> >> [ 36.087212] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
> >> unaddressed device
> >> [ 36.087224] usb 2-4: Disable of device-initiated U2 failed.
> >> [ 36.087226] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
> >> unaddressed device
> >> [ 36.087227] usb 2-4: usb_reset_and_verify_device Failed to disable LTM
> >
> > Yes, that's where the problem first seems to show up.  Apparently
> > usb_disable_ltm() fails because it can't communicate with the device,
> > and usb_reset_and_verify_device() then aborts because of that failure.
> > It shouldn't do this; after all, one very good reason for resetting the
> > device is because we're unable to communicate with it.
> >
> > You could try editing the source code for usb_reset_and_verify_device()
> > in drivers/usb/core/hub.c, to see what happens if it doesn't give up
> > after usb_disable_ltm() fails.
> 
> For the following logs I modified the "Failed to disable LTM" message
> and commented out the goto in the line below. Also I used kernel
> version 4.15-rc9 this time. I omitted upgrading the out-of-tree
> modules broadcom-wl and nouveau-fw, so don't mind errors related to
> that.
> The SD card reader is still missing after resume.
> 
> dmesg & usbmon:
> https://gist.github.com/anonymous/fc597612d5ebbac40d7bef9f8f0b579a
> 
> `usb_reset_and_verify_device()` is executed around dmesg line 1524.
> Again, the usbmon log has a major gap around that time.

It looks like the system is trying to carry out multiple warm resets, 
or a single extremely long warm reset, when it really should give up 
and do a cold reset instead.

It would be best to get Mathias's input on this.  I don't know what is 
the right way to fix this problem.

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: Tracepoints

[Bin Liu]

Hi,

On Thu, Jan 25, 2018 at 10:13:02AM -0500, Tyler Howell wrote:
> Hey Bin,
> 
> Thanks for replying back.  I'm not sure, but it might have been because I
> compiled the musb as a module (and hadn't loaded it!).  I re-configured my
> kernel and was able to get the musb events to show up under
> `/sys/kernel/debug/tracing/available_events`.

Glad you made progress.

> 
> Thanks again for the help!  I don't suppose you have the mentor graphics
> manual for the musb IP core off hand?  I'm working with the beagle bone
> black and the AM355x TRM is helpful, but I'd like to know more about the
> usb subsystem.

I do, but due to NDA I can only expose the information which I am
allowed to, the scope would be maily as that the Linux musb driver
exposes.

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

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

[Bin Liu]

Hi Yegor and Max,

On Tue, May 03, 2016 at 04:25:58PM +0200, Yegor Yefremov wrote:
> On Tue, May 3, 2016 at 3:48 PM, Bin Liu  wrote:
> > Hi,
> >
> > On Tue, May 03, 2016 at 12:03:52PM +0200, Yegor Yefremov wrote:
> >> On Thu, Apr 28, 2016 at 4:37 PM, Bin Liu  wrote:
> >> > Hi,
> >> >
> >> > On Thu, Apr 28, 2016 at 09:51:37AM +0300, Maxim Uvarov wrote:
> >> >
> >> > [snip]
> >> >
> >> >> Hello Bin,
> >> >>
> >> >> yes, it also works with that reset and go to finish:
> >> >>
> >> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> >> >> index c3d5fc9..8cd98e7 100644
> >> >> --- a/drivers/usb/musb/musb_host.c
> >> >> +++ b/drivers/usb/musb/musb_host.c
> >> >> @@ -1599,6 +1599,10 @@ void musb_host_rx(struct musb *musb, u8 epnum)
> >> >> status = -EPROTO;
> >> >> musb_writeb(epio, MUSB_RXINTERVAL, 0);
> >> >>
> >> >> +   rx_csr &= ~MUSB_RXCSR_H_ERROR;
> >> >> +   musb_writew(epio, MUSB_RXCSR, rx_csr);
> >> >> +
> >> >> +   goto finish;
> >> >> } else if (rx_csr & MUSB_RXCSR_DATAERROR) {
> >> >>
> >> >> if (USB_ENDPOINT_XFER_ISOC != qh->type) {
> >> >>
> >> >
> >> > Thanks for testing it.
> >>
> >> Have tested your patch and now both FT4232 and Huawei don't freeze on 
> >> removal.
> >>
> >> Bin, Max thanks for fixing this issue.
> >>
> >> Tested-by: Yegor Yefremov 
> >
> > Thanks for testing.
> >
> > Can you please test the patch [1] instead? I'd like to use it as the
> > fix.
> >
> > [1] http://marc.info/?l=linux-usb=146222355213935=2
> 
> The patch behaves the same as the previous one.

Sorry for bringing up this old thread, but it seems to be too aggressive
to stop scheduling further urbs on errors [1]. So is it possible for you
to re-test your usecase by reverting commit

dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one 
failed")

to see if only commit

b5801212229f ("usb: musb: host: clear rxcsr error bit if set")

itself solves your issue?

I know you have tested the patch in [2], which is similar to commit
b5801212229f, but tha latter doesn't have 'goto finish' which does dma
cleanup on errors, it makes more sense to me. But I'd like to have you
tested with reverting dbac5d07d13e to be sure.

[1] https://marc.info/?l=linux-usb=151689238420622=2
[2] https://marc.info/?l=linux-kernel=146185425805967=2

thanks,
-Bin.

--
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: Tracepoints

[Bin Liu]

+ cc:linux-usb

Hi Tyler,

On Wed, Jan 24, 2018 at 05:29:16PM -0500, Tyler Howell wrote:
> Hey Bin,
> 
> I've looking to learn how the musb system works, but for the life of me
> can't figure out how to enable the tracepoints for my kernel.  Is there a
> specific kernel config I need to enable for it?
> 
> I'm on the 4.14.13-ti-rt-r25 kernel from RobertCNelson's github.  Thanks
> for the help.

Kernel Doc has documented about ftrace [1]. Please see if it helps.

[1] Documentation/trace/*.txt

Regards,
-Bin.
--
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: MUSB patch (don't start next rx urb if current one failed)

[Bin Liu]

+ cc:linux-usb

Hi Tomas,

It is always a good idea to cc linux-usb list when sending emails to an
individual. (otherwise, for example in my setup the emails go to the
Junk folder if a mailing list is not in to/cc.)

On Thu, Jan 18, 2018 at 03:47:12PM +0100, Tomas Paukrt wrote:
> Hi Bin,
> 
> I have found out that your patch 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/musb/musb_host.c?id=dbac5d07d13e330e6706813c9fde477140fb5d80
> is causing at least issues with SMSC9500 Ethernet chips and RT2800
> WiFi chips. Error EPROTO sometimes happens during communication with
> these chips and it leads to stopping communication.
> 
> We have kernel 3.12.10 with backported selected patches including
> yours. Do we miss some patch that should restart sending URBs? In
> our situation sending URBs just stop after first failure and is not
> resumed unless we execute for example "ifconfig eth2 down" and
> "ifconfig eth2 up".

Sorry for causing the regression. I will loop you in another email
thread to try to find a solution.

Regards,
-Bin.
--
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: [BUG] SD card reader disappears after suspend

[Samuel Sadok]

2018-01-23 17:31 GMT+01:00 Alan Stern :
> On Tue, 23 Jan 2018, Samuel Sadok wrote:
>
>> Thanks Alan,
>>
>> While I was at it I also enabled debug logs for xhci_hcd and xhci_pci.
>>
>> $ echo module usbcore =p > /sys/kernel/debug/dynamic_debug/control
>> $ echo module xhci_hcd =p > /sys/kernel/debug/dynamic_debug/control
>> $ echo module xhci_pci =p > /sys/kernel/debug/dynamic_debug/control
>> $ modprobe usbmon
>> $ cat /sys/kernel/debug/usb/usbmon/0u > /tmp/usbmon.log
>> $ # press power button
>>
>> dmesg: https://gist.github.com/anonymous/29b81574abf40605f999cfeefe98e341
>> usbmon: https://gist.github.com/anonymous/55b6d9bbf8b8c8627230b10d2b09dcb6
>>
>> Both logs were collected at the same time so the timestamps should match.
>
> In fact they do, quite closely.  But there is a noticeable gap in the
> usbmon trace, between lines 197 and 198 (the timestamp jumps from
> 35923531 to 38925126) and there obviously was a lot of activity on bus
> 1 in between.

Yes you're right, that's inconvenient because the "failed to disable
LTM" message occurs exactly in this gap. Are gaps like this expected /
known? Any ideas on how to mitigate them? (I kinda want to avoid
soldering an external bus monitor to the mainboard :) )

>
>> Resume starts at dmesg line 1255.
>> As far as I can judge, the earliest indication of something going
>> wrong is line 1514:
>> [ 36.087176] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
>> unaddressed device
>> [ 36.087180] usb 2-4: Disable of device-initiated U1 failed.
>> [ 36.087212] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
>> unaddressed device
>> [ 36.087224] usb 2-4: Disable of device-initiated U2 failed.
>> [ 36.087226] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
>> unaddressed device
>> [ 36.087227] usb 2-4: usb_reset_and_verify_device Failed to disable LTM
>
> Yes, that's where the problem first seems to show up.  Apparently
> usb_disable_ltm() fails because it can't communicate with the device,
> and usb_reset_and_verify_device() then aborts because of that failure.
> It shouldn't do this; after all, one very good reason for resetting the
> device is because we're unable to communicate with it.
>
> You could try editing the source code for usb_reset_and_verify_device()
> in drivers/usb/core/hub.c, to see what happens if it doesn't give up
> after usb_disable_ltm() fails.

For the following logs I modified the "Failed to disable LTM" message
and commented out the goto in the line below. Also I used kernel
version 4.15-rc9 this time. I omitted upgrading the out-of-tree
modules broadcom-wl and nouveau-fw, so don't mind errors related to
that.
The SD card reader is still missing after resume.

dmesg & usbmon:
https://gist.github.com/anonymous/fc597612d5ebbac40d7bef9f8f0b579a

`usb_reset_and_verify_device()` is executed around dmesg line 1524.
Again, the usbmon log has a major gap around that time.
--
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-C Devices only show up if connected at boot

[Mika Westerberg]

On Thu, Jan 25, 2018 at 12:35:49PM +0200, Heikki Krogerus wrote:
> +Mika
> 
> On Tue, Jan 23, 2018 at 05:43:27PM +, Mike Lothian wrote:
> > On Tue, 23 Jan 2018 at 17:30 Greg KH  wrote:
> > >
> > > On Tue, Jan 23, 2018 at 05:12:03PM +, Mike Lothian wrote:
> > > > Hi
> > > >
> > > > I raised https://bugzilla.kernel.org/show_bug.cgi?id=198557 but was
> > > > informed by Greg bugs should be raised on the mailing list not in
> > > > bugzilla
> > > >
> > > > So USB-C devices only show up in dmesg or for use if they are
> > > > connected during boot
> > > >
> > > > Once booted and the device is disconnected the following message
> > > > appears in the dmesg:
> > > >
> > > > [  100.814687] usb 3-1: USB disconnect, device number 3
> > > > [  100.882840] xhci_hcd :39:00.0: xHCI host controller not
> > > > responding, assume dead
> > > > [  100.882843] xhci_hcd :39:00.0: HC died; cleaning up
> > > >
> > > > No further connections or disconnections display anything further in
> > > > the dmesg, the device works fine if connected via USB-A
> > > >
> > > > I've witnessed this behaviour since getting the laptop at the end of
> > > > 2015 so this isn't a regression
> > >
> > > Is there a BIOS update for the laptop?  This has been seen a lot in the
> > > past on lots of different laptops but was always resolved by the BIOS
> > > update (the latest one for mine also updates the xhci controller as
> > > well.)
> > >
> > > thanks,
> > >
> > > greg k-h
> > 
> > 
> > Hi
> > 
> > I've applied all BIOS updates for my laptop including the pulled one
> > for Spectre/Meltdown & ME bugs the other week
> > http://www.dell.com/support/home/uk/en/ukdhs1/product-support/servicetag/8k5w662/drivers
> > 
> > If it helps, I don't have this issue in Windows but I rarely have it booted
> > 
> > I thought it might have something to do with an ACPI failure (see bug
> > https://bugzilla.kernel.org/show_bug.cgi?id=198051)
> 
> Did you update the Thunderbolt firmware?
> 
> Mika, perhaps you can provide steps how to do that?

If it works in Windows then I suspect this is not related to the
firmware.

Mike, do you have PCI hotplug enabled in your .config? Following needs
to be set:

CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y

If not, please enabled them and try again.
--
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-C Devices only show up if connected at boot

[Heikki Krogerus]

+Mika

On Tue, Jan 23, 2018 at 05:43:27PM +, Mike Lothian wrote:
> On Tue, 23 Jan 2018 at 17:30 Greg KH  wrote:
> >
> > On Tue, Jan 23, 2018 at 05:12:03PM +, Mike Lothian wrote:
> > > Hi
> > >
> > > I raised https://bugzilla.kernel.org/show_bug.cgi?id=198557 but was
> > > informed by Greg bugs should be raised on the mailing list not in
> > > bugzilla
> > >
> > > So USB-C devices only show up in dmesg or for use if they are
> > > connected during boot
> > >
> > > Once booted and the device is disconnected the following message
> > > appears in the dmesg:
> > >
> > > [  100.814687] usb 3-1: USB disconnect, device number 3
> > > [  100.882840] xhci_hcd :39:00.0: xHCI host controller not
> > > responding, assume dead
> > > [  100.882843] xhci_hcd :39:00.0: HC died; cleaning up
> > >
> > > No further connections or disconnections display anything further in
> > > the dmesg, the device works fine if connected via USB-A
> > >
> > > I've witnessed this behaviour since getting the laptop at the end of
> > > 2015 so this isn't a regression
> >
> > Is there a BIOS update for the laptop?  This has been seen a lot in the
> > past on lots of different laptops but was always resolved by the BIOS
> > update (the latest one for mine also updates the xhci controller as
> > well.)
> >
> > thanks,
> >
> > greg k-h
> 
> 
> Hi
> 
> I've applied all BIOS updates for my laptop including the pulled one
> for Spectre/Meltdown & ME bugs the other week
> http://www.dell.com/support/home/uk/en/ukdhs1/product-support/servicetag/8k5w662/drivers
> 
> If it helps, I don't have this issue in Windows but I rarely have it booted
> 
> I thought it might have something to do with an ACPI failure (see bug
> https://bugzilla.kernel.org/show_bug.cgi?id=198051)

Did you update the Thunderbolt firmware?

Mika, perhaps you can provide steps how to do that?


Cheers,

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

Re: Request to add new VID/PID to PL2303 driver

['g...@kroah.com']

On Thu, Jan 25, 2018 at 09:37:16AM +, Chu.Mike [朱堅宜] wrote:
> Thanks, guys! Do you know what kernel version will I find this addition?

It will get merged into Linus's tree in the 4.16-rc1 merge window, and
then get backported to all of the stable kernel trees within a week or
so after that happens.

You will get an email when the patch gets added to those kernel trees
from my patch system.

thanks,

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

Re: [PATCH 3/3] firmware: Fix up docs referring to FIRMWARE_IN_KERNEL

[Greg KH]

On Wed, Jan 24, 2018 at 08:41:30AM +0100, Ingo Molnar wrote:
> 
> * Benjamin Gilbert  wrote:
> 
> > We've removed the option, so stop talking about it.
> > 
> > Signed-off-by: Benjamin Gilbert 
> > Cc: Borislav Petkov 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: H. Peter Anvin 
> > ---
> >  Documentation/driver-api/firmware/built-in-fw.rst | 7 +--
> >  Documentation/x86/microcode.txt   | 5 ++---
> >  arch/x86/Kconfig  | 6 +++---
> >  3 files changed, 6 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/driver-api/firmware/built-in-fw.rst 
> > b/Documentation/driver-api/firmware/built-in-fw.rst
> > index 7300e66857f8..396cdf591ac5 100644
> > --- a/Documentation/driver-api/firmware/built-in-fw.rst
> > +++ b/Documentation/driver-api/firmware/built-in-fw.rst
> > @@ -11,13 +11,8 @@ options:
> >* CONFIG_EXTRA_FIRMWARE
> >* CONFIG_EXTRA_FIRMWARE_DIR
> >  
> > -This should not be confused with CONFIG_FIRMWARE_IN_KERNEL, this is for 
> > drivers
> > -which enables firmware to be built as part of the kernel build process. 
> > This
> > -option, CONFIG_FIRMWARE_IN_KERNEL, will build all firmware for all drivers
> > -enabled which ship its firmware inside the Linux kernel source tree.
> > -
> >  There are a few reasons why you might want to consider building your 
> > firmware
> > -into the kernel with CONFIG_EXTRA_FIRMWARE though:
> > +into the kernel with CONFIG_EXTRA_FIRMWARE:
> >  
> >  * Speed
> >  * Firmware is needed for accessing the boot device, and the user doesn't
> > diff --git a/Documentation/x86/microcode.txt 
> > b/Documentation/x86/microcode.txt
> > index f57e1b45e628..aacd2f5e1a46 100644
> > --- a/Documentation/x86/microcode.txt
> > +++ b/Documentation/x86/microcode.txt
> > @@ -108,12 +108,11 @@ packages already put them there.
> >  
> >  
> >  The loader supports also loading of a builtin microcode supplied through
> > -the regular firmware builtin method CONFIG_FIRMWARE_IN_KERNEL. Only
> > -64-bit is currently supported.
> > +the regular firmware builtin method CONFIG_EXTRA_FIRMWARE. Only 64-bit is
> > +currently supported.
> 
> s/regular firmware builtin method
>  /regular builtin firmware method

I'll go edit that up by hand, thanks for the review.

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

Re: [PATCH] usb: serial: keyspan: remove unused USB_SERIAL_KEYSPAN_X firmware kconfig

[Greg KH]

On Mon, Jan 22, 2018 at 01:31:32PM +0100, Corentin Labbe wrote:
> All USB_SERIAL_KEYSPAN_X are not used anywhere in kernel tree.
> Furthermore all firmware files was removed since commit 2971c579f93bi 
> ("keyspan: use request_firmware()")
> So let's clean thoses unused symbols.
> 
> Signed-off-by: Corentin Labbe 

Benjamin Gilbert sent me a patch that fixes this up a bit better by also
removing the CONFIG option from the remaining defconfig locations, so
I'm going to take that version of this instead, sorry.

Thanks for the patch though, much appreciated.

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

RE: Request to add new VID/PID to PL2303 driver

[Chu . Mike [朱堅宜]]

Thanks, guys! Do you know what kernel version will I find this addition?


-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
Sent: Thursday, January 25, 2018 4:55 PM
To: 'g...@kroah.com'
Cc: Chu.Mike [朱堅宜]; Johan Hovold; linux-usb@vger.kernel.org
Subject: Re: Request to add new VID/PID to PL2303 driver

On Thu, Jan 25, 2018 at 09:51:11AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 25, 2018 at 03:44:46AM +, Chu.Mike [朱堅宜] wrote:
> > Dear Johan / Greg,
> >
> > We have a new customer who wants to add their VID/PID to the PL2303 driver 
> > source.
> > Can you help me?
> >
> > Customer: Chilitag
> > VID: 067B
> > PID: AAA8
> >
> > { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) },
> >
> > #define PL2303_VENDOR_ID0x067b
> > #define PL2303_PRODUCT_ID_CHILITAG0xaaa8
>
> Sure, how about the patch below?
>
> Johan, any objection to me adding this to my tree right now?

Please do so.

> ---
>
> From foo@baz Thu Jan 25 09:48:55 CET 2018
> Date: Thu, 25 Jan 2018 09:48:55 +0100
> From: Greg Kroah-Hartman 
> Subject: [PATCH] USB: serial: pl2303: new device id for Chilitag
>
> This adds a new device id for Chilitag devices to the pl2303 driver.
>
> Reported-by: "Chu.Mike [朱堅宜]" 
> Cc: stable 
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Johan Hovold 

Thanks,
Johan
保密警語: 
本電子郵件內容及其附加檔案均視為機密資料，受保密合約保護或依法不得洩漏。其內容僅供指定收件人按限定範圍或特殊目的合法使用，未經授權者收到此信息均無權閱讀、使用、複製、洩漏或散佈。若您並非本郵件之指定收件人，請即刻回覆郵件並永久刪除此郵件及其附件和銷毀所有複印文件。電子郵件的傳輸可能遭攔截、損毀、遺失、破壞、遲到或不完整、或包含病毒，無法保證其安全或無誤。寄件人不承擔因本電子郵件的錯誤或遺漏所產生的任何損害賠償責任。
 Confidentiality Notice: This e-mail message together with any attachments 
thereto (if any) is confidential, protected under an enforceable non-disclosure 
agreement, intended only for the use of the named recipient(s) above and may 
contain information that is privileged, belonging to professional work products 
or exempt from disclosure under applicable laws. Any unauthorized review, use, 
copying, disclosure, or distribution of any information contained in or 
attached to this transmission is strictly prohibited and may be against the 
laws. If you have received this message in error, or are not the intended 
recipient(s), please immediately notify the sender by e-mail and delete this 
e-mail message, all copies, and any attached documentation from your computer. 
E-mail transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any damage caused by any errors or omissions in the contents of this email.
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: Request to add new VID/PID to PL2303 driver

[Johan Hovold]

On Thu, Jan 25, 2018 at 09:51:11AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 25, 2018 at 03:44:46AM +, Chu.Mike [朱堅宜] wrote:
> > Dear Johan / Greg,
> > 
> > We have a new customer who wants to add their VID/PID to the PL2303 driver 
> > source.
> > Can you help me?
> > 
> > Customer: Chilitag
> > VID: 067B
> > PID: AAA8
> > 
> > { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) },
> > 
> > #define PL2303_VENDOR_ID0x067b
> > #define PL2303_PRODUCT_ID_CHILITAG0xaaa8
> 
> Sure, how about the patch below?
> 
> Johan, any objection to me adding this to my tree right now?

Please do so.

> ---
> 
> From foo@baz Thu Jan 25 09:48:55 CET 2018
> Date: Thu, 25 Jan 2018 09:48:55 +0100
> From: Greg Kroah-Hartman 
> Subject: [PATCH] USB: serial: pl2303: new device id for Chilitag
> 
> This adds a new device id for Chilitag devices to the pl2303 driver.
> 
> Reported-by: "Chu.Mike [朱堅宜]" 
> Cc: stable 
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Johan Hovold 

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

Re: Request to add new VID/PID to PL2303 driver

['g...@kroah.com']

On Thu, Jan 25, 2018 at 03:44:46AM +, Chu.Mike [朱堅宜] wrote:
> Dear Johan / Greg,
> 
> We have a new customer who wants to add their VID/PID to the PL2303 driver 
> source.
> Can you help me?
> 
> Customer: Chilitag
> VID: 067B
> PID: AAA8
> 
> { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) },
> 
> #define PL2303_VENDOR_ID0x067b
> #define PL2303_PRODUCT_ID_CHILITAG0xaaa8

Sure, how about the patch below?

Johan, any objection to me adding this to my tree right now?

thanks,

greg k-h

---

>From foo@baz Thu Jan 25 09:48:55 CET 2018
Date: Thu, 25 Jan 2018 09:48:55 +0100
From: Greg Kroah-Hartman 
Subject: [PATCH] USB: serial: pl2303: new device id for Chilitag

This adds a new device id for Chilitag devices to the pl2303 driver.

Reported-by: "Chu.Mike [朱堅宜]" 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 57ae832a49ff..46dd09da2434 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -38,6 +38,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) },
+   { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_CHILITAG) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_PHAROS) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ALDIGA) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_MMX) },
diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
index f98fd84890de..fcd72396a7b6 100644
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -12,6 +12,7 @@
 #define PL2303_PRODUCT_ID_DCU110x1234
 #define PL2303_PRODUCT_ID_PHAROS   0xaaa0
 #define PL2303_PRODUCT_ID_RSAQ30xaaa2
+#define PL2303_PRODUCT_ID_CHILITAG 0xaaa8
 #define PL2303_PRODUCT_ID_ALDIGA   0x0611
 #define PL2303_PRODUCT_ID_MMX  0x0612
 #define PL2303_PRODUCT_ID_GPRS 0x0609
--
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