Re: xhci_hcd HC died; cleaning up with TUSB7340 and µPD720201

2017-11-20 Thread Roger Quadros 
Hi Vignesh,

On 16/11/17 14:26, Vignesh R wrote:
> +linux-pci
> 
> Hi Chris,
> 
> On Thursday 16 November 2017 05:20 PM, Quadros, Roger wrote:
>> +Vignesh
>>
>> On 13/09/17 17:26, Chris Welch wrote:
>>> We are developing a product based on the TI AM5728 EVM.  The product 
>>> utilizes a TUSB7340 PCIe USB host for additional ports.  The TUSB7340 is 
>>> detected and setup properly and works OK with low data rate devices.  
>>> However, hot plugging a Realtek USB network adapter and doing Ethernet 
>>> transfer bandwidth testing using iperf3 causes the TUSB7340 host to be  
>>> locked out.  The TUSB7340 host appears to no longer communicate and the 
>>> logging indicates xhci_hcd :01:00.0: HC died; cleaning up.  Same issue 
>>> occurs with another USB Ethernet adapter I tried (Asus).
>>>
>>> We looked at using another host and found a mini PCIe card that utilizes 
>>> the µPD720201 and can be directly installed on the TI AM5728 EVM.  The card 
>>> is detected properly and we reran the transfer test.  The uPD720201 gets 
>>> locks out with the same problem.
>>>
>>> The AM5728 testing was performed using the TI SD card stock 
>>> am57xx-evm-linux-04.00.00.04.img, kernel am57xx-evm 4.9.28-geed43d1050, and 
>>> it reports that it is using the TI AM572x EVM Rev A3 device tree.
>>>
>>> It shows the following logging when it fails (this is with the TI EVM and 
>>> uPD720201).
>>>
>>> [  630.400899] xhci_hcd :01:00.0: xHCI host not responding to stop 
>>> endpoint command.
>>> [  630.408769] xhci_hcd :01:00.0: Assuming host is dying, halting host.
>>> [  630.420849] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [  630.425667] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [  630.430483] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [  630.435297] r8152 2-4:1.0 enp1s0u4: Tx status -108
>>> [  630.440122] xhci_hcd :01:00.0: HC died; cleaning up
>>> [  630.453961] usb 2-4: USB disconnect, device number 2
>>>
>>> The problem appears to be a general driver issue given we get the same 
>>> problem with both the  TUSB7340 and the µPD720201.
> 
> Seems like PCIe driver is missing MSI IRQs leading to stall. 
> Reading xHCI registers via PCIe mem space confirms this.
> 
> I see two problems wrt MSI handling:
> Since commit 8c934095fa2f3 ("PCI: dwc: Clear MSI interrupt status after it is 
> handled, not before"),
> dwc clears MSI status after calling EP's IRQ handler. But, it happens that 
> another MSI interrupt is
> raised just at the end of EP's IRQ handler and before clearing MSI status.
> This will result in loss of new MSI IRQ as we clear the MSI IRQ status 
> without handling.
> 
> Another problem appears to be wrt dra7xx PCIe wrapper:
> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI does not seem to catch MSI IRQs unless,
> its ensured that PCIE_MSI_INTR0_STATUS register read returns 0.
> 
> So, could you try reverting commit 8c934095fa2f3 and 
> also apply below patch and let me know if that fixes the issue?
> 
> ---
> 
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index e77a4ceed74c..8280abc56f30 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, 
> void *arg)
> u32 reg;
>  
> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
> +   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>  
> switch (reg) {
> case MSI:
> -   dw_handle_msi_irq(pp);
> +   /*
> +* Need to make sure no MSI IRQs are pending before
> +* exiting handler, else the wrapper will not catch new
> +* IRQs. So loop around till dw_handle_msi_irq() returns
> +* IRQ_NONE
> +*/
> +   while (dw_handle_msi_irq(pp) != IRQ_NONE);

To avoid this kind of looping, shouldn't we be disabling all IRQ events while
the interrupt handler is running and enable them just before we return from the 
hardirq
handler?


> break;
> case INTA:
> case INTB:
> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, 
> void *arg)
> break;
> }
>  
> -   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
> -
> return IRQ_HANDLED;
>  }
> 
> 
> 
> 

