Re: [PATCH 2/2] usb: chipidea: otg: use usb autosuspend to suspend bus for HNP

[Peter Chen]

On Tue, Dec 15, 2015 at 06:26:07PM +0800, Li Jun wrote:
> Directly manipulate the controller regsiter to suspend the usb bus
> for HNP is not the proper way, this should be done through the usbcore
> by usb autosuspend. So to start HNP, autosuspend support should be
> added for OTG devices interface driver if it's not enabled.
>
> Signed-off-by: Li Jun 
> ---
>  drivers/usb/chipidea/otg_fsm.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index 00ab59d..ba90dc6 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -485,20 +485,30 @@ static void ci_otg_loc_conn(struct otg_fsm *fsm, int on)
>
>  /*
>   * Generate SOF by host.
> - * This is controlled through suspend/resume the port.
>   * In host mode, controller will automatically send SOF.
>   * Suspend will block the data on the port.
> + *
> + * This is controlled through usbcore by usb autosuspend,
> + * so the usb device class driver need support autosuspend,
> + * otherwise the bus suspend will not happen.
>   */
>  static void ci_otg_loc_sof(struct otg_fsm *fsm, int on)
>  {
> - struct ci_hdrc *ci = container_of(fsm, struct ci_hdrc, fsm);
> + struct usb_device *udev;
>
> - if (on)
> - hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_FPR,
> - PORTSC_FPR);
> - else
> - hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_SUSP,
> - PORTSC_SUSP);
> + if (!fsm->otg->host)
> + return;
> +
> + udev = usb_hub_find_child(fsm->otg->host->root_hub, 1);
> + if (!udev)
> + return;
> +
> + if (on) {
> + usb_disable_autosuspend(udev);
> + } else {
> + pm_runtime_set_autosuspend_delay(>dev, 0);
> + usb_enable_autosuspend(udev);
> + }
>  }
>
>  /*

I am ok with these two, will queue them.

-- 

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: MX28 with hub cannot reset

[Peter Chen]

On Wed, Dec 23, 2015 at 6:54 AM, Fabio Estevam  wrote:
> Hi,
>
> On a mx28 custom board with a USB hub I can get a USB stick to get
> detected after applying this change:
> http://marc.info/?l=linux-usb=145079935324339=2
>
> Things work fine if I boot without the USB stick connected. Then I can
> insert/remove the USB device and it always gets detected.
>
> However, if I boot with the USB stick connected I get:
>
> [2.968513] hub 1-1:1.0: USB hub found
> [2.973096] hub 1-1:1.0: 2 ports detected
> [3.479731] usb 1-1: USB disconnect, device number 2
> [3.525403] usb usb1-port1: cannot reset (err = -32)
> [3.530828] usb usb1-port1: cannot reset (err = -32)
> [3.536089] usb usb1-port1: cannot reset (err = -32)
> [3.541600] usb usb1-port1: cannot reset (err = -32)
> [3.546857] usb usb1-port1: cannot reset (err = -32)
> [3.551982] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [3.560302] usb usb1-port1: cannot reset (err = -32)
> [3.565566] usb usb1-port1: cannot reset (err = -32)
> [3.571011] usb usb1-port1: cannot reset (err = -32)
> [3.576266] usb usb1-port1: cannot reset (err = -32)
> [3.581769] usb usb1-port1: cannot reset (err = -32)
> [3.586780] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [3.594138] usb usb1-port1: cannot reset (err = -32)
> [3.599615] usb usb1-port1: cannot reset (err = -32)
> [3.604871] usb usb1-port1: cannot reset (err = -32)
> [3.610244] usb usb1-port1: cannot reset (err = -32)
> [3.615499] usb usb1-port1: cannot reset (err = -32)
> [3.620649] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [3.627989] usb usb1-port1: cannot reset (err = -32)
> [3.633370] usb usb1-port1: cannot reset (err = -32)
> [3.638617] usb usb1-port1: cannot reset (err = -32)
> [3.644171] usb usb1-port1: cannot reset (err = -32)
> [3.649546] usb usb1-port1: cannot reset (err = -32)
> [3.654557] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [3.661650] usb usb1-port1: unable to enumerate USB device
>
> And the only way to get the USB port working again is to remove the
> USB stick and reboot the board.
>
> Commit d0ee68b59e6aa33221 ("usb: phy: mxs: Add VF610 USB PHY support")
> shows the same error messages in the commit log, but trying the same
> approach of adding the MXS_PHY_NEED_IP_FIX flag does not help on mx28.
>
> Any suggestions?

Fabio, there is a bug for imx28 usb low power mode, and we have no
good way to implement
workaround using current USB PHY framework, would you please test by
add "usbcore.autosuspend = -1"
at bootargs (no CI_HDRC_SUPPORTS_RUNTIME_PM needed to set for imx28) to
see if this problem can fix?


-- 
BR,
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: MX28 with hub cannot reset

[Fabio Estevam]

Hi Peter,

On Wed, Dec 23, 2015 at 7:49 AM, Peter Chen  wrote:

> Fabio, there is a bug for imx28 usb low power mode, and we have no
> good way to implement
> workaround using current USB PHY framework, would you please test by
> add "usbcore.autosuspend = -1"
> at bootargs (no CI_HDRC_SUPPORTS_RUNTIME_PM needed to set for imx28) to
> see if this problem can fix?

Excellent, passing 'usbcore.autosuspend=-1' fixes the issue!

Do you think we could have a fix for mx28 so that we don't need to
pass this option?

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

Re: [linux-usb-users] g_serial is not working in rx path (K3.14)

[Ramajayam S]

On Tue, Dec 22, 2015 at 7:48 PM, Ramajayam S  wrote:
> On Mon, Dec 14, 2015 at 11:17 PM, Ramajayam S
>  wrote:
>> On Mon, Dec 14, 2015 at 9:50 PM, Felipe Balbi  wrote:
>>>
>>> hi,
>>>
>>> Ramajayam S  writes:
 Hi
We are trying to enable g_serial in Intel platform and facing
 issue with RX path.

 stable kernel version: K3.14
>>>
>>> you need to test with something more recent, like v4.3. If you are stuck
>>> with Intel' v3.14 kernel, then you need to ask for support from Intel,
>> ok
>>> I'm afraid
>>>
 configuration enabled: USB_G_SERIAL

 testing details:

 writing from device side(ttyS0) to Windows Host(com 11-g_serial): working 
 fine

 from ttyS0: echo test > /dev/ttyGS0  -- received in comm 11

 Typing any character from windows host pc(com 11 using teraterm) to
 device side: not working
>>>
>>> what do you mean not working ? What happens ? Got usbmon trace or some
>>> usb sniffer ?
>> We have profiled using USB SW analyzer, by pressing enter key from USB
>> console(ttyGS0-com11 ) both the OUT/IN token sent from Host
>> PC(windows).
>> For IN token,
>> Working case: device is responded with proper data(approx 20 bytes for
>> command prompt display in ttyGSO-com11) and able to see raw data in
>> function   gs_write.
>> Non-Working Case: device is responded  with 1 byte of data and  able
>> to see raw data in function   gs_write (no response in command prompt
>> display --ttyGS0-com11)
> If we had print in n_tty_read function(after job_control function),
> console(ttyGS0-Com11) is working fine with double key press.
> 1st key press(enter key): user space is requesting to read 512 bytes
> of data instead of 1 byte -- non working scenario
> 2nd key Press(enter key): user space is requesting to read 1 byte of
> data --  working scenario
Issue is root caused with virtualization code(virtual usb). collision
is happened b/w virtual usb request and g_serial terminal request in
tty layer(read).
> Ramajayam S
>>>
>>> --
>>> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

[Felipe Ferreri Tonello]

Hi Clemens,

On 22/12/15 17:10, Clemens Ladisch wrote:
> Felipe F. Tonello wrote:
>> This refactor includes the following:
>>  * Cleaner state machine code;
> 
> It does not correctly handle system real time messages inserted between
> the status and data bytes of other messages.

True, thanks for pointing that out. I fixed that on next revision of
this patch.

> 
>>  * Reset state if MIDI message parsed is non-conformant;
> 
> Why?  In a byte stream like "C1 C3 44", where the data byte of the first
> message was lost, the reset would also drop the second message.

True. That was fixed as well.

> 
>>  * Fixed bug when a conformant MIDI message was followed by a non-conformant
>>causing the MIDI-USB message to use old temporary data (port->data[0..1]),
>>thus packing a wrong MIDI-USB request.
> 
> Running status is feature.

What do you mean by that? I don't qualify writing a *wrong* MIDI-USB
packet because of a previous MIDI message as a feature.

For instance, try this MIDI message:
"8A 54 24 00 40"

It will be converted to MIDI-USB as "08 8A 54 24 08 8A 00 40" which is
wrong. It should only be "08 8A 54 24" and ignore the "00 40" MIDI bytes.

On every state byte the message should basically reset data[0..1] to
zero overwriting previous data. This should also be true when a MIDI-USB
packet is complete.

Felipe


0x92698E6A.asc
Description: application/pgp-keys

[PATCH] BugFix in XHCI controller driver for scatter gather DMA

[Vikas Bansal]

From: Sumit Batra  

Pre-Condition 
URB with Scatter Gather list is queued to bulk OUT endpoint.
Every buffer in scatter gather list is not a multiple of maximum packet 
size for that endpoint(short packet).
CHAIN bit is set for all TRBs in a TD so that the DMA happens to all of 
them at once. 

Issue
DMA operation copies all the CHAINED TRBs at contiguous device memory.
But since the original packet was a short packet, so the actual data is 
re-aligned after this DMA operation.
At device end this re-aligned data causes data integrity issue with 
applications like ICMP ping.

Solution
Don't set the CHAINED bit for these TRBs, if their buffers are not a 
multiple of maximum packet size.
This will reduce the benefit in throughput as required from a scatter 
gather implementation, but this reduces the CPU utilization.
And solves the data integrity issue on Device End


Signed-off-by: Sumit Batra 
Signed-off-by: Vikas Bansal 
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..7363dee 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3110,7 +3110,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t 
mem_flags,
 * TRB to indicate it's the last TRB in the chain.
 */
