[PATCH 4.18 REGRESSION fix 0/2] typec: tcpm: Fix current-limit for non PD charging

2018-07-01 Thread Hans de Goede 
Hi All,

Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
power_supply"), causes the GPD win and pocket to charge at 5V 500ma instead
of 5V 2000ma when using a non PD charger (the GPD win comes with a non PD
charger).

These 2 patches fix this. They are both needed to fix this, but they can be
merged independently of each other. Still it might be better to keep them
grouped together. Wolfgang, can we have your ack for Greg merging both
through the USB tree?

Regards,

Hans

--
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.18 REGRESSION fix 2/2] i2c-cht-wc: Fix bq24190 supplier

2018-07-01 Thread Hans de Goede 
Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
power_supply") moved the code to register a power_supply representing
the device supplying power to the type-C connector, from the fusb302
code to the generic tcpm code.

This has caused the power-supply registered by the fusb302 driver,
which determines how much current the bq24190 can draw, to change name
from "fusb302-typec-source" to "tcpm-source-psy-i2c-fusb302".

Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...")
Cc: Adam Thomson 
Signed-off-by: Hans de Goede 
---
 drivers/i2c/busses/i2c-cht-wc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
index 44cffad43701..c4d176f5ed79 100644
--- a/drivers/i2c/busses/i2c-cht-wc.c
+++ b/drivers/i2c/busses/i2c-cht-wc.c
@@ -234,7 +234,8 @@ static const struct irq_chip cht_wc_i2c_irq_chip = {
.name   = "cht_wc_ext_chrg_irq_chip",
 };
 
-static const char * const bq24190_suppliers[] = { "fusb302-typec-source" };
+static const char * const bq24190_suppliers[] = {
+   "tcpm-source-psy-i2c-fusb302" };
 
 static const struct property_entry bq24190_props[] = {
PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq24190_suppliers),
-- 
2.17.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.18 REGRESSION fix 1/2] typec: tcpm: Correctly report power_supply current and voltage for non pd supply

2018-07-01 Thread Hans de Goede 
Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
power_supply") moved the code to register a power_supply representing
the device supplying power to the type-C connector, from the fusb302
code to the generic tcpm code so that we have a psy reporting the
supply voltage and current for all tcpm devices.

This broke the reporting of current and voltage through the psy interface
when supplied by a a non pd supply (5V, current as reported by
get_current_limit). The cause of this breakage is port->supply_voltage
and port->current_limit not being set in that case.

This commit fixes this by setting port->supply_voltage and
port->current_limit from tcpm_set_current_limit().

This commit also removes setting supply_voltage and current_limit
from tcpm_reset_port() as that calls tcpm_set_current_limit(0, 0)
which now already sets these to 0.

Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...")
Cc: Adam Thomson 
Signed-off-by: Hans de Goede 
---
 drivers/usb/typec/tcpm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 8a201dd53d36..316959c26db9 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -724,6 +724,9 @@ static int tcpm_set_current_limit(struct tcpm_port *port, 
u32 max_ma, u32 mv)
 
tcpm_log(port, "Setting voltage/current limit %u mV %u mA", mv, max_ma);
 
+   port->supply_voltage = mv;
+   port->current_limit = max_ma;
+
if (port->tcpc->set_current_limit)
ret = port->tcpc->set_current_limit(port->tcpc, max_ma, mv);
 
@@ -2594,8 +2597,6 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
-   port->supply_voltage = 0;
-   port->current_limit = 0;
port->usb_type = POWER_SUPPLY_USB_TYPE_C;
 
power_supply_changed(port->psy);
-- 
2.17.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 4.18 REGRESSION fix 0/2] typec: tcpm: Fix current-limit for non PD charging

2018-07-01 Thread Wolfram Sang 

> grouped together. Wolfgang, can we have your ack for Greg merging both
> through the USB tree?

My name is "Wolfram".



signature.asc
Description: PGP signature

Re: [PATCH 4.18 REGRESSION fix 2/2] i2c-cht-wc: Fix bq24190 supplier

2018-07-01 Thread Wolfram Sang 
On Sun, Jul 01, 2018 at 11:48:35AM +0200, Hans de Goede wrote:
> Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
> power_supply") moved the code to register a power_supply representing
> the device supplying power to the type-C connector, from the fusb302
> code to the generic tcpm code.
> 
> This has caused the power-supply registered by the fusb302 driver,
> which determines how much current the bq24190 can draw, to change name
> from "fusb302-typec-source" to "tcpm-source-psy-i2c-fusb302".
> 
> Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...")
> Cc: Adam Thomson 
> Signed-off-by: Hans de Goede 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