-- 
cheers,
-roger

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

[PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Shrirang Bagul 
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.

Signed-off-by: Shrirang Bagul 
---
 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81cf, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d0, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d1, 12)},   /* Dell Wireless 5818 */
+   {QMI_FIXED_INTF(0x413c, 0x81d2, 12)},   /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
-- 
2.14.1

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

Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Bjørn Mork 
Shrirang Bagul  writes:

> Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> series modems which will by default boot with vid 0x413c and pid's
> 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
> qmi_wwan on the usb interface #12.

NAK,

Interace #12 is MBIM, as shown by the device descriptors. Please provide
those descriptors and you will see that this interface is clearly a CDC
MBIM class interface.

Yes, I know these modems probe the control protocol so that you can make
QMI work on an MBIM control interface by sending it a QMI request as the
first messsage.  This is still wrong, abusing a quirky firmware
feature.

You need to reconfigure the modem for QMI using the Sierra specific AT
command or QMI request (tunneled in MBIM!) to properly switch it to QMI
mode, which will appear as a vendor specific interface number 8 (and 10
if you enable both QMI functions).





Bjørn
--
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: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Shrirang Bagul 
On Mon, 2017-11-20 at 10:41 +0100, Bjørn Mork wrote:
> Shrirang Bagul  writes:
> 
> > Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> > series modems which will by default boot with vid 0x413c and pid's
> > 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
> > qmi_wwan on the usb interface #12.
> 
> NAK,
> 
> Interace #12 is MBIM, as shown by the device descriptors. Please provide
> those descriptors and you will see that this interface is clearly a CDC
> MBIM class interface.
> 
> Yes, I know these modems probe the control protocol so that you can make
> QMI work on an MBIM control interface by sending it a QMI request as the
> first messsage.  This is still wrong, abusing a quirky firmware
> feature.
> 
> You need to reconfigure the modem for QMI using the Sierra specific AT
> command or QMI request (tunneled in MBIM!) to properly switch it to QMI
> mode, which will appear as a vendor specific interface number 8 (and 10
> if you enable both QMI functions).
Understood. Needs more work, will resend with fixes.

- Shrirang
> 
> 
> 
> 
> 
> Bjørn

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] net: qmi_wwan: add Dell DW5818, DW5819

2017-11-20 Thread Lars Melin 

On 11/20/2017 16:27, Shrirang Bagul wrote:

Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series modems which will by default boot with vid 0x413c and pid's
0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
qmi_wwan on the usb interface #12.

Signed-off-by: Shrirang Bagul 
---
  drivers/net/usb/qmi_wwan.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8d4a6f7cba61..bdf1fae38af2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1234,6 +1234,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81cf, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d0, 12)},   /* Dell Wireless 5819 */
+   {QMI_FIXED_INTF(0x413c, 0x81d1, 12)},   /* Dell Wireless 5818 */
+   {QMI_FIXED_INTF(0x413c, 0x81d2, 12)},   /* Dell Wireless 5818 */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */




NAK

413c:81cf and 413c:81d1 do not have a net interface, they only have a 
single serial interface (QDL) for firmware update.
Please do not add usb id's for which you have not confirmed the 
interface composition.


br
Lars

--
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: question about usb_rebind_intf

2017-11-20 Thread Oliver Neukum 
Am Freitag, den 17.11.2017, 13:21 -0500 schrieb Alan Stern:
> 
> The real fix would be to change the interface drivers by adding proper 
> support for reset-resume.  Otherwise there will always be a time window 
> following resume during which the interface is non-functional.

Very hard to do with btusb. The connection is messed up if we lose
power.

Regards
Oliver

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

Re: [PATCH] ARM: dts: bcm283x: Fix fifo size for EP 6,7

2017-11-20 Thread Stefan Wahren 
Hi Minas,

Am 20.11.2017 um 12:59 schrieb Minas Harutyunyan:
> Hi Stefan,
> Looks like I know cause of issue... but I'm overloaded today and will able to 
> check it tomorrow. Sorry for delay.