if (num_trbs > 1) {
-   field |= TRB_CHAIN;
+   if (this_sg_len %
+   usb_endpoint_maxp(>ep->desc) == 0)
+   field |= TRB_CHAIN;
} else {
/* FIXME - add check for ZERO_PACKET flag before this */
td->last_trb = ep_ring->enqueue;
--
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] BugFix in XHCI controller driver for scatter gather DMA

[Mathias Nyman]

On 23.12.2015 13:58, Vikas Bansal wrote:

From: Sumit Batra 

Pre-Condition
URB with Scatter Gather list is queued to bulk OUT endpoint.
Every buffer in scatter gather list is not a multiple of maximum packet
size for that endpoint(short packet).
CHAIN bit is set for all TRBs in a TD so that the DMA happens to all of
them at once.

Issue
DMA operation copies all the CHAINED TRBs at contiguous device memory.
But since the original packet was a short packet, so the actual data is
re-aligned after this DMA operation.
At device end this re-aligned data causes data integrity issue with
applications like ICMP ping.

Solution
Don't set the CHAINED bit for these TRBs, if their buffers are not a
multiple of maximum packet size.
This will reduce the benefit in throughput as required from a scatter
gather implementation, but this reduces the CPU utilization.
And solves the data integrity issue on Device End


Signed-off-by: Sumit Batra 
Signed-off-by: Vikas Bansal 
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7d34cbf..7363dee 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3110,7 +3110,9 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t 
mem_flags,
 * TRB to indicate it's the last TRB in the chain.
 */