[PATCH] USB: typec: fsusb302: Drop empty set_current_limit implementation

2018-07-01 Thread Hans de Goede 
The set_current_limit tcpm_dev callback is optional and the tcpm core
will already log the passed in values, so there is no need to have an
empty implementation of this.

Signed-off-by: Hans de Goede 
---
 drivers/usb/typec/fusb302/fusb302.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 1e68da10bf17..82bed9810be6 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -864,17 +864,6 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
return ret;
 }
 
-static int tcpm_set_current_limit(struct tcpc_dev *dev, u32 max_ma, u32 mv)
-{
-   struct fusb302_chip *chip = container_of(dev, struct fusb302_chip,
-tcpc_dev);
-
-   fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
-   max_ma, mv);
-
-   return 0;
-}
-
 static int fusb302_pd_tx_flush(struct fusb302_chip *chip)
 {
return fusb302_i2c_set_bits(chip, FUSB_REG_CONTROL0,
@@ -1213,7 +1202,6 @@ static void init_tcpc_dev(struct tcpc_dev 
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_polarity = tcpm_set_polarity;
fusb302_tcpc_dev->set_vconn = tcpm_set_vconn;
fusb302_tcpc_dev->set_vbus = tcpm_set_vbus;
-   fusb302_tcpc_dev->set_current_limit = tcpm_set_current_limit;
fusb302_tcpc_dev->set_pd_rx = tcpm_set_pd_rx;
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;
-- 
2.17.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] USB: typec: fsusb302: Drop empty set_current_limit implementation

2018-07-01 Thread Guenter Roeck 

On 07/01/2018 05:27 AM, Hans de Goede wrote:

The set_current_limit tcpm_dev callback is optional and the tcpm core
will already log the passed in values, so there is no need to have an
empty implementation of this.

Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
  drivers/usb/typec/fusb302/fusb302.c | 12 
  1 file changed, 12 deletions(-)

diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 1e68da10bf17..82bed9810be6 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -864,17 +864,6 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
return ret;
  }
  
-static int tcpm_set_current_limit(struct tcpc_dev *dev, u32 max_ma, u32 mv)

-{
-   struct fusb302_chip *chip = container_of(dev, struct fusb302_chip,
-tcpc_dev);
-
-   fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
-   max_ma, mv);
-
-   return 0;
-}
-
  static int fusb302_pd_tx_flush(struct fusb302_chip *chip)
  {
return fusb302_i2c_set_bits(chip, FUSB_REG_CONTROL0,
@@ -1213,7 +1202,6 @@ static void init_tcpc_dev(struct tcpc_dev 
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_polarity = tcpm_set_polarity;
fusb302_tcpc_dev->set_vconn = tcpm_set_vconn;
fusb302_tcpc_dev->set_vbus = tcpm_set_vbus;
-   fusb302_tcpc_dev->set_current_limit = tcpm_set_current_limit;
fusb302_tcpc_dev->set_pd_rx = tcpm_set_pd_rx;
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;



--
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 4.18 REGRESSION fix 1/2] typec: tcpm: Correctly report power_supply current and voltage for non pd supply

2018-07-01 Thread Guenter Roeck 

On 07/01/2018 02:48 AM, Hans de Goede wrote:

Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
power_supply") moved the code to register a power_supply representing
the device supplying power to the type-C connector, from the fusb302
code to the generic tcpm code so that we have a psy reporting the
supply voltage and current for all tcpm devices.

This broke the reporting of current and voltage through the psy interface
when supplied by a a non pd supply (5V, current as reported by
get_current_limit). The cause of this breakage is port->supply_voltage
and port->current_limit not being set in that case.

This commit fixes this by setting port->supply_voltage and
port->current_limit from tcpm_set_current_limit().

This commit also removes setting supply_voltage and current_limit
from tcpm_reset_port() as that calls tcpm_set_current_limit(0, 0)
which now already sets these to 0.

Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...")
Cc: Adam Thomson 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
  drivers/usb/typec/tcpm.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 8a201dd53d36..316959c26db9 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -724,6 +724,9 @@ static int tcpm_set_current_limit(struct tcpm_port *port, 
u32 max_ma, u32 mv)
  
  	tcpm_log(port, "Setting voltage/current limit %u mV %u mA", mv, max_ma);
  
+	port->supply_voltage = mv;

+   port->current_limit = max_ma;
+
if (port->tcpc->set_current_limit)
ret = port->tcpc->set_current_limit(port->tcpc, max_ma, mv);
  
@@ -2594,8 +2597,6 @@ static void tcpm_reset_port(struct tcpm_port *port)

tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
-   port->supply_voltage = 0;
-   port->current_limit = 0;
port->usb_type = POWER_SUPPLY_USB_TYPE_C;
  
  	power_supply_changed(port->psy);




--
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 4.18 REGRESSION fix 2/2] i2c-cht-wc: Fix bq24190 supplier

2018-07-01 Thread Guenter Roeck 

On 07/01/2018 02:48 AM, Hans de Goede wrote:

Commit f2a8aa053c17 ("typec: tcpm: Represent source supply through
power_supply") moved the code to register a power_supply representing
the device supplying power to the type-C connector, from the fusb302
code to the generic tcpm code.

This has caused the power-supply registered by the fusb302 driver,
which determines how much current the bq24190 can draw, to change name
from "fusb302-typec-source" to "tcpm-source-psy-i2c-fusb302".

Fixes: f2a8aa053c17 ("typec: tcpm: Represent source supply through...")
Cc: Adam Thomson 
Signed-off-by: Hans de Goede 


Reviewed-by: Guenter Roeck 


---
  drivers/i2c/busses/i2c-cht-wc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
index 44cffad43701..c4d176f5ed79 100644
--- a/drivers/i2c/busses/i2c-cht-wc.c
+++ b/drivers/i2c/busses/i2c-cht-wc.c
@@ -234,7 +234,8 @@ static const struct irq_chip cht_wc_i2c_irq_chip = {
.name   = "cht_wc_ext_chrg_irq_chip",
  };
  
-static const char * const bq24190_suppliers[] = { "fusb302-typec-source" };

+static const char * const bq24190_suppliers[] = {
+   "tcpm-source-psy-i2c-fusb302" };
  
  static const struct property_entry bq24190_props[] = {

PROPERTY_ENTRY_STRING_ARRAY("supplied-from", bq24190_suppliers),



--
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: Zero Packets in Isochronous Transfer Reception

2018-07-01 Thread Alan Stern 
On Sat, 30 Jun 2018, R0b0t1 wrote:

> Hello,
> 
> My code is a userspace application using libusb for now, but this
> seems the best place to ask.
> 
> I repurposed some USB audio class device code. At this point I've only
> changed the descriptor to report as vendor class so nothing else grabs
> the device. I can receive and play PCM audio from the device, but
> there is popping and clicking. The program I am using is attached; it
> is written in Python. The data is saved to RAM and then written to
> disk.
> 
> The device does not implement the synchronization aspect of the USB
> audio class and when it registers as a microphone a normal userland
> can read it properly.
> 
> During testing I think I noticed behavior related to my issue - for
> some reason there will be long runs of zero returned or no data
> returned. Usually this happens when a single transfer is scheduled.
> Many transfers in a row tend to report the data properly, but from the
> audible results I get it seems that runs of zeros still seem to slip
> in.
> 
> The problem seems more noticeable when using the Python libusb
> bindings but it still exists when using libusb directly. Can anyone
> suggest what to look into?

Have you tried using usbmon to capture the data as it is received by 
the kernel?

Alan Stern

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

Re: [PATCH] Bluetooth: btusb: use irqsave() in URB's complete callback

2018-07-01 Thread Sebastian Andrzej Siewior 
On 2018-06-21 11:34:15 [-0400], Alan Stern wrote:
> On Thu, 21 Jun 2018, Sebastian Andrzej Siewior wrote:
> 
> > On 2018-06-21 14:43:41 [+0200], Marcel Holtmann wrote:
> > > can I get an ACK from someone ensuring that this is the direction we are 
> > > going with the USB host controllers?
> > +Alan.
> > 
> > EHCI completes in BH since v3.12-rc1. In order to get rid of that
> > local_irq_save() in USB core code I need to make sure that the USB
> > device driver(s) use irqsave primitives. See
> >   
> > https://lkml.kernel.org/r/pine.lnx.4.44l0.1806011629140.1404-100...@iolanthe.rowland.org
> 
> Hi, Marcel!
Hi Marcel,

> Yes, Sebastian is right.  We are aiming to make it possible for the USB 
> core to invoke URB completion handlers with interrupts enabled, in 
> order to reduce latency (since USB interrupt processing can take a 
> fairly long time).  And of course, this means completion handlers have 
> to work correctly regardless of whether interrupts are enabled or 
> disabled.

I don't see this patch in linux-next. Do you still need some kind of
confirmation or has this been resolved?

> Currently ehci-hcd supports this possibility.  Other host controller 
> drivers may follow along; I'd like to see xhci-hcd do this too.
> 
> Alan Stern

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

[PATCH 07/12 v2] usb: usbtest: use irqsave() in USB's complete callback

2018-07-01 Thread Sebastian Andrzej Siewior 
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

Cc: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Sebastian Andrzej Siewior 
---
v1…v2: don't enable interrupts while releasing the lock around unlink()
   in ctrl_complete()

 drivers/usb/misc/usbtest.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 9e1142b8b91b..c7f82310e73e 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1082,11 +1082,12 @@ static void ctrl_complete(struct urb *urb)
struct usb_ctrlrequest  *reqp;
struct subcase  *subcase;
int status = urb->status;
+   unsigned long   flags;
 
reqp = (struct usb_ctrlrequest *)urb->setup_packet;
subcase = container_of(reqp, struct subcase, setup);
 
-   spin_lock(&ctx->lock);
+   spin_lock_irqsave(&ctx->lock, flags);
ctx->count--;
ctx->pending--;
 
@@ -1185,7 +1186,7 @@ static void ctrl_complete(struct urb *urb)
/* signal completion when nothing's queued */
if (ctx->pending == 0)
complete(&ctx->complete);
-   spin_unlock(&ctx->lock);
+   spin_unlock_irqrestore(&ctx->lock, flags);
 }
 
 static int
@@ -1917,8 +1918,9 @@ struct transfer_context {
 static void complicated_callback(struct urb *urb)
 {
struct transfer_context *ctx = urb->context;
+   unsigned long flags;
 
-   spin_lock(&ctx->lock);
+   spin_lock_irqsave(&ctx->lock, flags);
ctx->count--;
 
ctx->packet_count += urb->number_of_packets;
@@ -1958,7 +1960,7 @@ static void complicated_callback(struct urb *urb)
complete(&ctx->done);
}
 done:
-   spin_unlock(&ctx->lock);
+   spin_unlock_irqrestore(&ctx->lock, flags);
 }
 
 static struct urb *iso_alloc_urb(
-- 
2.18.0

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

RE: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected

2018-07-01 Thread Peter Chen 
 
> 
> On Mon, Jun 25, 2018 at 7:24 AM Fabio Estevam  wrote:
> >
> > From: Fabio Estevam 
> >
> > Since commit 03e6275ae381087bd8 ("usb: chipidea: Fix ULPI on imx51")
> > the kernel hangs on a imx51-babbage board, when using the ULPI
> > interface with the CONFIG_USB_CHIPIDEA_ULPI option unselected.
> >
> > Instead of hanging the kernel, let's warn the user that
> > CONFIG_USB_CHIPIDEA_ULPI needs to be selected, propagate an error and
> > continue with booting the kernel.
> >
> > The user can then react to the warning and select
> > CONFIG_USB_CHIPIDEA_ULPI as needed.
> >
> > Fixes: 03e6275ae381087bd8 ("usb: chipidea: Fix ULPI on imx51")
> > Suggested-by: Lucas Stach 
> > Signed-off-by: Fabio Estevam 
> 
> FWIW:
> 
> Tested-by: Andrey Smirnov 
> 
> > ---
> > Changes since v1:
> > - Only propagate the error when CONFIG_USB_CHIPIDEA_ULPI is unselected
> >
> >  drivers/usb/chipidea/core.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 85fc6db..e7018a1 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -608,6 +608,17 @@ static int ci_get_platdata(struct device *dev,
> > if (!platdata->phy_mode)
> > platdata->phy_mode =
> > of_usb_get_phy_mode(dev->of_node);
> >
> > +   if (platdata->phy_mode == USBPHY_INTERFACE_MODE_ULPI) {
> > +   /*
> > +* CONFIG_USB_CHIPIDEA_ULPI needs to be selected
> > +* for proper usage of the ULPI mode
> > +*/
> > +   if (!IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)) {
> > +   WARN_ONCE(1, "Select CONFIG_USB_CHIPIDEA_ULPI in 
> > order
> to use ULPI mode\n");
> > +   return -EINVAL;
> > +   }
> > +   }
> > +
> > if (!platdata->dr_mode)
> > platdata->dr_mode = usb_get_dr_mode(dev);
> >

Fabio, since this function has dependency with defconfig, is the defconfig 
change a fix for v4.18-rc
or for v4.19-rc1?

Peter
N�r��y���b�X��ǧv�^�)޺{.n�+{�^n�r��z���h&���G���h�(�階�ݢj"���m�z�ޖ���f���h���~�m�

Re: USB Gadget driver for USB screen?

2018-07-01 Thread Clemens Ladisch 
Sebastian Nielsen wrote:
> Does anyone know of a USB Gadget kernel driver for a USB screen?

There is no standardized device class for USB-to-VGA devices.

> So I can have a linux USB gadget emulate as a USB screen to the host PC, and
> aquire it's picture as a picture stream?

You could try reverse engineering the protocol used by the sisusbvga
or udl drivers, and implementing that.


Regards,
Clemens
--
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: dwc2: crash regression in commit 3bc04e28a030 (bisected)

2018-07-01 Thread Antti Seppälä 
On 30 June 2018 at 02:57, Doug Anderson  wrote:
> Hi,
>
> On Fri, Jun 29, 2018 at 11:29 AM, Antti Seppälä  wrote:
>> Hi Doug, John and linux-usb.
>>
>> I'd like to report a regression in commit 3bc04e28a030 (usb: dwc2:
>> host: Get aligned DMA in a more supported way)
>
> Seems unlikely, but any chance that
>  helps you?
>

Thank you for your suggestion but unfortunately the patch does not
help and the crash remains.

>
>> Apparently the patch does something nasty that the Lantiq platform
>> really does not like as whenever I plug my usb 3g modem into the usb
>> port of my BT HomeHub v5 (Lantiq XRX200) I get a kernel
>> oops/crash/panic with usually quite a weird content that looks like
>> some sort of memory corruption.
>>
>> I've bisected the crash and reverting 3bc04e28a030 allows the 3g-modem
>> to be plugged and the kernel does not crash.
>>
>> Below is the console log when I plug the modem in. I used stable
>> vanilla kernel 4.9.109 from OpenWrt during my tests with dwc2 debug
>> prints enabled:
>>
>> root@lantiq:/# echo -n "module dwc2 +p" >
>> /sys/kernel/debug/dynamic_debug/control
>> [   92.563454] dwc2 1e101000.ifxhcd: gintsts=0521  gintmsk=f3000806
>> [   92.568762] dwc2 1e101000.ifxhcd: DWC OTG HCD HUB STATUS DATA: Root
>> port status changed
>> [   92.576447] dwc2 1e101000.ifxhcd:   port_connect_status_change: 1
>> [   92.582523] dwc2 1e101000.ifxhcd:   port_reset_change: 0
>> [   92.587830] dwc2 1e101000.ifxhcd:   port_enable_change: 0
>> [   92.593228] dwc2 1e101000.ifxhcd:   port_suspend_change: 0
>> [   92.598710] dwc2 1e101000.ifxhcd:   port_over_current_change: 0
>> [   92.607242] dwc2 1e101000.ifxhcd: ClearPortFeature 
>> USB_PORT_FEAT_C_CONNECTION
>> [   92.758240] dwc2 1e101000.ifxhcd: SetPortFeature
>> [   92.761535] dwc2 1e101000.ifxhcd: SetPortFeature - USB_PORT_FEAT_RESET
>> [   92.768063] dwc2 1e101000.ifxhcd: In host mode, hprt0=00021501
>> [   92.841013] dwc2 1e101000.ifxhcd: gintsts=0529  gintmsk=f3000806
>> [   92.905329] dwc2 1e101000.ifxhcd: ClearPortFeature USB_PORT_FEAT_C_RESET
>> [   92.968536] usb 1-1: new high-speed USB device number 2 using dwc2
>> [   92.975029] dwc2 1e101000.ifxhcd: SetPortFeature
>> [   92.978358] dwc2 1e101000.ifxhcd: SetPortFeature - USB_PORT_FEAT_RESET
>> [   92.984837] dwc2 1e101000.ifxhcd: In host mode, hprt0=1101
>> [   92.990674] dwc2 1e101000.ifxhcd: gintsts=0529  gintmsk=f3000806
>> [   93.060349] dwc2 1e101000.ifxhcd: DWC OTG HCD HUB STATUS DATA: Root
>> port status changed
>> [   93.067020] dwc2 1e101000.ifxhcd:   port_connect_status_change: 0
>> [   93.073099] dwc2 1e101000.ifxhcd:   port_reset_change: 0
>> [   93.078375] dwc2 1e101000.ifxhcd:   port_enable_change: 1
>> [   93.083766] dwc2 1e101000.ifxhcd:   port_suspend_change: 0
>> [   93.089252] dwc2 1e101000.ifxhcd:   port_over_current_change: 0
>> [   93.096284] dwc2 1e101000.ifxhcd: gintsts=0529  gintmsk=f3000806
>> [   93.152672] dwc2 1e101000.ifxhcd: ClearPortFeature USB_PORT_FEAT_C_RESET
>> [   93.216952] dwc2 1e101000.ifxhcd: DWC OTG HCD EP DISABLE:
>> bEndpointAddress=0x00, ep->hcpriv=86e4fa00
>> [   93.224792] dwc2 1e101000.ifxhcd: DWC OTG HCD EP DISABLE:
>> bEndpointAddress=0x00, ep->hcpriv=  (null)
>> [   93.233926] dwc2 1e101000.ifxhcd: DWC OTG HCD EP RESET: 
>> bEndpointAddress=0x00
>> [   93.268547] dwc2 1e101000.ifxhcd: DWC OTG HCD EP RESET: 
>> bEndpointAddress=0x81
>> [   93.274399] dwc2 1e101000.ifxhcd: DWC OTG HCD EP RESET: 
>> bEndpointAddress=0x01
>> [   93.307463] usb-storage 1-1:1.0: USB Mass Storage device detected
>> [   93.312238] dwc2 1e101000.ifxhcd: DWC OTG HCD HUB STATUS DATA: Root
>> port status changed
>> [   93.312256] dwc2 1e101000.ifxhcd:   port_connect_status_change: 0
>> [   93.312270] dwc2 1e101000.ifxhcd:   port_reset_change: 0
>> [   93.312329] dwc2 1e101000.ifxhcd:   port_enable_change: 1
>> [   93.312342] dwc2 1e101000.ifxhcd:   port_suspend_change: 0
>> [   93.312356] dwc2 1e101000.ifxhcd:   port_over_current_change: 0
>> [   93.408514] scsi host0: usb-storage 1-1:1.0
>> [   93.437010] dwc2 1e101000.ifxhcd: ClearPortFeature USB_PORT_FEAT_C_ENABLE
>> [   94.152597] dwc2 1e101000.ifxhcd: DWC OTG HCD EP RESET: 
>> bEndpointAddress=0x01
>> [   94.166421] dwc2 1e101000.ifxhcd: gintsts=2529  gintmsk=f3000806
>> [   94.171336] dwc2 1e101000.ifxhcd: ++Disconnect Detected Interrupt++
>> (Host) a_host
>> [   94.180561] dwc2 1e101000.ifxhcd: DWC OTG HCD EP RESET: 
>> bEndpointAddress=0x01
>> [   94.186473] dwc2 1e101000.ifxhcd: Not connected
>> [   94.300415] dwc2 1e101000.ifxhcd: DWC OTG HCD HUB STATUS DATA: Root
>> port status changed
>> [   94.307074] dwc2 1e101000.ifxhcd:   port_connect_status_change: 1
>> [   94.313203] dwc2 1e101000.ifxhcd:   port_reset_change: 0
>> [   94.318467] dwc2 1e101000.ifxhcd:   port_enable_change: 1
>> [   94.323858] dwc2 1e101000.ifxhcd:   port_suspend_change: 0
>> [   94.329344] dwc2 1e101000.ifxhcd:   port_over_current_change: 0
>> [   94.336998]