thanks for your reply. There is no need to hurry, because the merge
window isn't open yet, but i like to get this fixed for the next kernel
release.

I have the suspicion this is related to the fact that u-boot already
initialize the USB IP, before dwc2 driver is loaded.

Regards
Stefan

>
> Thanks,
> Minas
>

--
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_hcd HC died; cleaning up with TUSB7340 and µPD720201

2017-11-20 Thread Vignesh R 


On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
[...]
>>
>> So, could you try reverting commit 8c934095fa2f3 and 
>> also apply below patch and let me know if that fixes the issue?
>>
>> ---
>>
>> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
>> index e77a4ceed74c..8280abc56f30 100644
>> --- a/drivers/pci/dwc/pci-dra7xx.c
>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int 
>> irq, void *arg)
>> u32 reg;
>>  
>> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>> +   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>  
>> switch (reg) {
>> case MSI:
>> -   dw_handle_msi_irq(pp);
>> +   /*
>> +* Need to make sure no MSI IRQs are pending before
>> +* exiting handler, else the wrapper will not catch new
>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>> +* IRQ_NONE
>> +*/
>> +   while (dw_handle_msi_irq(pp) != IRQ_NONE);
> 
> To avoid this kind of looping, shouldn't we be disabling all IRQ events while
> the interrupt handler is running and enable them just before we return from 
> the hardirq
> handler?

IIUC, you are saying to disable all MSIs at PCIe designware core level,
then call dw_handle_msi_irq() and then enable MSIs after hardirq
returns. But, the problem is if PCIe EP raises another MSI after the
call to EP's handler but before re-enabling MSIs, then it will be
ignored as IRQs are not yet enabled.
Ideally, EP's support Per Vector Masking(PVM) which allow RC to prevent
EP from sending MSI messages for sometime. But, unfortunately, the cards
mentioned here don't support this feature.

> 
> 
>> break;
>> case INTA:
>> case INTB:
>> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, 
>> void *arg)
>> break;
>> }
>>  
>> -   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>> -
>> return IRQ_HANDLED;
>>  }
>>
>>
>>
>>
> 

-- 
Regards
Vignesh
--
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_hcd HC died; cleaning up with TUSB7340 and µPD720201

2017-11-20 Thread Roger Quadros 
On 20/11/17 15:19, Vignesh R wrote:
> 
> 
> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
> [...]
>>>
>>> So, could you try reverting commit 8c934095fa2f3 and 
>>> also apply below patch and let me know if that fixes the issue?
>>>
>>> ---
>>>
>>> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
>>> index e77a4ceed74c..8280abc56f30 100644
>>> --- a/drivers/pci/dwc/pci-dra7xx.c
>>> +++ b/drivers/pci/dwc/pci-dra7xx.c
>>> @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int 
>>> irq, void *arg)
>>> u32 reg;
>>>  
>>> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>>> +   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>>  
>>> switch (reg) {
>>> case MSI:
>>> -   dw_handle_msi_irq(pp);
>>> +   /*
>>> +* Need to make sure no MSI IRQs are pending before
>>> +* exiting handler, else the wrapper will not catch new
>>> +* IRQs. So loop around till dw_handle_msi_irq() returns
>>> +* IRQ_NONE
>>> +*/
>>> +   while (dw_handle_msi_irq(pp) != IRQ_NONE);
>>
>> To avoid this kind of looping, shouldn't we be disabling all IRQ events while
>> the interrupt handler is running and enable them just before we return from 
>> the hardirq
>> handler?
> 
> IIUC, you are saying to disable all MSIs at PCIe designware core level,
> then call dw_handle_msi_irq() and then enable MSIs after hardirq
> returns. But, the problem is if PCIe EP raises another MSI after the
> call to EP's handler but before re-enabling MSIs, then it will be
> ignored as IRQs are not yet enabled.
> Ideally, EP's support Per Vector Masking(PVM) which allow RC to prevent
> EP from sending MSI messages for sometime. But, unfortunately, the cards
> mentioned here don't support this feature.

I'm not aware of MSIs.

But for any typical hardware, there should be an interrupt event enable 
register and an
interrupt mask register.

In the IRQ handler, we mask the interrupt but still keep the interrupt events 
enabled so that
they can be latched during the time the interrupt was masked.

When the interrupt is unmasked at end of the IRQ handler, it should re-trigger 
the interrupt
if any events were latched and pending.

This way you don't need to keep checking for any pending events in the IRQ 
handler.

> 
>>
>>
>>> break;
>>> case INTA:
>>> case INTB:
>>> @@ -273,8 +280,6 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, 
>>> void *arg)
>>> break;
>>> }
>>>  
>>> -   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, reg);
>>> -
>>> return IRQ_HANDLED;
>>>  }
>>>
>>>
>>>
>>>
>>
> 