if (num_trbs > 1) {
-   field |= TRB_CHAIN;
+   if (this_sg_len %
+   usb_endpoint_maxp(>ep->desc) == 0)
+   field |= TRB_CHAIN;
} else {
/* FIXME - add check for ZERO_PACKET flag before this */


Hi

I don't fully understand the issue here yet, and I need to look into this more.
I believe removing the CHAIN bit from a TRB mid TD would make the xhc interpret
it as two separate TDs, and in this case the TD size fields of the TRBs will be 
wrong.

xhci supports Scatter/Gather transfers where the TRBs of a Multi-TRB TD have 
different
length fields. specs say "(xhc) form a concatenated data buffer from separate 
buffers
that reside in memory. If the Transfer Ring was associated with an OUT Endpoint 
then the
concatenated data buffer would be sent to the USB Device as single transfer"

"Note that no constraints are placed on the TRB Length fields in a 
Scatter/Gather list.
Classically all the buffers pointed to by a scatter gather list were required 
to be “page size”
in length except for the first and last (as illustrated by the example above).
The xHCI does not require this constraint. Any buffer pointed to by a Normal, 
Data Stage,
or Isoch TRB in a TD may be any size between 0 and 64K bytes in size."

"Note: A USB packet may be comprised of the data from many TRBs, or many USB 
packets may be
required to transfer a single TRB.
Note: No relationship is assumed between USB packet boundaries and TRB data buffer 
boundaries."

Is the case here that a TRB Length field of a Scatter/Father is less than max 
packet size,
or just not aligned with max packet size boundaries?

Is it possible this is about TD fragments? xhci has some requirements on how TDs
should be fragmented, it's possible the driver doesn't live up to all these 
requirements.

See xhci specs section 4.11.7.1, TD Fragments
  
I need to dig into this after the holidays,

I'll be back 7 January 2016.

Don't be afraid to ping me about this issue after that.

-Mathias  
--

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

[PATCH 3/4] USB: host: use to_platform_device

[Geliang Tang]

Use to_platform_device() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/usb/host/ehci-platform.c | 6 ++
 drivers/usb/host/ehci-st.c   | 6 ++
 drivers/usb/host/ohci-platform.c | 6 ++
 drivers/usb/host/ohci-st.c   | 6 ++
 4 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index bd7082f2..1757ebb 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -345,8 +345,7 @@ static int ehci_platform_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int ret;
 
@@ -364,8 +363,7 @@ static int ehci_platform_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
 
if (pdata->power_on) {
diff --git a/drivers/usb/host/ehci-st.c b/drivers/usb/host/ehci-st.c
index b7c5cfa..a94ed67 100644
--- a/drivers/usb/host/ehci-st.c
+++ b/drivers/usb/host/ehci-st.c
@@ -287,8 +287,7 @@ static int st_ehci_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int ret;
 
@@ -308,8 +307,7 @@ static int st_ehci_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
int err;
 
pinctrl_pm_select_default_state(dev);
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index c2669f18..ae1c988 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -310,8 +310,7 @@ static int ohci_platform_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev->platform_data;
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int ret;
 
@@ -329,8 +328,7 @@ static int ohci_platform_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(dev);
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
 
if (pdata->power_on) {
int err = pdata->power_on(pdev);
diff --git a/drivers/usb/host/ohci-st.c b/drivers/usb/host/ohci-st.c
index df9028e..acf2eb2 100644
--- a/drivers/usb/host/ohci-st.c
+++ b/drivers/usb/host/ohci-st.c
@@ -270,8 +270,7 @@ static int st_ohci_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev->platform_data;
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
bool do_wakeup = device_may_wakeup(dev);
int ret;
 
@@ -289,8 +288,7 @@ static int st_ohci_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(dev);
-   struct platform_device *pdev =
-   container_of(dev, struct platform_device, dev);
+   struct platform_device *pdev = to_platform_device(dev);
int err;
 
if (pdata->power_on) {
-- 
2.5.0


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

[PATCH 1/4] USB: core, devio: use to_usb_device

[Geliang Tang]

Use to_usb_device() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/usb/core/devio.c | 2 +-
 drivers/usb/core/usb.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 59e7a33..c47d36a 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -848,7 +848,7 @@ static struct usb_device *usbdev_lookup_by_devt(dev_t devt)
  (void *) (unsigned long) devt, match_devt);
if (!dev)
return NULL;
-   return container_of(dev, struct usb_device, dev);
+   return to_usb_device(dev);
 }
 
 /*
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 77e4c9b..f25de6c 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -241,7 +241,7 @@ static int __each_dev(struct device *dev, void *data)
if (!is_usb_device(dev))
return 0;
 
-   return arg->fn(container_of(dev, struct usb_device, dev), arg->data);
+   return arg->fn(to_usb_device(dev), arg->data);
 }
 
 /**
-- 
2.5.0


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

[PATCH 2/4] USB: core, wusbcore: use bus_to_hcd

[Geliang Tang]

Use bus_to_hcd() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/usb/core/hcd.c| 6 +++---
 drivers/usb/core/hub.c| 2 +-
 drivers/usb/core/usb.c| 2 +-
 drivers/usb/wusbcore/wusbhc.h | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index df0e3b9..e96eddb 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2208,7 +2208,7 @@ int usb_hcd_get_frame_number (struct usb_device *udev)
 
 int hcd_bus_suspend(struct usb_device *rhdev, pm_message_t msg)
 {
-   struct usb_hcd  *hcd = container_of(rhdev->bus, struct usb_hcd, self);
+   struct usb_hcd  *hcd = bus_to_hcd(rhdev->bus);
int status;
int old_state = hcd->state;
 
@@ -2257,7 +2257,7 @@ int hcd_bus_suspend(struct usb_device *rhdev, 
pm_message_t msg)
 
 int hcd_bus_resume(struct usb_device *rhdev, pm_message_t msg)
 {
-   struct usb_hcd  *hcd = container_of(rhdev->bus, struct usb_hcd, self);
+   struct usb_hcd  *hcd = bus_to_hcd(rhdev->bus);
int status;
int old_state = hcd->state;
 
@@ -2371,7 +2371,7 @@ int usb_bus_start_enum(struct usb_bus *bus, unsigned 
port_num)
 * boards with root hubs hooked up to internal devices (instead of
 * just the OTG port) may need more attention to resetting...
 */
-   hcd = container_of (bus, struct usb_hcd, self);
+   hcd = bus_to_hcd(bus);
if (port_num && hcd->driver->start_port_reset)
status = hcd->driver->start_port_reset(hcd, port_num);
 
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 51b43691..7c4b392 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2619,7 +2619,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
struct usb_hcd *hcd;
if (hub->hdev->parent != NULL)  /* not a root hub? */
return 0;
-   hcd = container_of(hub->hdev->bus, struct usb_hcd, self);
+   hcd = bus_to_hcd(hub->hdev->bus);
return hcd->wireless;
 }
 
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index f25de6c..e0c6382 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -391,7 +391,7 @@ struct device_type usb_device_type = {
 /* Returns 1 if @usb_bus is WUSB, 0 otherwise */
 static unsigned usb_bus_is_wusb(struct usb_bus *bus)
 {
-   struct usb_hcd *hcd = container_of(bus, struct usb_hcd, self);
+   struct usb_hcd *hcd = bus_to_hcd(bus);
return hcd->wireless;
 }
 
diff --git a/drivers/usb/wusbcore/wusbhc.h b/drivers/usb/wusbcore/wusbhc.h
index 41838db..8c5bd00 100644
--- a/drivers/usb/wusbcore/wusbhc.h
+++ b/drivers/usb/wusbcore/wusbhc.h
@@ -336,7 +336,7 @@ static inline
 struct usb_hcd *usb_hcd_get_by_usb_dev(struct usb_device *usb_dev)
 {
struct usb_hcd *usb_hcd;
-   usb_hcd = container_of(usb_dev->bus, struct usb_hcd, self);
+   usb_hcd = bus_to_hcd(usb_dev->bus);
return usb_get_hcd(usb_hcd);
 }
 
-- 
2.5.0


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

[PATCH 8/9 v2] usb: gadget: rndis: use list_for_each_entry_safe

[Geliang Tang]

Use list_for_each_entry_safe() instead of list_for_each_safe() to
simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/usb/gadget/function/rndis.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/function/rndis.c 
b/drivers/usb/gadget/function/rndis.c
index 70d3917..13280f5 100644
--- a/drivers/usb/gadget/function/rndis.c
+++ b/drivers/usb/gadget/function/rndis.c
@@ -1006,12 +1006,9 @@ EXPORT_SYMBOL_GPL(rndis_add_hdr);
 
 void rndis_free_response(struct rndis_params *params, u8 *buf)
 {
-   rndis_resp_t *r;
-   struct list_head *act, *tmp;
+   rndis_resp_t *r, *n;
 
-   list_for_each_safe(act, tmp, &(params->resp_queue))
-   {
-   r = list_entry(act, rndis_resp_t, list);
+   list_for_each_entry_safe(r, n, >resp_queue, list) {
if (r && r->buf == buf) {
list_del(>list);
kfree(r);
@@ -1022,14 +1019,11 @@ EXPORT_SYMBOL_GPL(rndis_free_response);
 
 u8 *rndis_get_next_response(struct rndis_params *params, u32 *length)
 {
-   rndis_resp_t *r;
-   struct list_head *act, *tmp;
+   rndis_resp_t *r, *n;
 
if (!length) return NULL;
 
-   list_for_each_safe(act, tmp, &(params->resp_queue))
-   {
-   r = list_entry(act, rndis_resp_t, list);
+   list_for_each_entry_safe(r, n, >resp_queue, list) {
if (!r->send) {
r->send = 1;
*length = r->length;
-- 
2.5.0


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

[PATCH 4/4] HID: usbhid: use to_usb_device

[Geliang Tang]

Use to_usb_device() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/hid/usbhid/usbhid.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/usbhid/usbhid.h b/drivers/hid/usbhid/usbhid.h
index 807922b..fa47d66 100644
--- a/drivers/hid/usbhid/usbhid.h
+++ b/drivers/hid/usbhid/usbhid.h
@@ -96,7 +96,7 @@ struct usbhid_device {
 };
 
 #definehid_to_usb_dev(hid_dev) \
-   container_of(hid_dev->dev.parent->parent, struct usb_device, dev)
+   to_usb_device(hid_dev->dev.parent->parent)
 
 #endif
 
-- 
2.5.0


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

Re: xhci list corruption on sysfs removal

[Joe Lawrence]

On 12/21/2015 10:07 AM, Mathias Nyman wrote:

Hi

On 18.12.2015 18:48, Joe Lawrence wrote:

Hello Roger and Mathias,

Running with slub_debug=FZPU and removing an XHCI host controller via
sysfs, I've hit a use-after-free that I've bisected to:

   8c24d6d7b09deee3036ddc4f2b81b53b28c8f877 is the first bad commit
   commit 8c24d6d7b09deee3036ddc4f2b81b53b28c8f877

...


If I revert 8c24d6d7b09d "usb: xhci: stop everything on the first call
to xhci_stop", the warning goes away.

Let me know if any additional instrumentation or information would help
track down this issue.



Thanks for the in-depth analysis.

Seems that the problem is that xhci driver frees data for all devices, both
usb2 and and usb3 the first time  usb_remove_hcd() is called.

All data includes the all devices all endpoints and endpoint rings,
including the
the td_list in the xhci_ring struct.

When we call usb_remove_hcd() a second time for the second xhci bus, as
part of
usb_hcd_pci_remove() in xhci_pci_remove() it will try to dequeue all
pending urbs,
but td_list is already freed for that endpoint ring.

before commit 8c24d6d7b09d we only halted xhci when first hcd was removed,
devices were freed only after second hcd removal.

we will also free xhci->devs[slot_id] and set it to null after freeing
the endpoint rings,
so something like this should work in this case (copypaste of git diff):

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3f91270..dfc11d0 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1549,7 +1549,9 @@ int xhci_urb_dequeue(struct usb_hcd *hcd, struct
urb *urb, int status)
 xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
 "HW died, freeing TD.");
 urb_priv = urb->hcpriv;
-   for (i = urb_priv->td_cnt; i < urb_priv->length; i++) {
+   for (i = urb_priv->td_cnt;
+i < urb_priv->length && xhci->devs[urb->dev->slot_id];
+i++) {
 td = urb_priv->td[i];
 if (!list_empty(>td_list))
 list_del_init(>td_list);

There might be other similar cases caused by commit 8c24d6d7b09d.
This whole issue  probably needs more attention.


Hi Mathias,

Thanks for taking a look.  I applied these changes on top of 4.3 and 
didn't see any further slub_debug complaints on sysfs or hotplug removal 
during overnight testing. :)  Feel free to add my Reported-by or 
Tested-by tag.


Regards,

-- Joe
--
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

[GIT PULL] USB patches for v4.5

[Felipe Balbi]

Hi Greg,

Here's the large usb gadget pull request for v4.5. Please consider
merging it to your usb-next branch. We have a total 97 non-merge commits
this time, so a substantial amount of code. Here's a dirstat to show you
where most of changes are:

$ git diff --dirstat 9f9499ae8e64
  22.5% drivers/usb/dwc2/
   8.7% drivers/usb/dwc3/
   9.5% drivers/usb/gadget/function/
  35.9% drivers/usb/gadget/udc/
   6.2% drivers/usb/phy/
   5.0% drivers/usb/renesas_usbhs/
   7.2% drivers/usb/
   
The following changes since commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89:

  Linux 4.4-rc5 (2015-12-13 17:42:58 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v4.5

for you to fetch changes up to 5072cfc40a80cea3749fd3413b3896630d8c787e:

  usb: dwc3: of-simple: fix build warning on !PM (2015-12-22 21:58:26 -0600)


usb: patches for v4.5

A ton of improvements to dwc2 have been made. The
driver should be a lot more stable on v4.5 then ever
before.

Our good old dwc3 got a few cleanups and misc fixes
and also added support to Xilinx's integration of
this IP.

Yoshihiro Shimoda gives us support for a new USB3
peripheral controller from Renesas.

Other than these, the usual misc fixes all over the
place.


Baolin Wang (1):
  usb: gadget: Add the console support for usb-to-serial port

Bin Liu (3):
  usb: of: add an api to get dr_mode by the phy node
  usb: phy: correct the am335x phy header filename
  usb: phy: phy-am335x: bypass first VBUS sensing for host-only mode

David Eccher (1):
  usb: gadget: inode.c: fix unbalanced spin_lock in ep0_write

Deepa Dinamani (1):
  usb: misc: usbtest: Remove timeval usage

Douglas Anderson (8):
  usb: dwc2: host: Fix missing device insertions
  usb: dwc2: host: Support immediate retries for split transactions
  usb: dwc2: host: Add missing spinlock in dwc2_hcd_reset_func()
  usb: dwc2: host: Clear interrupts before handling them
  usb: dwc2: Restore GUSBCFG in dwc2_get_hwparams()
  usb: dwc2: Avoid double-reset at boot time
  usb: dwc2: Speed dwc2_get_hwparams() on some host-only ports
  usb: dwc2: Avoid more calls to dwc2_core_reset()

Du, Changbin (2):
  usb: dwc2: fix transfer stop programming for out endpoint
  usb: gadget: forbid queuing request to a disabled ep

Felipe Balbi (13):
  usb: dwc3: gadget: simplify dwc3_gadget_ep_queue()
  usb: dwc3: gadget: purge dev_dbg() calls
  usb: dwc3: core: purge dev_dbg() calls
  usb: dwc3: ep0: purge dev_dbg() calls
  usb: dwc3: gadget: simplify next_request() return check
  usb: dwc3: ep0: fix setup_packet_pending initialization
  usb: dwc3: add generic OF glue layer
  usb: dwc3: remove dwc3-qcom in favor of dwc3-of-simple
  usb: dwc3: gadget: handle request->zero
  usb: dwc3: trace: show request flags
  usb: dwc3: gadget: pass a condition to dev_WARN_ONCE()
  usb: of: fix build breakage on !OF
  usb: dwc3: of-simple: fix build warning on !PM

Felipe F. Tonello (6):
  usb: gadget: f_midi: remove duplicated code
  usb: gadget: define free_ep_req as universal function
  usb: gadget: gmidi: Cleanup legacy code
  usb: gadget: f_midi: set altsettings only for MIDIStreaming interface
  usb: gadget: f_midi: fail if set_alt fails to allocate requests
  usb: gadget: f_midi: pre-allocate IN requests

Geert Uytterhoeven (1):
  usb: phy: Remove unused Renesas R-Car (Gen1) USB PHY driver

Geliang Tang (1):
  usb: gadget: bcm63xx_udc: use list_for_each_entry_safe

Geyslan G. Bem (2):
  usb: gadget: s3c-hsudc: remove redundant condition
  usb: musb: gadget: remove redundant condition

Gregory Herrero (12):
  usb: dwc2: host: ensure filling of isoc desc is correctly done
  usb: dwc2: host: set active bit in isochronous descriptors
  usb: dwc2: host: rework isochronous halt path
  usb: dwc2: host: fix use of qtd after free in desc dma mode
  usb: dwc2: host: spinlock release channel
  usb: dwc2: host: add function to compare frame index
  usb: dwc2: host: program descriptor for next frame
  usb: dwc2: host: always increment available host channel during release
  usb: dwc2: host: process all completed urbs
  usb: dwc2: host: avoid usage of dma_alloc_coherent with irqs disabled
  usb: dwc2: host: use kmem cache to allocate descriptors
  usb: dwc2: gadget: don't overwrite DCTL register on NAKEFF interrupts

Heiko Stübner (1):
  usb: dwc2: add shutdown callback to platform variant

Igor Kotrasinski (1):
  usb: gadget: composite: remove redundant bcdUSB setting in legacy

John Youn (15):
  usb: dwc2: Reorder AHBIDLE and CSFTRST in dwc2_core_reset()
  usb: dwc2: Rename dwc2_core_reset()
  usb: dwc2: Add dwc2_core_reset()
  

RE: [PATCH 0/7][v4] Add OTG support for FSL socs

[Jun Li]

> -Original Message-
> From: Ramneek Mehresh [mailto:ramneek.mehr...@freescale.com]
> Sent: Wednesday, December 23, 2015 8:20 PM
> To: Jun Li ; Felipe Balbi ; linux-
> ker...@vger.kernel.org
> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org
> Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> 
> 
> 
> > -Original Message-
> > From: Jun Li [mailto:jun...@nxp.com]
> > Sent: Wednesday, December 23, 2015 10:36 AM
> > To: Felipe Balbi ; Mehresh Ramneek-B31383
> > ; linux-ker...@vger.kernel.org
> > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > u...@vger.kernel.org
> > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> >
> > Hi
> >
> > > -Original Message-
> > > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> > > ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> > > Sent: Wednesday, December 23, 2015 2:21 AM
> > > To: Ramneek Mehresh ; linux-
> > > ker...@vger.kernel.org
> > > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > > u...@vger.kernel.org
> > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> > >
> > >
> > > Hi,
> > >
> > > Ramneek Mehresh  writes:
> > > >> -Original Message-
> > > >> From: Felipe Balbi [mailto:ba...@ti.com]
> > > >> Sent: Saturday, October 10, 2015 3:04 AM
> > > >> To: Mehresh Ramneek-B31383 ;
> > linux-
> > > >> ker...@vger.kernel.org
> > > >> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > > >> u...@vger.kernel.org; Mehresh Ramneek-B31383
> > > >> 
> > > >> Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs
> > > >>
> > > >> Felipe Balbi  writes:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > Ramneek Mehresh  writes:
> > > >> >> Add support for otg for all freescale socs having internal usb
> phy.
> > > >> >>
> > > >> >> Ramneek Mehresh (7):
> > > >> >>   usb:fsl:otg: Make fsl otg driver as tristate
> > > >> >>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
> > > >> >>   usb:fsl:otg: Add support to add/remove usb host driver
> > > >> >>   usb:fsl:otg: Signal host drv when host is otg
> > > >> >>   usb:fsl:otg: Modify otg_event to start host drv
> > > >> >>   usb:fsl:otg: Combine host/gadget start/resume for ID change
> > > >> >>   usb:fsl:otg: Add host-gadget drv sync delay
> > > >> >
> > > >> > Unless Alan's okay with the host side changes, I can't accept
> > > >> > any of these. However, I must say some of the flags you add
> > > >> > here already exist in some way, shape or form. For example,
> > > >> > look at
> > > is_b_host flag.
> > > >>
> > > >
> > > > Could you please be more specific...which flag you think that I
> > > >should remove/I'm re-defining. The flags I'm defining are:
> > > >
> > > > have_hcd : defined in fsl specific structure for fsl specific
> > > > use-case
> > > >
> > > > had_hcd: defined in fsl specific structure for fsl specific
> > > > use-case
> > > >
> > > > is_otg : defined in include/linux/usb.h
> > > >
> > > > Are you suggesting using otg_port or is_b_host instead of is_otg?
> > > >
> > > > As I understand, is_b_host is specifically to check if an otg B
> > > > device is in host mode...correct?  I just need a flag to check if
> > > > a controller is capable of otg operations? That's why defined
> "is_otg"
> > > > flag. Please suggest.
> > >
> > > no, I don't know why I made that comment. You could use otg_port,
> > > but that wouldn't look very clean. Can you resend with Alan's ack,
> > > then I'll move this series into testing/next.
> > >
> > > --
> > > balbi
> >
> > Can you directly put the change_hcd_work in its phy driver(phy-fsl-
> usb.c)?
> > Then add/remove hcd will not through ehci_fsl_drv_suspend/resume, With
> > this, you can make it work without a new flag "is_otg".
> >
> change_hcd_work() changes host controller mode, and hence, should be in
> host controller driver. 

Reasonable, but most of OTG stuff not belong to phy actully,
I see phy-msm-usb.c directly do hcd add/remove for OTG. 

> To move this to phy driver (just to avoid usage of
> a single flag) won't be a good idea.

I just saw you simply still use the suspend/resume method, but the
change_hcd_work actually has nothing to do with it now, then add a
flag to return for it, also the flag in your usage is not to indicate
if the host capable/enabled otg, but something like
is_host_role_to_be_changed_for_otg(test and then clear).

Meanwhile you add another 2 flags in ehci_fsl(have_hcd, add_hcd) also for
OTG host add/remove, so I am thinking if all those can be simplified. 

> In this case, I'll also have to move some host controller specific flags
> to phy drv which won't be correct.

> 
> > Li Jun

--
To unsubscribe from this list: send the line 

[PATCH] staging: android: sync.c: Changed the ways nullptrs were being checked

[Chase Metzger]

Removed all checkpatch.pl CHECKs that suggested to check NULL by
!obj instead of obj == NULL.

Signed-off-by: Chase Metzger 
---
 drivers/staging/android/sync.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f83e00c..5413f28 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -43,7 +43,7 @@ struct sync_timeline *sync_timeline_create(const struct 
sync_timeline_ops *ops,
return NULL;
 
obj = kzalloc(size, GFP_KERNEL);
-   if (obj == NULL)
+   if (!obj)
return NULL;
 
kref_init(>kref);
@@ -130,7 +130,7 @@ struct sync_pt *sync_pt_create(struct sync_timeline *obj, 
int size)
return NULL;
 
pt = kzalloc(size, GFP_KERNEL);
-   if (pt == NULL)
+   if (!pt)
return NULL;
 
spin_lock_irqsave(>child_list_lock, flags);
@@ -155,7 +155,7 @@ static struct sync_fence *sync_fence_alloc(int size, const 
char *name)
struct sync_fence *fence;
 
fence = kzalloc(size, GFP_KERNEL);
-   if (fence == NULL)
+   if (!fence)
return NULL;
 
fence->file = anon_inode_getfile("sync_fence", _fence_fops,
@@ -193,7 +193,7 @@ struct sync_fence *sync_fence_create(const char *name, 
struct sync_pt *pt)
struct sync_fence *fence;
 
fence = sync_fence_alloc(offsetof(struct sync_fence, cbs[1]), name);
-   if (fence == NULL)
+   if (!fence)
return NULL;
 
fence->num_fences = 1;
@@ -215,7 +215,7 @@ struct sync_fence *sync_fence_fdget(int fd)
 {
struct file *file = fget(fd);
 
-   if (file == NULL)
+   if (!file)
return NULL;
 
if (file->f_op != _fence_fops)
@@ -262,7 +262,7 @@ struct sync_fence *sync_fence_merge(const char *name,
unsigned long size = offsetof(struct sync_fence, cbs[num_fences]);
 
fence = sync_fence_alloc(size, name);
-   if (fence == NULL)
+   if (!fence)
return NULL;
 
atomic_set(>status, num_fences);
@@ -583,14 +583,14 @@ static long sync_fence_ioctl_merge(struct sync_fence 
*fence, unsigned long arg)
}
 
fence2 = sync_fence_fdget(data.fd2);
-   if (fence2 == NULL) {
+   if (!fence2) {
err = -ENOENT;
goto err_put_fd;
}
 
data.name[sizeof(data.name) - 1] = '\0';
fence3 = sync_fence_merge(data.name, fence, fence2);
-   if (fence3 == NULL) {
+   if (!fence3) {
err = -ENOMEM;
goto err_put_fence2;
}
@@ -666,7 +666,7 @@ static long sync_fence_ioctl_fence_info(struct sync_fence 
*fence,
size = 4096;
 
data = kzalloc(size, GFP_KERNEL);
-   if (data == NULL)
+   if (!data)
return -ENOMEM;
 
strlcpy(data->name, fence->name, sizeof(data->name));
-- 
2.1.4

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

RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled

[Alan Stern]

On Wed, 23 Dec 2015, Hayes Wang wrote:

> Oliver Neukum [mailto:oneu...@suse.de]
> > Sent: Wednesday, December 23, 2015 4:20 PM
> [...]
> > No, step (2) does not exist. Calls to suspend() and [reset_]resume()
> > always balance. Usually a driver shouldn't care about system suspend.
> > The way the driver is currently coded will also fail for Port-Power Off.
> 
> It is different with Windows. The Windows would resume the device before
> system suspend, if the system suspend follows the autosuspend.
> 
> Would this be a problem? After system suspend, the device may wake up
> the system when receiving any packet, not only magic packet. The wake
> events are different for system suspend and autosuspend. However, I
> couldn't change the wake event, because the autosuspend occurs first,
> and the suspend() is only called once.

I don't understand why the wakeup conditions are different.  It seems
to me that the choice of which packets will generate a wakeup ought to
depend on the user's selection, not on the kind of suspend.  For
instance, if the user says that only a magic packet should cause a
wakeup then that should be true for both runtime suspend and system
suspend.

To put it another way, as far as the device is concerned a suspend is
just a suspend -- there's no different between a runtime suspend and a
system suspend.

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: MX28 with hub cannot reset

[Peter Chen]

On Wed, Dec 23, 2015 at 08:05:13AM -0200, Fabio Estevam wrote:
> Hi Peter,
>
> On Wed, Dec 23, 2015 at 7:49 AM, Peter Chen  wrote:
>
> > Fabio, there is a bug for imx28 usb low power mode, and we have no
> > good way to implement
> > workaround using current USB PHY framework, would you please test by
> > add "usbcore.autosuspend = -1"
> > at bootargs (no CI_HDRC_SUPPORTS_RUNTIME_PM needed to set for imx28) to
> > see if this problem can fix?
>
> Excellent, passing 'usbcore.autosuspend=-1' fixes the issue!
>
> Do you think we could have a fix for mx28 so that we don't need to
> pass this option?
>

No, we don't have it now.

Felipe didn't agree to add more USB PHY interfaces to workaround
this SoC problem, and I can't find any good ways to handle it either.

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219215.html

-- 

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

Re: [PATCH net,stable] net: cdc_ncm: avoid changing RX/TX buffers on MTU changes

[David Miller]

From: Bjørn Mork 
Date: Wed, 23 Dec 2015 13:42:43 +0100

> NCM buffer sizes are negotiated with the device independently of
> the network device MTU.  The RX buffers are allocated by the
> usbnet framework based on the rx_urb_size value set by cdc_ncm. A
> single RX buffer can hold a number of MTU sized packets.
> 
> The default usbnet change_mtu ndo only modifies rx_urb_size if it
> is equal to hard_mtu.  And the cdc_ncm driver will set rx_urb_size
> and hard_mtu independently of each other, based on dwNtbInMaxSize
> and dwNtbOutMaxSize respectively. It was therefore assumed that
> usbnet_change_mtu() would never touch rx_urb_size.  This failed to
> consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens
> to be equal.
> 
> Fix by implementing an NCM specific change_mtu ndo, modifying the
> netdev MTU without touching the buffer size settings.
> 
> Signed-off-by: Bjørn Mork 

Applied and queued up for -stable, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/23/2015 05:17 AM, Chanwoo Choi wrote:


This patch depend on GPIOLIB configuration as following:
I modified it with following diff and applied it.

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index ba4db7d..3d89e60 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -54,6 +54,7 @@ config EXTCON_MAX14577

 config EXTCON_MAX3355
tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   depends on GPIOLIB || COMPILE_TEST


  If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST?
  And no, it shouldn't depend on gpiolib. It has empty stubs for the case 
of CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll 
look into it.


Yes. When GPIOLIB is disabled, the build issue don't happen.


 What? It surely does happen!


hmm
Sure. you need to check the include/linux/gpio/consumer.h.

Because of build error happen, you miss to include the "linux/gpio/consumer.h"
header file in extcon-max3355.c. Please test it for enough time.


Yes, with this file #include'd, it build fine now.


because include/linux/gpio/consumer.h implement the dummy function
for all gpio functions if CONFIG_GPIOLIB is disabled.


 Linus W. advised to #include this header explicitly -- I'll try and post.


Don't necessary. I already updated it including the 
"include/linux/gpio/consumer.h".


I saw that, yes.


For correct operation of max3355, you should add the dependency
to the extcon-max3355.c driver. This driver use the GPIO library
certainly.


 I disagree. The driver will just cease to load in this case. I don't see 
why we need such dependency. Only compilation time dependencies should be
specified, I think.


This driver have to depend on GPIOLIB.
Why are you disagreeing the COMPILE_TEST dependency? It is just compile test
without anything.


I agree now. I still disagree about the gpiolib dependency though.


If gpiolib is disabled, extcon-max3355.c might not operate it correctly.


   It'll just fail the probe, that's all.


Just this driver could be built without operation because gpiolib function
will not do the any behavior.


   devm_gpiod_get() will just fail with -ENOSYS.


I think that it is not too much problem. I should send the pull request within 
this week.
If you want to need more discussion of extcon-max3355.c,
I will not include it on pull request for v4.5 because there is issue.


   No, please include it into the pull request.

MBR, Sergei

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

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
>> Running status is feature.
>
>What do you mean by that?

That this behavior is intended, and required.

> I don't qualify writing a *wrong* MIDI-USB
>packet because of a previous MIDI message as a feature.

The MIDI Specification qualifies Running Status as a feature.


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: [PATCH 0/7][v4] Add OTG support for FSL socs

[Ramneek Mehresh]

> -Original Message-
> From: Jun Li [mailto:jun...@nxp.com]
> Sent: Wednesday, December 23, 2015 10:02 PM
> To: Mehresh Ramneek-B31383 ; Felipe
> Balbi ; linux-ker...@vger.kernel.org
> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org
> Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> 
> 
> 
> > -Original Message-
> > From: Ramneek Mehresh [mailto:ramneek.mehr...@freescale.com]
> > Sent: Wednesday, December 23, 2015 8:20 PM
> > To: Jun Li ; Felipe Balbi ; linux-
> > ker...@vger.kernel.org
> > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > u...@vger.kernel.org
> > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> >
> >
> >
> > > -Original Message-
> > > From: Jun Li [mailto:jun...@nxp.com]
> > > Sent: Wednesday, December 23, 2015 10:36 AM
> > > To: Felipe Balbi ; Mehresh Ramneek-B31383
> > > ; linux-ker...@vger.kernel.org
> > > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > > u...@vger.kernel.org
> > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> > >
> > > Hi
> > >
> > > > -Original Message-
> > > > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> > > > ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> > > > Sent: Wednesday, December 23, 2015 2:21 AM
> > > > To: Ramneek Mehresh ; linux-
> > > > ker...@vger.kernel.org
> > > > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > > > u...@vger.kernel.org
> > > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Ramneek Mehresh  writes:
> > > > >> -Original Message-
> > > > >> From: Felipe Balbi [mailto:ba...@ti.com]
> > > > >> Sent: Saturday, October 10, 2015 3:04 AM
> > > > >> To: Mehresh Ramneek-B31383
> ;
> > > linux-
> > > > >> ker...@vger.kernel.org
> > > > >> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org;
> > > > >> linux- u...@vger.kernel.org; Mehresh Ramneek-B31383
> > > > >> 
> > > > >> Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs
> > > > >>
> > > > >> Felipe Balbi  writes:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > Ramneek Mehresh  writes:
> > > > >> >> Add support for otg for all freescale socs having internal
> > > > >> >> usb
> > phy.
> > > > >> >>
> > > > >> >> Ramneek Mehresh (7):
> > > > >> >>   usb:fsl:otg: Make fsl otg driver as tristate
> > > > >> >>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
> > > > >> >>   usb:fsl:otg: Add support to add/remove usb host driver
> > > > >> >>   usb:fsl:otg: Signal host drv when host is otg
> > > > >> >>   usb:fsl:otg: Modify otg_event to start host drv
> > > > >> >>   usb:fsl:otg: Combine host/gadget start/resume for ID change
> > > > >> >>   usb:fsl:otg: Add host-gadget drv sync delay
> > > > >> >
> > > > >> > Unless Alan's okay with the host side changes, I can't accept
> > > > >> > any of these. However, I must say some of the flags you add
> > > > >> > here already exist in some way, shape or form. For example,
> > > > >> > look at
> > > > is_b_host flag.
> > > > >>
> > > > >
> > > > > Could you please be more specific...which flag you think that I
> > > > >should remove/I'm re-defining. The flags I'm defining are:
> > > > >
> > > > > have_hcd : defined in fsl specific structure for fsl specific
> > > > > use-case
> > > > >
> > > > > had_hcd: defined in fsl specific structure for fsl specific
> > > > > use-case
> > > > >
> > > > > is_otg : defined in include/linux/usb.h
> > > > >
> > > > > Are you suggesting using otg_port or is_b_host instead of is_otg?
> > > > >
> > > > > As I understand, is_b_host is specifically to check if an otg B
> > > > > device is in host mode...correct?  I just need a flag to check
> > > > > if a controller is capable of otg operations? That's why defined
> > "is_otg"
> > > > > flag. Please suggest.
> > > >
> > > > no, I don't know why I made that comment. You could use otg_port,
> > > > but that wouldn't look very clean. Can you resend with Alan's ack,
> > > > then I'll move this series into testing/next.
> > > >
> > > > --
> > > > balbi
> > >
> > > Can you directly put the change_hcd_work in its phy driver(phy-fsl-
> > usb.c)?
> > > Then add/remove hcd will not through ehci_fsl_drv_suspend/resume,
> > > With this, you can make it work without a new flag "is_otg".
> > >
> > change_hcd_work() changes host controller mode, and hence, should be
> > in host controller driver.
> 
> Reasonable, but most of OTG stuff not belong to phy actully, I see phy-msm-
> usb.c directly do hcd add/remove for OTG.
> 
Thanks for your input...but I still strongly believe that controller specific 
data structure and flags

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

[Oliver Neukum]

On Wed, 2015-12-23 at 20:32 -0500, Alan Stern wrote:

> I don't understand why the wakeup conditions are different.  It seems
> to me that the choice of which packets will generate a wakeup ought to
> depend on the user's selection, not on the kind of suspend.  For
> instance, if the user says that only a magic packet should cause a
> wakeup then that should be true for both runtime suspend and system
> suspend.
> 
> To put it another way, as far as the device is concerned a suspend is
> just a suspend -- there's no different between a runtime suspend and a
> system suspend.

This literally true, but the host and the driver care.
If we autosuspend a running network device, any packet
(maybe filtered for MAC) should cause a remote wake up,
else we'd lose packets.

But you cannot keep that setting if the system goes down
or any broadcast packet would resume the whole system.
Yet you cannot just disable remote wake up, as WoL packages
still must trigger a remote wake up.
So there are drivers which must change settings on devices
as the system goes to sleep, even if their devices have
already been autosuspended. We could use the notifier chains
for that. But can this solution be called elegant?

Merry Christmas
Oliver



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

RE: [PATCH 0/7][v4] Add OTG support for FSL socs

[Ramneek Mehresh]

> -Original Message-
> From: Jun Li [mailto:jun...@nxp.com]
> Sent: Wednesday, December 23, 2015 10:36 AM
> To: Felipe Balbi ; Mehresh Ramneek-B31383
> ; linux-ker...@vger.kernel.org
> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org
> Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> 
> Hi
> 
> > -Original Message-
> > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> > ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> > Sent: Wednesday, December 23, 2015 2:21 AM
> > To: Ramneek Mehresh ; linux-
> > ker...@vger.kernel.org
> > Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > u...@vger.kernel.org
> > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> >
> >
> > Hi,
> >
> > Ramneek Mehresh  writes:
> > >> -Original Message-
> > >> From: Felipe Balbi [mailto:ba...@ti.com]
> > >> Sent: Saturday, October 10, 2015 3:04 AM
> > >> To: Mehresh Ramneek-B31383 ;
> linux-
> > >> ker...@vger.kernel.org
> > >> Cc: st...@rowland.harvard.edu; gre...@linuxfoundation.org; linux-
> > >> u...@vger.kernel.org; Mehresh Ramneek-B31383
> > >> 
> > >> Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs
> > >>
> > >> Felipe Balbi  writes:
> > >>
> > >> > Hi,
> > >> >
> > >> > Ramneek Mehresh  writes:
> > >> >> Add support for otg for all freescale socs having internal usb phy.
> > >> >>
> > >> >> Ramneek Mehresh (7):
> > >> >>   usb:fsl:otg: Make fsl otg driver as tristate
> > >> >>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
> > >> >>   usb:fsl:otg: Add support to add/remove usb host driver
> > >> >>   usb:fsl:otg: Signal host drv when host is otg
> > >> >>   usb:fsl:otg: Modify otg_event to start host drv
> > >> >>   usb:fsl:otg: Combine host/gadget start/resume for ID change
> > >> >>   usb:fsl:otg: Add host-gadget drv sync delay
> > >> >
> > >> > Unless Alan's okay with the host side changes, I can't accept any
> > >> > of these. However, I must say some of the flags you add here
> > >> > already exist in some way, shape or form. For example, look at
> > is_b_host flag.
> > >>
> > >
> > > Could you please be more specific...which flag you think that I
> > >should remove/I'm re-defining. The flags I'm defining are:
> > >
> > > have_hcd : defined in fsl specific structure for fsl specific
> > > use-case
> > >
> > > had_hcd: defined in fsl specific structure for fsl specific use-case
> > >
> > > is_otg : defined in include/linux/usb.h
> > >
> > > Are you suggesting using otg_port or is_b_host instead of is_otg?
> > >
> > > As I understand, is_b_host is specifically to check if an otg B
> > > device is in host mode...correct?  I just need a flag to check if a
> > > controller is capable of otg operations? That's why defined "is_otg"
> > > flag. Please suggest.
> >
> > no, I don't know why I made that comment. You could use otg_port, but
> > that wouldn't look very clean. Can you resend with Alan's ack, then
> > I'll move this series into testing/next.
> >
> > --
> > balbi
> 
> Can you directly put the change_hcd_work in its phy driver(phy-fsl-usb.c)?
> Then add/remove hcd will not through ehci_fsl_drv_suspend/resume, With
> this, you can make it work without a new flag "is_otg".
> 
change_hcd_work() changes host controller mode, and hence, should be in host 
controller
driver. To move this to phy driver (just to avoid usage of a single flag) won't 
be a good idea.
In this case, I'll also have to move some host controller specific flags to phy 
drv which won't be correct.

> Li Jun

--
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 net,stable] net: cdc_ncm: avoid changing RX/TX buffers on MTU changes

[Bjørn Mork]

NCM buffer sizes are negotiated with the device independently of
the network device MTU.  The RX buffers are allocated by the
usbnet framework based on the rx_urb_size value set by cdc_ncm. A
single RX buffer can hold a number of MTU sized packets.

The default usbnet change_mtu ndo only modifies rx_urb_size if it
is equal to hard_mtu.  And the cdc_ncm driver will set rx_urb_size
and hard_mtu independently of each other, based on dwNtbInMaxSize
and dwNtbOutMaxSize respectively. It was therefore assumed that
usbnet_change_mtu() would never touch rx_urb_size.  This failed to
consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens
to be equal.

Fix by implementing an NCM specific change_mtu ndo, modifying the
netdev MTU without touching the buffer size settings.

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/cdc_mbim.c  |  2 +-
 drivers/net/usb/cdc_ncm.c   | 31 +++
 include/linux/usb/cdc_ncm.h |  1 +
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 190f8d935da4..980789503f7b 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -100,7 +100,7 @@ static const struct net_device_ops cdc_mbim_netdev_ops = {
.ndo_stop = usbnet_stop,
.ndo_start_xmit   = usbnet_start_xmit,
.ndo_tx_timeout   = usbnet_tx_timeout,
-   .ndo_change_mtu   = usbnet_change_mtu,
+   .ndo_change_mtu   = cdc_ncm_change_mtu,
.ndo_set_mac_address  = eth_mac_addr,
.ndo_validate_addr= eth_validate_addr,
.ndo_vlan_rx_add_vid  = cdc_mbim_rx_add_vid,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index c48c7f8ca727..b6433fdebbb6 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -732,6 +733,33 @@ static void cdc_ncm_free(struct cdc_ncm_ctx *ctx)
kfree(ctx);
 }
 
+/* we need to override the usbnet change_mtu ndo for two reasons:
+ *  - respect the negotiated maximum datagram size
+ *  - avoid unwanted changes to rx and tx buffers
+ */
+int cdc_ncm_change_mtu(struct net_device *net, int new_mtu)
+{
+   struct usbnet *dev = netdev_priv(net);
+   struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
+   int maxmtu = ctx->max_datagram_size - cdc_ncm_eth_hlen(dev);
+
+   if (new_mtu <= 0 || new_mtu > maxmtu)
+   return -EINVAL;
+   net->mtu = new_mtu;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(cdc_ncm_change_mtu);
+
+static const struct net_device_ops cdc_ncm_netdev_ops = {
+   .ndo_open= usbnet_open,
+   .ndo_stop= usbnet_stop,
+   .ndo_start_xmit  = usbnet_start_xmit,
+   .ndo_tx_timeout  = usbnet_tx_timeout,
+   .ndo_change_mtu  = cdc_ncm_change_mtu,
+   .ndo_set_mac_address = eth_mac_addr,
+   .ndo_validate_addr   = eth_validate_addr,
+};
+
 int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 
data_altsetting, int drvflags)
 {
struct cdc_ncm_ctx *ctx;
@@ -866,6 +894,9 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
/* add our sysfs attrs */
dev->net->sysfs_groups[0] = _ncm_sysfs_attr_group;
 
+   /* must handle MTU changes */
+   dev->net->netdev_ops = _ncm_netdev_ops;
+
return 0;
 
 error2:
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 1f6526c76ee8..3a375d07d0dc 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -138,6 +138,7 @@ struct cdc_ncm_ctx {
 };
 
 u8 cdc_ncm_select_altsetting(struct usb_interface *intf);
+int cdc_ncm_change_mtu(struct net_device *net, int new_mtu);
 int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 
data_altsetting, int drvflags);
 void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf);
 struct sk_buff *cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, 
__le32 sign);
-- 
2.1.4

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

[PATCH v2] usb: gadget: f_midi: refactor state machine

[Felipe F. Tonello]

This refactor results in a cleaner state machine code and as a result fixed a
bug when packaging a MIDI-USB packet right after a non-conformant MIDI byte 
stream.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 205 +--
 1 file changed, 124 insertions(+), 81 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index fb1fe96d3215..ab0fbeb3ee39 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -50,6 +50,19 @@ static const char f_midi_longname[] = "MIDI Gadget";
  */
 #define MAX_PORTS 16
 
+/* MIDI message states */
+enum {
+   STATE_INITIAL = 0,  /* pseudo state */
+   STATE_1PARAM,
+   STATE_2PARAM_1,
+   STATE_2PARAM_2,
+   STATE_SYSEX_0,
+   STATE_SYSEX_1,
+   STATE_SYSEX_2,
+   STATE_REAL_TIME,
+   STATE_FINISHED, /* pseudo state */
+};
+
 /*
  * This is a gadget, and the IN/OUT naming is from the host's perspective.
  * USB -> OUT endpoint -> rawmidi
@@ -60,13 +73,6 @@ struct gmidi_in_port {
int active;
uint8_t cable;
uint8_t state;
-#define STATE_UNKNOWN  0
-#define STATE_1PARAM   1
-#define STATE_2PARAM_1 2
-#define STATE_2PARAM_2 3
-#define STATE_SYSEX_0  4
-#define STATE_SYSEX_1  5
-#define STATE_SYSEX_2  6
uint8_t data[2];
 };
 
@@ -400,118 +406,155 @@ static int f_midi_snd_free(struct snd_device *device)
return 0;
 }
 
-static void f_midi_transmit_packet(struct usb_request *req, uint8_t p0,
-   uint8_t p1, uint8_t p2, uint8_t p3)
-{
-   unsigned length = req->length;
-   u8 *buf = (u8 *)req->buf + length;
-
-   buf[0] = p0;
-   buf[1] = p1;
-   buf[2] = p2;
-   buf[3] = p3;
-   req->length = length + 4;
-}
-
 /*
  * Converts MIDI commands to USB MIDI packets.
  */
 static void f_midi_transmit_byte(struct usb_request *req,
 struct gmidi_in_port *port, uint8_t b)
 {
-   uint8_t p0 = port->cable << 4;
+   uint8_t p[4] = { port->cable << 4, 0, 0, 0 };
+   uint8_t next_state = STATE_INITIAL;
 
if (b >= 0xf8) {
-   f_midi_transmit_packet(req, p0 | 0x0f, b, 0, 0);
+   /* System Real-Time Messages */
+   p[0] |= 0x0f;
+   p[1] = b;
+   next_state = port->state;
+   port->state = STATE_REAL_TIME;
} else if (b >= 0xf0) {
+   /* System Common Messages */
+   port->data[0] = port->data[1] = 0;
switch (b) {
case 0xf0:
port->data[0] = b;
-   port->state = STATE_SYSEX_1;
+   next_state = STATE_SYSEX_1;
break;
case 0xf1:
case 0xf3:
port->data[0] = b;
-   port->state = STATE_1PARAM;
+   next_state = STATE_1PARAM;
break;
case 0xf2:
port->data[0] = b;
-   port->state = STATE_2PARAM_1;
+   next_state = STATE_2PARAM_1;
break;
case 0xf4:
case 0xf5:
-   port->state = STATE_UNKNOWN;
+   next_state = STATE_INITIAL;
break;
case 0xf6:
-   f_midi_transmit_packet(req, p0 | 0x05, 0xf6, 0, 0);
-   port->state = STATE_UNKNOWN;
-   break;
-   case 0xf7:
-   switch (port->state) {
-   case STATE_SYSEX_0:
-   f_midi_transmit_packet(req,
-   p0 | 0x05, 0xf7, 0, 0);
-   break;
-   case STATE_SYSEX_1:
-   f_midi_transmit_packet(req,
-   p0 | 0x06, port->data[0], 0xf7, 0);
-   break;
-   case STATE_SYSEX_2:
-   f_midi_transmit_packet(req,
-   p0 | 0x07, port->data[0],
-   port->data[1], 0xf7);
-   break;
-   }
-   port->state = STATE_UNKNOWN;
+   p[0] |= 0x05;
+   p[1] = 0xf6;
+   next_state = STATE_FINISHED;
break;
}
} else if (b >= 0x80) {
+   /*
+* Channel Voice Messages, Channel Mode Messages
+* and Control Change Messages.
+*/
port->data[0] = b;
+   port->data[1] = 0;
if (b >= 0xc0 && b <= 0xdf)
-  

Re: [PATCH v2] r8152: fix lockup when runtime PM is enabled

[Oliver Neukum]

On Wed, 2015-12-23 at 09:20 +, Hayes Wang wrote:
> Oliver Neukum [mailto:oneu...@suse.de]
> > Sent: Wednesday, December 23, 2015 4:20 PM
> [...]
> > No, step (2) does not exist. Calls to suspend() and [reset_]resume()
> > always balance. Usually a driver shouldn't care about system suspend.
> > The way the driver is currently coded will also fail for Port-Power Off.
> 
> It is different with Windows. The Windows would resume the device before
> system suspend, if the system suspend follows the autosuspend.
> 
> Would this be a problem? After system suspend, the device may wake up
> the system when receiving any packet, not only magic packet. The wake
> events are different for system suspend and autosuspend. However, I
> couldn't change the wake event, because the autosuspend occurs first,
> and the suspend() is only called once.

That is indeed a problem and I need to think a bit about finding
a good solution. If you are happy with an inelegant solution, you can
use a pm_notifier, which will tell you that the system is going
to suspend. This is documented:

https://www.kernel.org/doc/Documentation/power/notifiers.txt

HTH
Oliver


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

RE: [PATCH v2] r8152: fix lockup when runtime PM is enabled

[Hayes Wang]

Oliver Neukum [mailto:oneu...@suse.com]
> Sent: Wednesday, December 23, 2015 6:46 PM
[...]
> That is indeed a problem and I need to think a bit about finding
> a good solution. If you are happy with an inelegant solution, you can
> use a pm_notifier, which will tell you that the system is going
> to suspend. This is documented:
> 
> https://www.kernel.org/doc/Documentation/power/notifiers.txt

Thanks. I would study it after fixing the reset_resume() issue.

Best Regards,
Hayes

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

Re: [PATCH 1/2] usb: gadget: f_midi: refactor state machine

[Felipe Ferreri Tonello]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Balbi,

On 22/12/15 17:49, Felipe Balbi wrote:
> 
> Hi,
> 
> "Felipe F. Tonello"  writes:
>> This refactor includes the following: * Cleaner state machine
>> code; * Reset state if MIDI message parsed is non-conformant; *
>> Fixed bug when a conformant MIDI message was followed by a
>> non-conformant causing the MIDI-USB message to use old temporary
>> data (port->data[0..1]), thus packing a wrong MIDI-USB request.
> 
> we don't do more than one logical thing per patch. Please split
> this up.

Actually this patch has only one logical change, the state machine
refactoring. But by doing it, those three items were a consequence.

Felipe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWemc+AAoJEMxEtNCSaY5qpXwP/1B/sVsfapRtP4dw93YF6En5
w/ej9JatIyJIaXNxauCVzgRl9uuiXGyEqErRjJdodyvHar3yKvD9HEXE6MhowEp4
JMD/phN2v9Sdj1VxRf9Z0XDSWsg6huVhfQU47HBMRGiY8ezvEgir2bvg7dYbZMsv
ACgIx8oh6N/AEHPq9GoLbEpXfJ58Pl564Sq/2o6wWsJQS06A+jp+JmqK4Y3eB5M5
18rmLW7lQLcZPO08Pf/c6BExWQLbzY/mT8KofwycvC9hWxYp9LPwJY4oMzOWROe8
AZS1ayRqlabG3qx3dPRcV4j6c6uROEfQY+HejCn+Zbi0CfVYtsI+xO5LkwnZMUyc
0qvy90h0PUQ2e37/wo5YnnVLK0ce1Gm6gY50iFXwqE69m55KHTufsIVX4eTUBfcj
PtugPtTnKEsW171r/gHPYO9A+WKxycCvjPs9Wogsljly+NrRzgPMAI7Alx//4lwq
QhwRWF1BkNOoCPEpHnVlLkcIhgdcAbbnvWxlcAVlLAQ/oYl6ShbQFv96y/2IWCVO
Mwr7Ab8a/dnyJ/GWEQdpJUmfKGQbKNpM93H5yD4AQlmz4Hj620gzm3y2XNJY2bUt
8H37Q2VWtlcRy2UHjgBSeF0YKCvdDuDmZwRZbPpajkmbcYSGtJFDve1/L6bOtZSj
7nVfYIqvtIBWrDZ3PF9G
=3uC5
-END PGP SIGNATURE-


0x92698E6A.asc
Description: application/pgp-keys


0x92698E6A.asc.sig
Description: PGP signature