-- 
cheers,
-roger

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

Re: [PATCH] USB: option: add Quectel BG96 2c7c:0296

2017-11-20 Thread Sebastian Sjoholm 
Thank you for the feedback, let me try once more.

Regards,
Sebastian

> On Nov 20, 2017, at 08:05 , Greg KH  wrote:
> 
> On Sun, Nov 19, 2017 at 08:40:28PM +0100, ssjoh...@mac.com wrote:
>> From: ssjoholm 
>> 
>> Signed-off-by: ssjoholm 
> 
> This goes at the bottom of the changelog text.
> 
> And we need a real name, I doubt you use this to sign legal documents.
> 
>> Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both CAT-M 
>> and NB-IoT. Tested hardware is BG96 mounted on Quectel development board 
>> (EVB). The USB id is added to option.c to allow DIAG,GPS,AT and modem 
>> communication with the BG96.
> 
> Please also line-wrap your text at 72 columns, like your editor is
> asking you to :)
> 
> thanks,
> 
> greg k-h

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

[PATCH] USB: serial: iuu_phoenix: remove redundant assignment of DIV to itself

2017-11-20 Thread Colin King 
From: Colin Ian King 

The assignment of DIV to itself is redundant and can be removed.

Signed-off-by: Colin Ian King 
---
 drivers/usb/serial/iuu_phoenix.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/serial/iuu_phoenix.c b/drivers/usb/serial/iuu_phoenix.c
index 397a8012ffa3..62c91e360baf 100644
--- a/drivers/usb/serial/iuu_phoenix.c
+++ b/drivers/usb/serial/iuu_phoenix.c
@@ -472,7 +472,6 @@ static int iuu_clk(struct usb_serial_port *port, int dwFrq)
}
}
P2 = ((P - PO) / 2) - 4;
-   DIV = DIV;
PUMP = 0x04;
PBmsb = (P2 >> 8 & 0x03);
PBlsb = P2 & 0xFF;
-- 
2.14.1

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

[PATCH net,stable] net: qmi_wwan: add Quectel BG96 2c7c:0296

2017-11-20 Thread Sebastian Sjoholm 
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both 
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel development 
board (EVB). The USB id is added to qmi_wwan.c to allow QMI 
communication with the BG96.

Signed-off-by: Sebastian Sjoholm 

---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 720a3a248070..c750cf7c042b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1239,6 +1239,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0  
Mini PCIe */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
+   {QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
2.11.0 (Apple Git-81)

--
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: qmi_wwan: add Quectel BG96 2c7c:0296

2017-11-20 Thread Bjørn Mork 
Sebastian Sjoholm  writes:

> Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both 
> CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel development 
> board (EVB). The USB id is added to qmi_wwan.c to allow QMI 
> communication with the BG96.
>
> Signed-off-by: Sebastian Sjoholm 

Perfect.  Thanks.

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

[PATCH] USB: option: add Quectel BG96 2c7c:0296

2017-11-20 Thread Sebastian Sjoholm 
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both 
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel 
development board (EVB). The USB id is added to option.c to allow 
DIAG,GPS,AT and modem communication with the BG96.

Signed-off-by: Sebastian Sjoholm 

---
 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index aaa7d901a06d..3b3513874cfd 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -238,6 +238,7 @@ static void option_instat_callback(struct urb *urb);
 /* These Quectel products use Quectel's vendor ID */
 #define QUECTEL_PRODUCT_EC21   0x0121
 #define QUECTEL_PRODUCT_EC25   0x0125
+#define QUECTEL_PRODUCT_BG96   0x0296
 
 #define CMOTECH_VENDOR_ID  0x16d8
 #define CMOTECH_PRODUCT_6001   0x6001
@@ -1182,6 +1183,8 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
-- 
2.11.0 (Apple Git-81)

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

Re: [PATCH] USB: serial: iuu_phoenix: remove redundant assignment of DIV to itself

2017-11-20 Thread walter harms 


Am 20.11.2017 18:40, schrieb Colin King:
> From: Colin Ian King 
> 
> The assignment of DIV to itself is redundant and can be removed.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/usb/serial/iuu_phoenix.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/serial/iuu_phoenix.c 
> b/drivers/usb/serial/iuu_phoenix.c
> index 397a8012ffa3..62c91e360baf 100644
> --- a/drivers/usb/serial/iuu_phoenix.c
> +++ b/drivers/usb/serial/iuu_phoenix.c
> @@ -472,7 +472,6 @@ static int iuu_clk(struct usb_serial_port *port, int 
> dwFrq)
>   }
>   }
>   P2 = ((P - PO) / 2) - 4;
> - DIV = DIV;
>   PUMP = 0x04;
>   PBmsb = (P2 >> 8 & 0x03);
>   PBlsb = P2 & 0xFF;

These all all-upper-case stuff makes me a bit nervous. Normally this
is reserved for #define ( I assume that the programmer refers to
the original documentation) a point to change ?

btw: i noticed  int frq = (int)dwFrq;
since dwFrq is already an in, the cast is useless.

just ym 2 cents,

re,
 wh



--
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_hcd HC died; cleaning up with TUSB7340 and µPD720201

2017-11-20 Thread Vignesh R 


On Monday 20 November 2017 07:01 PM, Roger Quadros wrote:
> On 20/11/17 15:19, Vignesh R wrote:
>>
>>
>> On Monday 20 November 2017 01:31 PM, Roger Quadros wrote:
>> [...]

 So, could you try reverting commit 8c934095fa2f3 and 
 also apply below patch and let me know if that fixes the issue?

 ---

 diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
 index e77a4ceed74c..8280abc56f30 100644
 --- a/drivers/pci/dwc/pci-dra7xx.c
 +++ b/drivers/pci/dwc/pci-dra7xx.c
 @@ -259,10 +259,17 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int 
 irq, void *arg)
 u32 reg;
  
 reg = dra7xx_pcie_readl(dra7xx, 
 PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
 +   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI, 
 reg);
  
 switch (reg) {
 case MSI:
 -   dw_handle_msi_irq(pp);
 +   /*
 +* Need to make sure no MSI IRQs are pending before
 +* exiting handler, else the wrapper will not catch new
 +* IRQs. So loop around till dw_handle_msi_irq() returns
 +* IRQ_NONE
 +*/
 +   while (dw_handle_msi_irq(pp) != IRQ_NONE);
>>>
>>> To avoid this kind of looping, shouldn't we be disabling all IRQ events 
>>> while
>>> the interrupt handler is running and enable them just before we return from 
>>> the hardirq
>>> handler?
>>
>> IIUC, you are saying to disable all MSIs at PCIe designware core level,
>> then call dw_handle_msi_irq() and then enable MSIs after hardirq
>> returns. But, the problem is if PCIe EP raises another MSI after the
>> call to EP's handler but before re-enabling MSIs, then it will be
>> ignored as IRQs are not yet enabled.
>> Ideally, EP's support Per Vector Masking(PVM) which allow RC to prevent
>> EP from sending MSI messages for sometime. But, unfortunately, the cards
>> mentioned here don't support this feature.
> 
> I'm not aware of MSIs.
> 
> But for any typical hardware, there should be an interrupt event enable 
> register and an
> interrupt mask register.
> 
> In the IRQ handler, we mask the interrupt but still keep the interrupt events 
> enabled so that
> they can be latched during the time the interrupt was masked.
> 
> When the interrupt is unmasked at end of the IRQ handler, it should 
> re-trigger the interrupt
> if any events were latched and pending.
> 
> This way you don't need to keep checking for any pending events in the IRQ 
> handler.
> 

Thanks for the suggestion! I tried using interrupt masking at designware
level. But, unfortunately that does not help and my test cases still fail.
Seems like designware MSI status register is a non-masked status and
dra7xx specific wrapper seems to be relying on this non-masked status to
raise IRQ(instead of actual IRQ signal of designware) to CPU. There is
very little documentation in the TRM wrt how wrapper forwards designware
IRQ status to CPU.

So, at best, I will add a check in the above while() loop and break and
exit IRQ handler, lets say after 1K loops.


-- 
Regards
Vignesh
--
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: usbip port number limits

2017-11-20 Thread Yuyang Du 
On Wed, Nov 15, 2017 at 07:58:24AM -0700, Shuah Khan wrote:
> Hi Juan,
> 
> On 11/15/2017 07:43 AM, Juan Zea wrote:
> > 
> >>> Also, will you be able to revert the usb3 commit 
> >>> 1c9de5bf428612458427943b724bea51abde520a 
> >>>
> >>> and see if any of the problems go away. 
> >>>
> >>> thanks, 
> >>> -- Shuah 
> >>>
> > 
> >> I'm on it and will send results later.
> > 
> >> Thanks,
> >> Juan
> > 
> > Ok, I'm back. The revert was quite complex, with several conflicts I was 
> > not able to resolve. So I started testing full checkouts around that series 
> > of changes by Yuyang.
> 
> I was hoping it will be easier. I was apprehensive it could be a com[ex 
> revert. :(
> 
> > That led me to bisecting the problem with the fingerprint reader, and the 
> > culprit is here: 
> > 
> > 03cd00d538a6feb0492cd153edf256ef7d7bd95e is the first bad commit
> > commit 03cd00d538a6feb0492cd153edf256ef7d7bd95e
> > Author: Yuyang Du 
> > Date:   Thu Jun 8 13:04:09 2017 +0800
> > 
> > usbip: vhci-hcd: Set the vhci structure up to work
> > 
> > This patch enables the new vhci structure. Its lock protects
> > both the USB2 hub and the shared USB3 hub.
> > 
> > Signed-off-by: Yuyang Du 
> > Acked-by: Shuah Khan 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > :04 04 b7b5c6b16db801c74354bb0d0a247855f64b0829 
> > 72524e78d281ebc8d36fa32cb93ed0278e99f880 M  drivers
> > 
> > The commit before, fingerprint reader works. Also, multicontroller works 
> > (no usb3 ports). 
> > In this bad commit, I get the errors I sent in the previous message.
> > 
> 
> Thanks for reporting and debugging the problem to isolate the commit. I was
> suspecting one of these commit based on the messages you are seeing.
> 
> I will see if I can fix this without doing a huge reverts.
> 
Hi,

Sorry for the latency. It seems now the bug is:

Nov 14 14:35:29 kernel-tester kernel: [  229.636543] kernel BUG at 
drivers/usb/usbip/vhci_hcd.c:683!

which is a hard one (you mentioned the lastest kernel is used).

Since you didn't post patch, lets first make sure we are on the same
page. Could you please try the following patch and see whether the
bug still exists?

Also, I'm assuming you are using a non-super-speed device.

Thanks,
Yuyang

-

diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index 9bd2cd7..82367f9 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -328,9 +328,18 @@ int usbip_vhci_refresh_device_list(void)
 int usbip_vhci_get_free_port(uint32_t speed)
 {
for (int i = 0; i < vhci_driver->nports; i++) {
-   if (speed == USB_SPEED_SUPER &&
-   vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
-   continue;
+   /*
+* Make sure hub speed (either SUPER or !SUPER) matches
+* device speed
+*/
+   if (speed == USB_SPEED_SUPER) {
+   if  (vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
+   continue;
+   }
+   else {
+   if  (vhci_driver->idev[i].hub != HUB_SPEED_HIGH)
+   continue;
+   }
 
if (vhci_driver->idev[i].status == VDEV_ST_NULL)
return vhci_driver->idev[i].port;
--
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