Re: [PATCH] HID: usbhid: fix out-of-bounds bug

[Jaejoong Kim]

2017-09-27 23:29 GMT+09:00 Alan Stern :
> On Wed, 27 Sep 2017, Michel Hermier wrote:
>
>> Le 27 sept. 2017 07:42, "Alan Stern"  a écrit :
>
>> > -   for (n = 0; n < hdesc->bNumDescriptors; n++)
>> > +   num_descriptors = min_t(int, hdesc->bNumDescriptors,
>> > +   (hdesc->bLength - 6) / 3);
>> > +   for (n = 0; n < num_descriptors; n++)
>> > if (hdesc->desc[n].bDescriptorType == HID_DT_REPORT)
>> > rsize = le16_to_cpu(hdesc->desc[n].
>> wDescriptorLength);
>>
>> Yes, this is a lot better.

OK.

>>
>>
>> Is it possible to explicit the magic number 6 and 3 in the code. Currently,
>> it looks like it comes from no where.

I gree with you.

>
> Yes, it is possible.  The 6 is equal to
>
> offsetof(struct hid_descriptor, desc)
>
> and the 3 is equal to
>
> sizeof(struct hid_class_descriptor)
>
> (at least, I think it is -- the structure is marked as packed so its
> size should be 3).
>
> In this case I found the numbers to be more readable, but other people
> may have different opinions.

I will post V2 shortly.

>
>> I'm also wondering if this change will not affect some devices in the wild,
>> by rejecting hid descriptors with num descriptors == 0 ?
>
> It's possible, but I doubt it.  If such devices do exist, they should
> never have worked in the first place.  Certainly they would generate
> warnings or errors during enumeration because of their invalid
> descriptors.
>
> Alan Stern
>

Jaejoong
--
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/5] USB: dummy-hcd: multiple fixes

[Felipe Balbi]

Hi,

Alan Stern  writes:
> Felipe and Greg:
>
> In the following series of changes for the dummy-hcd driver, the first
> three patches correct issues that are serious enough to merit inclusion
> in the -stable kernels:
>
>   1/5 fixes a bug that prevents g_mass_storage from working 
>   correctly in the default configuration;
>
>   2/5 fixes an interrupts-disabled infinite loop found with
>   syzkaller;
>
>   3/5 fixes a locking bug created by an earlier commit.
>
> Patches 4 and 5 concern less important matters: removing unsupported
> endpoints and limiting bandwidth for control/interrupt transfers.  
> They do not need to go into -stable and they don't fix any serious
> problems, so it's okay for them to wait for the next merge window.
>
> The patches are independent, so it shouldn't matter if Greg takes 1-3 
> and Felipe takes 4-5.

I'll send a 'fixes' pull request tomorrow. Just finishing up going
through pending patches.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 16/31] usb/phy-isp1301-omap: Remove .data assignment

[Felipe Balbi]

Hi,

Kees Cook  writes:
> The .data assignment appears to be redundant to the WORK_STOP bit for
> stopping the timer. Also, it appears this timer is entirely unused
> as it is only ever started under #define VERBOSE, which is explicitly
> undefined.
>
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: linux-usb@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Kees Cook 

Are you merging these as part of a larger series altogether, or should I
pick the patches that concern me?

If you're taking them all together:

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 27/31] usb/gadget/snps_udc_core: Remove struct timer_list.data use

[Felipe Balbi]

Kees Cook  writes:

> If the probe fails, udc_remove() will not be called, so there is no
> reason to make del_timer_sync() calls conditional. As a result, use of
> the .data field can be dropped, in support of making removing this field
> entirely from struct timer_list.
>
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: Raviteja Garimella 
> Cc: Michal Nazarewicz 
> Cc: "Gustavo A. R. Silva" 
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Kees Cook 

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v4 6/8] pwm: atmel-tcb: Support backup mode

[Romain Izard]

Save and restore registers for the PWM on suspend and resume, which
makes hibernation and backup modes possible.

Signed-off-by: Romain Izard 
Acked-by: Nicolas Ferre 
---
 drivers/pwm/pwm-atmel-tcb.c | 63 +++--
 1 file changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index 75db585a2a94..acd3ce8ecf3f 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -37,11 +37,20 @@ struct atmel_tcb_pwm_device {
unsigned period;/* PWM period expressed in clk cycles */
 };
 
+struct atmel_tcb_channel {
+   u32 enabled;
+   u32 cmr;
+   u32 ra;
+   u32 rb;
+   u32 rc;
+};
+
 struct atmel_tcb_pwm_chip {
struct pwm_chip chip;
spinlock_t lock;
struct atmel_tc *tc;
struct atmel_tcb_pwm_device *pwms[NPWM];
+   struct atmel_tcb_channel bkup[NPWM / 2];
 };
 
 static inline struct atmel_tcb_pwm_chip *to_tcb_chip(struct pwm_chip *chip)
@@ -175,12 +184,15 @@ static void atmel_tcb_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 * Use software trigger to apply the new setting.
 * If both PWM devices in this group are disabled we stop the clock.
 */
-   if (!(cmr & (ATMEL_TC_ACPC | ATMEL_TC_BCPC)))
+   if (!(cmr & (ATMEL_TC_ACPC | ATMEL_TC_BCPC))) {
__raw_writel(ATMEL_TC_SWTRG | ATMEL_TC_CLKDIS,
 regs + ATMEL_TC_REG(group, CCR));
-   else
+   tcbpwmc->bkup[group].enabled = 1;
+   } else {
__raw_writel(ATMEL_TC_SWTRG, regs +
 ATMEL_TC_REG(group, CCR));
+   tcbpwmc->bkup[group].enabled = 0;
+   }
 
spin_unlock(&tcbpwmc->lock);
 }
@@ -263,6 +275,7 @@ static int atmel_tcb_pwm_enable(struct pwm_chip *chip, 
struct pwm_device *pwm)
/* Use software trigger to apply the new setting */
__raw_writel(ATMEL_TC_CLKEN | ATMEL_TC_SWTRG,
 regs + ATMEL_TC_REG(group, CCR));
+   tcbpwmc->bkup[group].enabled = 1;
spin_unlock(&tcbpwmc->lock);
return 0;
 }
@@ -445,10 +458,56 @@ static const struct of_device_id atmel_tcb_pwm_dt_ids[] = 
{
 };
 MODULE_DEVICE_TABLE(of, atmel_tcb_pwm_dt_ids);
 
+#ifdef CONFIG_PM_SLEEP
+static int atmel_tcb_pwm_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct atmel_tcb_pwm_chip *tcbpwm = platform_get_drvdata(pdev);
+   void __iomem *base = tcbpwm->tc->regs;
+   int i;
+
+   for (i = 0; i < (NPWM / 2); i++) {
+   struct atmel_tcb_channel *chan = &tcbpwm->bkup[i];
+
+   chan->cmr = readl(base + ATMEL_TC_REG(i, CMR));
+   chan->ra = readl(base + ATMEL_TC_REG(i, RA));
+   chan->rb = readl(base + ATMEL_TC_REG(i, RB));
+   chan->rc = readl(base + ATMEL_TC_REG(i, RC));
+   }
+   return 0;
+}
+
+static int atmel_tcb_pwm_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct atmel_tcb_pwm_chip *tcbpwm = platform_get_drvdata(pdev);
+   void __iomem *base = tcbpwm->tc->regs;
+   int i;
+
+   for (i = 0; i < (NPWM / 2); i++) {
+   struct atmel_tcb_channel *chan = &tcbpwm->bkup[i];
+
+   writel(chan->cmr, base + ATMEL_TC_REG(i, CMR));
+   writel(chan->ra, base + ATMEL_TC_REG(i, RA));
+   writel(chan->rb, base + ATMEL_TC_REG(i, RB));
+   writel(chan->rc, base + ATMEL_TC_REG(i, RC));
+   if (chan->enabled) {
+   writel(ATMEL_TC_CLKEN | ATMEL_TC_SWTRG,
+   base + ATMEL_TC_REG(i, CCR));
+   }
+   }
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(atmel_tcb_pwm_pm_ops, atmel_tcb_pwm_suspend,
+atmel_tcb_pwm_resume);
+
 static struct platform_driver atmel_tcb_pwm_driver = {
.driver = {
.name = "atmel-tcb-pwm",
.of_match_table = atmel_tcb_pwm_dt_ids,
+   .pm = &atmel_tcb_pwm_pm_ops,
},
.probe = atmel_tcb_pwm_probe,
.remove = atmel_tcb_pwm_remove,
-- 
2.11.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 v4 0/8] Various patches for SAMA5D2 backup mode

[Romain Izard]

While the core of the backup mode for SAMA5D2 has been integrated in
v4.13, it is far from complete. Individual controllers in the chip have
drivers that do not support the reset of the registers during suspend,
and they need to be adapted to handle it.

The first patch uses the clock wakeup code from the prototype backup
mode instead of the version integrated in the mainline, as the mainline
version is not stable. During a test loop with two-second backup
suspend, the mainline version will hang in less than one day, whereas
the prototype version has been running the same test for more than a
week without hanging.

While all these patches are provided in a series, the clock, mtd,
usb, pwm and mfd patch do not depend on each other.

Changes in v2:
* drop the IIO patch duplicating existing code
* determine the number of programmable clocks to save dynamically
* declare a required local variable in the tty/serial patch

Changes in v3:
* drop dev_printk changes for PMECC
* rework the resume code for PMECC
* improve comments on PMC clock handling

Changes in v4:
* fix a bug in the PMECC resume code

Romain Izard (8):
  clk: at91: pmc: Wait for clocks when resuming
  clk: at91: pmc: Save SCSR during suspend
  clk: at91: pmc: Support backup for programmable clocks
  mtd: nand: atmel: Avoid ECC errors when leaving backup mode
  ehci-atmel: Power down during suspend is normal
  pwm: atmel-tcb: Support backup mode
  atmel_flexcom: Support backup mode
  tty/serial: atmel: Prevent a warning on suspend

 drivers/clk/at91/clk-programmable.c  |  2 +
 drivers/clk/at91/pmc.c   | 63 ++-
 drivers/clk/at91/pmc.h   |  2 +
 drivers/mfd/atmel-flexcom.c  | 65 
 drivers/mtd/nand/atmel/nand-controller.c |  3 ++
 drivers/mtd/nand/atmel/pmecc.c   | 17 +
 drivers/mtd/nand/atmel/pmecc.h   |  1 +
 drivers/pwm/pwm-atmel-tcb.c  | 63 ++-
 drivers/tty/serial/atmel_serial.c| 13 +++
 drivers/usb/host/ehci-atmel.c|  3 +-
 10 files changed, 196 insertions(+), 36 deletions(-)

-- 
2.11.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 v4 8/8] tty/serial: atmel: Prevent a warning on suspend

[Romain Izard]

The atmel serial port driver reported the following warning on suspend:
atmel_usart f802.serial: ttyS1: Unable to drain transmitter

As the ATMEL_US_TXEMPTY status bit in ATMEL_US_CSR is always cleared
when the transmitter is disabled, we need to know the transmitter's
state to return the real fifo state. And as ATMEL_US_CR is write-only,
it is necessary to save the state of the transmitter in a local
variable, and update the variable when TXEN and TXDIS is written in
ATMEL_US_CR.

After those changes, atmel_tx_empty can return "empty" on suspend, the
warning in uart_suspend_port disappears, and suspending is 20ms shorter
for each enabled Atmel serial port.

Signed-off-by: Romain Izard 
Tested-by: Nicolas Ferre 
Acked-by: Nicolas Ferre 
Acked-by: Richard Genoud 
---
 drivers/tty/serial/atmel_serial.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index 7551cab438ff..ce45b4ada0bf 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -171,6 +171,7 @@ struct atmel_uart_port {
boolhas_hw_timer;
struct timer_list   uart_timer;
 
+   booltx_stopped;
boolsuspended;
unsigned intpending;
unsigned intpending_status;
@@ -380,6 +381,10 @@ static int atmel_config_rs485(struct uart_port *port,
  */
 static u_int atmel_tx_empty(struct uart_port *port)
 {
+   struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
+   if (atmel_port->tx_stopped)
+   return TIOCSER_TEMT;
return (atmel_uart_readl(port, ATMEL_US_CSR) & ATMEL_US_TXEMPTY) ?
TIOCSER_TEMT :
0;
@@ -485,6 +490,7 @@ static void atmel_stop_tx(struct uart_port *port)
 * is fully transmitted.
 */
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
+   atmel_port->tx_stopped = true;
 
/* Disable interrupts */
atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
@@ -521,6 +527,7 @@ static void atmel_start_tx(struct uart_port *port)
 
/* re-enable the transmitter */
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
+   atmel_port->tx_stopped = false;
 }
 
 /*
@@ -1866,6 +1873,7 @@ static int atmel_startup(struct uart_port *port)
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_RSTSTA | ATMEL_US_RSTRX);
/* enable xmit & rcvr */
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN | ATMEL_US_RXEN);
+   atmel_port->tx_stopped = false;
 
setup_timer(&atmel_port->uart_timer,
atmel_uart_timer_callback,
@@ -2122,6 +2130,7 @@ static void atmel_set_termios(struct uart_port *port, 
struct ktermios *termios,
 
/* disable receiver and transmitter */
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS | ATMEL_US_RXDIS);
+   atmel_port->tx_stopped = true;
 
/* mode */
if (port->rs485.flags & SER_RS485_ENABLED) {
@@ -2207,6 +2216,7 @@ static void atmel_set_termios(struct uart_port *port, 
struct ktermios *termios,
atmel_uart_writel(port, ATMEL_US_BRGR, quot);
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_RSTSTA | ATMEL_US_RSTRX);
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN | ATMEL_US_RXEN);
+   atmel_port->tx_stopped = false;
 
/* restore interrupts */
atmel_uart_writel(port, ATMEL_US_IER, imr);
@@ -2450,6 +2460,7 @@ static void atmel_console_write(struct console *co, const 
char *s, u_int count)
 
/* Make sure that tx path is actually able to send characters */
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
+   atmel_port->tx_stopped = false;
 
uart_console_write(port, s, count, atmel_console_putchar);
 
@@ -2511,6 +2522,7 @@ static int __init atmel_console_setup(struct console *co, 
char *options)
 {
int ret;
struct uart_port *port = &atmel_ports[co->index].uart;
+   struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
int baud = 115200;
int bits = 8;
int parity = 'n';
@@ -2528,6 +2540,7 @@ static int __init atmel_console_setup(struct console *co, 
char *options)
atmel_uart_writel(port, ATMEL_US_IDR, -1);
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_RSTSTA | ATMEL_US_RSTRX);
atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN | ATMEL_US_RXEN);
+   atmel_port->tx_stopped = false;
 
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
-- 
2.11.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 v4 7/8] atmel_flexcom: Support backup mode

[Romain Izard]

The controller used by a flexcom module is configured at boot, and left
alone after this. As the configuration will be lost after backup mode,
restore the state of the flexcom driver on resume.

Signed-off-by: Romain Izard 
Acked-by: Nicolas Ferre 
Tested-by: Nicolas Ferre 
---
 drivers/mfd/atmel-flexcom.c | 65 ++---
 1 file changed, 50 insertions(+), 15 deletions(-)

diff --git a/drivers/mfd/atmel-flexcom.c b/drivers/mfd/atmel-flexcom.c
index 064bde9cff5a..ef1235c4a179 100644
--- a/drivers/mfd/atmel-flexcom.c
+++ b/drivers/mfd/atmel-flexcom.c
@@ -39,34 +39,44 @@
 #define FLEX_MR_OPMODE(opmode) (((opmode) << FLEX_MR_OPMODE_OFFSET) &  \
 FLEX_MR_OPMODE_MASK)
 
+struct atmel_flexcom {
+   void __iomem *base;
+   u32 opmode;
+   struct clk *clk;
+};
 
 static int atmel_flexcom_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
-   struct clk *clk;
struct resource *res;
-   void __iomem *base;
-   u32 opmode;
+   struct atmel_flexcom *afc;
int err;
+   u32 val;
+
+   afc = devm_kzalloc(&pdev->dev, sizeof(*afc), GFP_KERNEL);
+   if (!afc)
+   return -ENOMEM;
 
-   err = of_property_read_u32(np, "atmel,flexcom-mode", &opmode);
+   platform_set_drvdata(pdev, afc);
+
+   err = of_property_read_u32(np, "atmel,flexcom-mode", &afc->opmode);
if (err)
return err;
 
-   if (opmode < ATMEL_FLEXCOM_MODE_USART ||
-   opmode > ATMEL_FLEXCOM_MODE_TWI)
+   if (afc->opmode < ATMEL_FLEXCOM_MODE_USART ||
+   afc->opmode > ATMEL_FLEXCOM_MODE_TWI)
return -EINVAL;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   afc->base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(afc->base))
+   return PTR_ERR(afc->base);
 
-   clk = devm_clk_get(&pdev->dev, NULL);
-   if (IS_ERR(clk))
-   return PTR_ERR(clk);
+   afc->clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(afc->clk))
+   return PTR_ERR(afc->clk);
 
-   err = clk_prepare_enable(clk);
+   err = clk_prepare_enable(afc->clk);
if (err)
return err;
 
@@ -76,9 +86,10 @@ static int atmel_flexcom_probe(struct platform_device *pdev)
 * inaccessible and are read as zero. Also the external I/O lines of the
 * Flexcom are muxed to reach the selected device.
 */
-   writel(FLEX_MR_OPMODE(opmode), base + FLEX_MR);
+   val = FLEX_MR_OPMODE(afc->opmode);
+   writel(val, afc->base + FLEX_MR);
 
-   clk_disable_unprepare(clk);
+   clk_disable_unprepare(afc->clk);
 
return devm_of_platform_populate(&pdev->dev);
 }
@@ -89,10 +100,34 @@ static const struct of_device_id atmel_flexcom_of_match[] 
= {
 };
 MODULE_DEVICE_TABLE(of, atmel_flexcom_of_match);
 
+#ifdef CONFIG_PM_SLEEP
+static int atmel_flexcom_resume(struct device *dev)
+{
+   struct atmel_flexcom *afc = dev_get_drvdata(dev);
+   int err;
+   u32 val;
+
+   err = clk_prepare_enable(afc->clk);
+   if (err)
+   return err;
+
+   val = FLEX_MR_OPMODE(afc->opmode),
+   writel(val, afc->base + FLEX_MR);
+
+   clk_disable_unprepare(afc->clk);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(atmel_flexcom_pm_ops, NULL,
+atmel_flexcom_resume);
+
 static struct platform_driver atmel_flexcom_driver = {
.probe  = atmel_flexcom_probe,
.driver = {
.name   = "atmel_flexcom",
+   .pm = &atmel_flexcom_pm_ops,
.of_match_table = atmel_flexcom_of_match,
},
 };
-- 
2.11.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 v4 5/8] ehci-atmel: Power down during suspend is normal

[Romain Izard]

When an Atmel SoC is suspended with the backup mode, the USB bus will be
powered down. As this is expected, do not return an error to the driver
core when ehci_resume detects it.

Signed-off-by: Romain Izard 
Acked-by: Nicolas Ferre 
---
 drivers/usb/host/ehci-atmel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 7440722bfbf0..2a8b9bdc0e57 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -205,7 +205,8 @@ static int __maybe_unused ehci_atmel_drv_resume(struct 
device *dev)
struct atmel_ehci_priv *atmel_ehci = hcd_to_atmel_ehci_priv(hcd);
 
atmel_start_clock(atmel_ehci);
-   return ehci_resume(hcd, false);
+   ehci_resume(hcd, false);
+   return 0;
 }
 
 #ifdef CONFIG_OF
-- 
2.11.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 v4 4/8] mtd: nand: atmel: Avoid ECC errors when leaving backup mode

[Romain Izard]

During backup mode, the contents of all registers will be cleared as the
SoC will be completely powered down. For a product that boots on NAND
Flash memory, the bootloader will obviously use the related controller
to read the Flash and correct any detected error in the memory, before
handling back control to the kernel's resuming entry point.

But it does not clean the NAND controller registers after use and on its
side the kernel driver expects the error locator to be powered down and
in a clean state. Add a resume hook for the PMECC error locator, and
reset its registers.

Signed-off-by: Romain Izard 
---
Changes in v3:
* keep the PMECC disabled when not in use, and use atmel_pmecc_resume to
  reset the controller after the bootloader has left it enabled.

Changes in v4:
* export atmel_pmecc_reset instead of atmel_pmecc_resume
* use the correct pointer in atmel_nand_controller_resume

 drivers/mtd/nand/atmel/nand-controller.c |  3 +++
 drivers/mtd/nand/atmel/pmecc.c   | 17 +
 drivers/mtd/nand/atmel/pmecc.h   |  1 +
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/atmel/nand-controller.c 
b/drivers/mtd/nand/atmel/nand-controller.c
index f25eca79f4e5..8afcff9a66ea 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -2530,6 +2530,9 @@ static __maybe_unused int 
atmel_nand_controller_resume(struct device *dev)
struct atmel_nand_controller *nc = dev_get_drvdata(dev);
struct atmel_nand *nand;
 
+   if (nc->pmecc)
+   atmel_pmecc_reset(nc->pmecc);
+
list_for_each_entry(nand, &nc->chips, node) {
int i;
 
diff --git a/drivers/mtd/nand/atmel/pmecc.c b/drivers/mtd/nand/atmel/pmecc.c
index 146af8218314..0a3f12141c45 100644
--- a/drivers/mtd/nand/atmel/pmecc.c
+++ b/drivers/mtd/nand/atmel/pmecc.c
@@ -765,6 +765,13 @@ void atmel_pmecc_get_generated_eccbytes(struct 
atmel_pmecc_user *user,
 }
 EXPORT_SYMBOL_GPL(atmel_pmecc_get_generated_eccbytes);
 
+void atmel_pmecc_reset(struct atmel_pmecc *pmecc)
+{
+   writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
+   writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
+}
+EXPORT_SYMBOL_GPL(atmel_pmecc_reset);
+
 int atmel_pmecc_enable(struct atmel_pmecc_user *user, int op)
 {
struct atmel_pmecc *pmecc = user->pmecc;
@@ -797,10 +804,7 @@ EXPORT_SYMBOL_GPL(atmel_pmecc_enable);
 
 void atmel_pmecc_disable(struct atmel_pmecc_user *user)
 {
-   struct atmel_pmecc *pmecc = user->pmecc;
-
-   writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
-   writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
+   atmel_pmecc_reset(user->pmecc);
mutex_unlock(&user->pmecc->lock);
 }
 EXPORT_SYMBOL_GPL(atmel_pmecc_disable);
@@ -855,10 +859,7 @@ static struct atmel_pmecc *atmel_pmecc_create(struct 
platform_device *pdev,
 
/* Disable all interrupts before registering the PMECC handler. */
writel(0x, pmecc->regs.base + ATMEL_PMECC_IDR);
-
-   /* Reset the ECC engine */
-   writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
-   writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
+   atmel_pmecc_reset(pmecc);
 
return pmecc;
 }
diff --git a/drivers/mtd/nand/atmel/pmecc.h b/drivers/mtd/nand/atmel/pmecc.h
index a8ddbfca2ea5..817e0dd9fd15 100644
--- a/drivers/mtd/nand/atmel/pmecc.h
+++ b/drivers/mtd/nand/atmel/pmecc.h
@@ -61,6 +61,7 @@ atmel_pmecc_create_user(struct atmel_pmecc *pmecc,
struct atmel_pmecc_user_req *req);
 void atmel_pmecc_destroy_user(struct atmel_pmecc_user *user);
 
+void atmel_pmecc_reset(struct atmel_pmecc *pmecc);
 int atmel_pmecc_enable(struct atmel_pmecc_user *user, int op);
 void atmel_pmecc_disable(struct atmel_pmecc_user *user);
 int atmel_pmecc_wait_rdy(struct atmel_pmecc_user *user);
-- 
2.11.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 v4 1/8] clk: at91: pmc: Wait for clocks when resuming

[Romain Izard]

Wait for the syncronization of all clocks when resuming, not only the
UPLL clock. Do not use regmap_read_poll_timeout, as it will call BUG()
when interrupts are masked, which is the case in here.

Signed-off-by: Romain Izard 
Acked-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
---
 drivers/clk/at91/pmc.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 775af473fe11..5c2b26de303e 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -107,10 +107,20 @@ static int pmc_suspend(void)
return 0;
 }
 
+static bool pmc_ready(unsigned int mask)
+{
+   unsigned int status;
+
+   regmap_read(pmcreg, AT91_PMC_SR, &status);
+
+   return ((status & mask) == mask) ? 1 : 0;
+}
+
 static void pmc_resume(void)
 {
-   int i, ret = 0;
+   int i;
u32 tmp;
+   u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
 
regmap_read(pmcreg, AT91_PMC_MCKR, &tmp);
if (pmc_cache.mckr != tmp)
@@ -134,13 +144,11 @@ static void pmc_resume(void)
 AT91_PMC_PCR_CMD);
}
 
-   if (pmc_cache.uckr & AT91_PMC_UPLLEN) {
-   ret = regmap_read_poll_timeout(pmcreg, AT91_PMC_SR, tmp,
-  !(tmp & AT91_PMC_LOCKU),
-  10, 5000);
-   if (ret)
-   pr_crit("USB PLL didn't lock when resuming\n");
-   }
+   if (pmc_cache.uckr & AT91_PMC_UPLLEN)
+   mask |= AT91_PMC_LOCKU;
+
+   while (!pmc_ready(mask))
+   cpu_relax();
 }
 
 static struct syscore_ops pmc_syscore_ops = {
-- 
2.11.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 v4 3/8] clk: at91: pmc: Support backup for programmable clocks

[Romain Izard]

From: Romain Izard 

When an AT91 programmable clock is declared in the device tree, register
it into the Power Management Controller driver. On entering suspend mode,
the driver saves and restores the Programmable Clock registers to support
the backup mode for these clocks.

Signed-off-by: Romain Izard 
Acked-by: Nicolas Ferre 
---
Changes in v2:
* register PCKs on clock startup

Changes in v3:
* improve comments on hanling 0 in pmc_register_id and pmc_register_pck
* declare local variables earlier for checkpatch

 drivers/clk/at91/clk-programmable.c |  2 ++
 drivers/clk/at91/pmc.c  | 35 +++
 drivers/clk/at91/pmc.h  |  2 ++
 3 files changed, 39 insertions(+)

diff --git a/drivers/clk/at91/clk-programmable.c 
b/drivers/clk/at91/clk-programmable.c
index 85a449cf61e3..0e6aab1252fc 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -204,6 +204,8 @@ at91_clk_register_programmable(struct regmap *regmap,
if (ret) {
kfree(prog);
hw = ERR_PTR(ret);
+   } else {
+   pmc_register_pck(id);
}
 
return hw;
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 07dc2861ad3f..1fa27f4ea538 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -22,6 +22,7 @@
 #include "pmc.h"
 
 #define PMC_MAX_IDS 128
+#define PMC_MAX_PCKS 8
 
 int of_at91_get_clk_range(struct device_node *np, const char *propname,
  struct clk_range *range)
@@ -50,6 +51,7 @@ EXPORT_SYMBOL_GPL(of_at91_get_clk_range);
 static struct regmap *pmcreg;
 
 static u8 registered_ids[PMC_MAX_IDS];
+static u8 registered_pcks[PMC_MAX_PCKS];
 
 static struct
 {
@@ -66,8 +68,13 @@ static struct
u32 pcr[PMC_MAX_IDS];
u32 audio_pll0;
u32 audio_pll1;
+   u32 pckr[PMC_MAX_PCKS];
 } pmc_cache;
 
+/*
+ * As Peripheral ID 0 is invalid on AT91 chips, the identifier is stored
+ * without alteration in the table, and 0 is for unused clocks.
+ */
 void pmc_register_id(u8 id)
 {
int i;
@@ -82,9 +89,28 @@ void pmc_register_id(u8 id)
}
 }
 
+/*
+ * As Programmable Clock 0 is valid on AT91 chips, there is an offset
+ * of 1 between the stored value and the real clock ID.
+ */
+void pmc_register_pck(u8 pck)
+{
+   int i;
+
+   for (i = 0; i < PMC_MAX_PCKS; i++) {
+   if (registered_pcks[i] == 0) {
+   registered_pcks[i] = pck + 1;
+   break;
+   }
+   if (registered_pcks[i] == (pck + 1))
+   break;
+   }
+}
+
 static int pmc_suspend(void)
 {
int i;
+   u8 num;
 
regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
@@ -103,6 +129,10 @@ static int pmc_suspend(void)
regmap_read(pmcreg, AT91_PMC_PCR,
&pmc_cache.pcr[registered_ids[i]]);
}
+   for (i = 0; registered_pcks[i]; i++) {
+   num = registered_pcks[i] - 1;
+   regmap_read(pmcreg, AT91_PMC_PCKR(num), &pmc_cache.pckr[num]);
+   }
 
return 0;
 }
@@ -119,6 +149,7 @@ static bool pmc_ready(unsigned int mask)
 static void pmc_resume(void)
 {
int i;
+   u8 num;
u32 tmp;
u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
 
@@ -143,6 +174,10 @@ static void pmc_resume(void)
 pmc_cache.pcr[registered_ids[i]] |
 AT91_PMC_PCR_CMD);
}
+   for (i = 0; registered_pcks[i]; i++) {
+   num = registered_pcks[i] - 1;
+   regmap_write(pmcreg, AT91_PMC_PCKR(num), pmc_cache.pckr[num]);
+   }
 
if (pmc_cache.uckr & AT91_PMC_UPLLEN)
mask |= AT91_PMC_LOCKU;
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index 858e8ef7e8db..d22b1fa9ecdc 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -31,8 +31,10 @@ int of_at91_get_clk_range(struct device_node *np, const char 
*propname,
 
 #ifdef CONFIG_PM
 void pmc_register_id(u8 id);
+void pmc_register_pck(u8 pck);
 #else
 static inline void pmc_register_id(u8 id) {}
+static inline void pmc_register_pck(u8 pck) {}
 #endif
 
 #endif /* __PMC_H_ */
-- 
2.11.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 v4 2/8] clk: at91: pmc: Save SCSR during suspend

[Romain Izard]

The contents of the System Clock Status Register (SCSR) needs to be
restored into the System Clock Enable Register (SCER).

As the bootloader will restore some clocks by itself, the issue can be
missed as only the USB controller, the LCD controller, the Image Sensor
controller and the programmable clocks will be impacted.

Fix the obvious typo in the suspend/resume code, as the IMR register
does not need to be saved twice.

Signed-off-by: Romain Izard 
Acked-by: Nicolas Ferre 
---
 drivers/clk/at91/pmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 5c2b26de303e..07dc2861ad3f 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -86,7 +86,7 @@ static int pmc_suspend(void)
 {
int i;
 
-   regmap_read(pmcreg, AT91_PMC_IMR, &pmc_cache.scsr);
+   regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
regmap_read(pmcreg, AT91_CKGR_UCKR, &pmc_cache.uckr);
regmap_read(pmcreg, AT91_CKGR_MOR, &pmc_cache.mor);
@@ -129,7 +129,7 @@ static void pmc_resume(void)
if (pmc_cache.pllar != tmp)
pr_warn("PLLAR was not configured properly by the firmware\n");
 
-   regmap_write(pmcreg, AT91_PMC_IMR, pmc_cache.scsr);
+   regmap_write(pmcreg, AT91_PMC_SCER, pmc_cache.scsr);
regmap_write(pmcreg, AT91_PMC_PCER, pmc_cache.pcsr0);
regmap_write(pmcreg, AT91_CKGR_UCKR, pmc_cache.uckr);
regmap_write(pmcreg, AT91_CKGR_MOR, pmc_cache.mor);
-- 
2.11.0

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

Re: [PATCH v4 0/8] Various patches for SAMA5D2 backup mode

[Alexandre Belloni]

Hi,

On 28/09/2017 at 11:46:19 +0200, Romain Izard wrote:
> While the core of the backup mode for SAMA5D2 has been integrated in
> v4.13, it is far from complete. Individual controllers in the chip have
> drivers that do not support the reset of the registers during suspend,
> and they need to be adapted to handle it.
> 
> The first patch uses the clock wakeup code from the prototype backup
> mode instead of the version integrated in the mainline, as the mainline
> version is not stable. During a test loop with two-second backup
> suspend, the mainline version will hang in less than one day, whereas
> the prototype version has been running the same test for more than a
> week without hanging.
> 
> While all these patches are provided in a series, the clock, mtd,
> usb, pwm and mfd patch do not depend on each other.
> 
> Changes in v2:
> * drop the IIO patch duplicating existing code
> * determine the number of programmable clocks to save dynamically
> * declare a required local variable in the tty/serial patch
> 
> Changes in v3:
> * drop dev_printk changes for PMECC
> * rework the resume code for PMECC
> * improve comments on PMC clock handling
> 
> Changes in v4:
> * fix a bug in the PMECC resume code
> 
> Romain Izard (8):
>   clk: at91: pmc: Wait for clocks when resuming
>   clk: at91: pmc: Save SCSR during suspend
>   clk: at91: pmc: Support backup for programmable clocks
>   mtd: nand: atmel: Avoid ECC errors when leaving backup mode
>   ehci-atmel: Power down during suspend is normal
>   pwm: atmel-tcb: Support backup mode
>   atmel_flexcom: Support backup mode
>   tty/serial: atmel: Prevent a warning on suspend
> 

Really, you have to stop sending those independent patches as a series
if you want to have a chance to see them being merged.

>  drivers/clk/at91/clk-programmable.c  |  2 +
>  drivers/clk/at91/pmc.c   | 63 ++-
>  drivers/clk/at91/pmc.h   |  2 +
>  drivers/mfd/atmel-flexcom.c  | 65 
> 
>  drivers/mtd/nand/atmel/nand-controller.c |  3 ++
>  drivers/mtd/nand/atmel/pmecc.c   | 17 +
>  drivers/mtd/nand/atmel/pmecc.h   |  1 +
>  drivers/pwm/pwm-atmel-tcb.c  | 63 ++-
>  drivers/tty/serial/atmel_serial.c| 13 +++
>  drivers/usb/host/ehci-atmel.c|  3 +-
>  10 files changed, 196 insertions(+), 36 deletions(-)
> 
> -- 
> 2.11.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] HID: usbhid: fix out-of-bounds bug

[Jaejoong Kim]

The hid descriptor identifies the length and type of subordinate
descriptors for a device. If the received hid descriptor is smaller than
the size of the struct hid_descriptor, it is possible to cause
out-of-bounds.

In addition, if bNumDescriptors of the hid descriptor have an incorrect
value, this can also cause out-of-bounds while approaching hdesc->desc[n].

So check the size of hid descriptor and bNumDescriptors.

BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
Read of size 1 at addr 88006c5f8edf by task kworker/1:2/1261

CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351
kasan_report+0x22f/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Reported-by: Andrey Konovalov 
Signed-off-by: Jaejoong Kim 
---

Changes in v2:
- write a new commit message because orginal version is wrong approach
- add check hid descriptor size
- get proper value for bNumDescriptors as suggested by Alan Stern
- fix the Reported-by

 drivers/hid/usbhid/hid-core.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 089bad8..045b5da 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -975,6 +975,8 @@ static int usbhid_parse(struct hid_device *hid)
unsigned int rsize = 0;
char *rdesc;
int ret, n;
+   int num_descriptors;
+   size_t offset = offsetof(struct hid_descriptor, desc);
 
quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
le16_to_cpu(dev->descriptor.idProduct));
@@ -997,10 +999,18 @@ static int usbhid_parse(struct hid_device *hid)
return -ENODEV;
}
 
+   if (hdesc->bLength < sizeof(struct hid_descriptor)) {
+   dbg_hid("hid descriptor is too short\n");
+   return -EINVAL;
+   }
+
hid->version = le16_to_cpu(hdesc->bcdHID);
hid->country = hdesc->bCountryCode;
 
-   for (n = 0; n < hdesc->bNumDescriptors; n++)
+   num_descriptors = min_t(int, hdesc->bNumDescriptors,
+  (hdesc->bLength - offset) / sizeof(struct hid_class_descriptor));
+
+   for (n = 0; n < num_descriptors; n++)
if (hdesc->desc[n].bDescriptorType == HID_DT_REPORT)
rsize = le16_to_cpu(hdesc->desc[n].wDescriptorLength);
 
-- 
2.7.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: Type-C port on the Asmedia ASM1142

[Mathias Nyman]

On 27.09.2017 23:15, Adrian Bocaniciu wrote:

On Wed, 27 Sep 2017 11:03:41 +0300
Mathias Nyman  wrote:


Ok, please let me know which register you refer to, I'd like to get this fixed 
as soon as possible.
Based on what you say I suspect that you talk about the SBRN (Serial bus 
release number).

The early xhci 1.1 spec that was used to write USB3.1 SSP support stated that 
SBRN contain
the serial bus specification release, (in hex) with examples of 30h for USB 3.0 
and 31h for USB 3.1

Driver uses this to determine if hosts supports USB 3.0 or usb 3.1

I see that the current public xhci spec only mention 30h (USB 3.0), and in a 
way that it can be
interpreted as 30 being the only option.
If this is the case then SBRN itself would be completely useless.
Why have a register with the purpose of telling which serial bus release number 
the hardware
supports always forced to 30h?

Yes, the first Intel Alpine ridge based USB 3.1 SSP 10Gbps xHCI hosts had this 
as 30,
Newer Intel USB 3.1 SSP capable 10Gbps xHCI hosts have it set to 31h

If vendors have interpreted it as "SBRN must equal 30h" then we need to work
around that in the driver.

We can check if the host supports USB 3.1 from the ports supported protocol 
capability,
see xhci 7.2 xHCI supported protocol capability, major and minor revision 
fields. These
should at least contain major=3 and minor=1 for USB 3.1 capable ports.

That at least is unambiguous in all xhci specs (early, and current public)



Yes, indeed, your guess is correct. I was writing about SBRN.

In the function "xhci_pci_setup", from the file "drivers/usb/host/xhci-pci.c", SBRN is read 
and stored in "xhci->sbrn".

Then, in the function "xhci_gen_setup", from the file "drivers/usb/host/xhci.c", the value 
of "xhci->sbrn" is checked. If it is 0x31, then support for 10 Gb/s is assumed.

This check was introduced in a patch from the 1st October 2015. It must have 
worked once, because I have seen some Linux screen shots with the output of 
lsusb showing some xHCI controller with 10 Gb/s support.

I am not aware of any USB 3.1 controllers that existed in 2015 and that could 
have SBRN equal to 0x31, except for some earlier ASMedia controllers. AFAIK, 
there were at least 2 versions before ASM 1142, so one or both of them must 
have had SBRN equal to 0x31.

I have verified on many motherboards that both Alpine Ridge and ASM 1142 have SBRN 
equal to 0x30. Moreover, the ASM 1142 datasheet says clearly that SBRN is 0x30. 
Therefore, I believe that ASMedia has understood the xHCI specification exactly as 
it is written, i.e. that SBRN must be 0x30, and they have reverted its value from 
the earlier 0x31 to 0x30. There are at least 2 newer ASMedia USB 3.1 controllers 
(2142 & 3142). I do not know what value they use for SBRN, but 0x30 is likely.


Nevertheless, even if we ignore this history of unpredictable SBRN values, it is wrong to 
believe that any USB 3.1 controller supports 10 Gb/s operation. The evidence for this is 
all the b*s*t advertising about "USB 3.1 Gen 1", i.e. 5 Gb/s (4 Gb/s actually) 
speed.

Moreover, very soon USB 3.2 devices will appear. USB 3.2 introduces 2 more 
speeds, so a USB 3.2 xHCI controller will support some or all of 4 speeds: 1 * 
5 Gb/s (actually 4 Gb/s), 2 * 5 Gb/s (actually 8 Gb/s), 1 * 10 Gb/s (i.e. 10 
Gb/s) and 2 * 10 Gb/s (i.e. 20 Gb/s). It is very likely that some USB 3.2 xHCI 
controllers will not support all speeds, especially because the 2-lane speeds 
are possible only over Type C connectors, so the same controller will support 
all speeds on some motherboards but only some of them when used with Type A 
connectors.

In conclusion, the supported speeds must be detected independently of the USB 
release number.

The xHCI Specification describes an appropriate source for this information, at the "xHCI 
Supported Protocol Capability", in the "Protocol Speed ID" Dwords.

There are chances that I might have time during this weekend to test some USB 
3.1 xHCI controllers to see how this works.

If you can work on this sooner, you are welcome.


While reading the extra capability registers should be easy, what should be 
thought carefully is how to change the existing structures which store 
information about the xHCI controller, to accomodate the extra speeds that will 
be available soon and the fact that the set of supported speeds is not 
necessarily determined by the USB version number.

Like I said, while I patched my kernel and now my xHCI controllers are 
recognized as supporting 10 Gb/s, the SSDs with USB-SATA bridges that I have 
connected are still not recognized as also supporting 10 Gb/s. I believe that 
the problem is caused by other parts of the xHCI specification that are not 
implemented, but I did not have time yet to identify them.



To sum it up:

Ways to deduce host controller capable speeds:

1. From SBRN
Good: + easy, the current way
Bad:  - unreliable, public spec currently forces value to be 30h (USB 3.0) 
so many vendors 

Re: Type-C port on the Asmedia ASM1142

[Felipe Balbi]

Hi,

Mathias Nyman  writes:

[snip]

>> Like I said, while I patched my kernel and now my xHCI controllers
>> are recognized as supporting 10 Gb/s, the SSDs with USB-SATA bridges
>> that I have connected are still not recognized as also supporting 10
>> Gb/s. I believe that the problem is caused by other parts of the xHCI
>> specification that are not implemented, but I did not have time yet
>> to identify them.
>>
>
> To sum it up:
>
> Ways to deduce host controller capable speeds:
>
> 1. From SBRN
>  Good: + easy, the current way
>
>  Bad: - unreliable, public spec currently forces value to be 30h
>  (USB 3.0) so many vendors (30h) for 3.1 SSP capable hosts
>
>  Bad: - PCI centric, SBRN is in pci config space, platform devices
>  need their own way to set xhci->sbrn value
>
>  Bad: - assumes host vendors only use 3.1 (30h) for 10Gbps SSP
>  hosts.
>
>  Bad: - assumes a future spec revision always implies new
>  mandatory supported speeds
>
> 2. From xHCI supported protocol capability (extended capability for
> xHCI ports) major and minor revision number
>  Good: + spec is clear on this issue, can't be interpreted in
>  different ways.
>
>  Bad: - assumes host vendors only use 3.1 (30h) for 10Gbps SSP
>  capable hosts. (seems true so far for hosts)
>
>  Bad: - assumes a future spec release always implies new mandatory
>  supported speeds
>
> 3. From xHCI supported protocol capability (extended capability for
> xHCI ports) PSI Dwords
>  Good: +spec is clear on this issue, can't be interpreted in
>  different ways.
>
>  Good: +get actual real numerical value of supported speed, like
>  5830Mb/s
>
>  Bad: -PSI Dwords are optional, many vendors don't have them.

Indeed, they are optional. However if PSIC is 0, then the default
mapping *must* be assumed. Default mapping, on public spec, only species
up to 5Gbps. So this means that SSP hosts *must* have PSIC > 0.

> I already wrote xhci support for parsing PSI Dwords for xHCI and
> create the usb 3.1 root hub descriptor out of it.
>
> If hosts doesnt have PSI Dwords then driver uses the default USB speed
> ID mappings for root hub (xhci 7.2.2.1.)

which only define speeds up to 5Gbps

> To me it looks like first step is to use xHCI supported protocol
> capability major and minor fields to get USB release number, and also
> set initial supported speed.
>
> After this we can check if we a PSI Dwords list exists, and tune the
> supported speed for the host (and root hub)

Actually, I think we should go the other way around:

psic = read_psic_from_register();

if (psic)
setup_supported_speeds_based_on_psic(xhci, psic);
else
setup_supported_speeds_using_default_mappings(xhci);

This should be enough to sort everything out (assuming no-quirky HW, of
course). Even if a new spec is released defining a new default mapping
for 10Gbps and/or adding 0x31 to SBRN, we really don't need to rely on
that.

Well, maybe we can rely on SBRN to append a new default
mapping. Something like (also considering possible quirky hosts):

static bool xhci_30_supports_ssp(struct xhci_hcd *xhci)
{
sbrn = read_sbrn_maybe(xhci);
if (!sbrn)
return false;

if (sbrn == 0x30 && xhci->quirks & XHCI_SBRN30_SUPPORTS_SSP)
return true;

return false;
}

static void setup_supported_speeds_using_default_mappings(struct xhci_hcd *xhci)
{
[...]

sbrn = read_sbrn_maybe(xhci);
if (!sbrn)
return;

/*
 * xhci revision foo.bar defines a new SBRN of 0x31 for USB3.1
 * hosts.
 *
 * That same spec revision, also defines a new default mapping
 * for 10Gbps. Let's append it.
 *
 * Note that there are known quirky hosts which have SBRN equals
 * to 0x30, but are, indeed, 10Gbps-capable hosts which PSIC
 * equal to 0. Also handle these cases.
 */
if (sbrn == 0x31 || xhci_30_supports_ssp(xhci))
append_10gbps_default_mapping(xhci);

[...]
}

> Other things to consider is that we assume PSI IDs 1,2,3,4 always maps
> to Full, Low, High and SuperSpeed.

That's the default mapping. If PSIC > 0 you don't need default
mapping. Or rather, shouldn't need. Imagine the following situation:

Currently xhci always adds default mapping. Now say PSIC is > 0 and ID 3
is, according to PSI Dwords, used for 10Gbps. Now you're gonna have ID 3
being used for 10Gbps and 480Mbps.

IMHO, the first step should be extracting all the current magic (without
changing it in any way) to a separate function. Then you can start
reasoning about how to best parse/decode it.

> I haven't seen those mapped any other way, but I think PSI Dwords
> don't force this mapping.

they don't appear to, no. Only default mapping forces that.

-- 
balbi


signature.asc
Description: PGP signature

usb/misc/usbtest: null-ptr-deref in usbtest_probe/get_endpoints

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).

It seems that out pointer ends up being NULL and kernel crashes on
access to out->desc.bEndpointAddress.

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x81 has invalid
maxpacket 2040, setting to 64
usb 1-1: config 2 interface 0 altsetting 206 has an invalid endpoint
with address 0xFF, skipping
usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x5 has an
invalid bInterval 255, changing to 4
usb 1-1: config 2 interface 0 has no altsetting 0
usb 1-1: New USB device found, idVendor=0525, idProduct=a4a0
usb 1-1: New USB device strings: Mfr=0, Product=185, SerialNumber=1
usb 1-1: Product: a
usb 1-1: SerialNumber: a
gadgetfs: configuration #2
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted
4.14.0-rc2-42664-gaf7d1481b3cb #297
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: 880064328000 task.stack: 880064398000
RIP: 0010:get_endpoints drivers/usb/misc/usbtest.c:208
RIP: 0010:usbtest_probe+0x114f/0x1ef0 drivers/usb/misc/usbtest.c:2706
RSP: 0018:88006439e358 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 11000c873c33
RDX:  RSI: 0006 RDI: 0002
RBP: 88006439e5e8 R08: 88006439dd60 R09: 11000c873bc5
R10: 880064328000 R11: 0005 R12: 88006197e698
R13: 880067755d28 R14: 88006439e5c0 R15: 88006782ddc0
FS:  () GS:88006c90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20002e07 CR3: 639a9000 CR4: 06e0
Call Trace:
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 8b bd 30 fe ff ff e8 d1 60 05 fe 48 b8 00 00 00 00 00 fc ff df
41 89 5f 10 49 8b 9e c0 fe ff ff 48 8d 7b 02 48 89 fa 48 c1 ea 03 <0f>
b6 04 02 48 89 fa 83 e2 07 38 d0 7f 09 84 c0 74 05 e8 ba 5f
RIP: usbtest_probe+0x114f/0x1ef0 RSP: 88006439e358
---[ end trace 005817b8c41d50d0 ]---
--
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

DMAR faults with VL805 xHCI controller since 4.13

[Hao Wei Tee]

I've been getting xhci_hcd probe failures since 4.13, seemingly caused by DMAR 
faults:

xhci_hcd :03:00.0: xHCI Host Controller
xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2
DMAR: DRHD: handling fault status reg 3
DMAR: [DMA Read] Request device [03:00.0] fault addr de483000 [fault reason 
01] Present bit in root entry is clear

dmar_fault: 1638936 callbacks suppressed
...
dmar_fault: 2334570 callbacks suppressed
...
dmar_fault: 2322965 callbacks suppressed
...
dmar_fault: 2322989 callbacks suppressed
...
xhci_hcd :03:00.0: can't setup: -110
xhci_hcd :03:00.0: USB bus 2 deregistered
xhci_hcd :03:00.0: init :03:00.0 fail, -110
xhci_hcd: probe of :03:00.0 failed with error -110

Presumably this has to do with the new dma-mapping things in 4.13. If VT-d is 
disabled, no more errors occur.

I have no idea how to investigate this.

I'm not sure if the fault lies in the USB driver or elsewhere. Please forgive 
me if this ends up being the wrong list.

-- 
Hao Wei
--
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

[RFC PATCH 0/2] usb: typec: alternate mode bus

[Heikki Krogerus]

Hi guys,

The bus allows SVID specific communication with the partners to be
handled in separate drivers for each alternate mode.

Alternate mode handling happens with two separate logical devices:
1. Partner alternate mode devices which represent the alternate modes
   on the partner. The driver for them will handle the alternate mode
   specific communication with the partner using VDMs.
2. Port alternate mode devices which represent connections from the
   USB Type-C port to devices on the platform.

The drivers will be bind to the partner alternate modes. The alternate
mode drivers will need to deliver the result of the negotiated pin
configurations to the rest of the platform (towards the port alternate
mode devices). This series includes API for that, however, not the
final implementation yet.

The connections to the other devices on the platform the ports have
can be described by using the remote endpoint concept [1][2] on ACPI
and DT platforms, but I have no solution for the "platform data" case
where we have neither DT nor ACPI to describe the connections for us.

[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/acpi/dsd/graph.txt


Heikki Krogerus (2):
  usb: typec: Simple bus for alternate modes
  usb: typec: dummy alternate mode driver

 drivers/usb/typec/Kconfig  |   2 +
 drivers/usb/typec/Makefile |   3 +
 drivers/usb/typec/altmode.c| 249 +
 drivers/usb/typec/altmode.h|  46 ++
 drivers/usb/typec/altmodes/Kconfig |   9 ++
 drivers/usb/typec/altmodes/Makefile|   2 +
 drivers/usb/typec/altmodes/dummy.c | 133 ++
 drivers/usb/typec/{typec.c => class.c} | 128 -
 drivers/usb/typec/tcpm.c   |   2 +-
 include/linux/usb/typec.h  |   6 +-
 include/linux/usb/typec_altmode.h  |  65 +
 11 files changed, 608 insertions(+), 37 deletions(-)
 create mode 100644 drivers/usb/typec/altmode.c
 create mode 100644 drivers/usb/typec/altmode.h
 create mode 100644 drivers/usb/typec/altmodes/Kconfig
 create mode 100644 drivers/usb/typec/altmodes/Makefile
 create mode 100644 drivers/usb/typec/altmodes/dummy.c
 rename drivers/usb/typec/{typec.c => class.c} (93%)
 create mode 100644 include/linux/usb/typec_altmode.h

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

[RFC PATCH 2/2] usb: typec: dummy alternate mode driver

[Heikki Krogerus]

Example alternate mode driver.

Meant only to give an idea how a real alternate mode driver
*could* look like!

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig   |   2 +
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/altmodes/Kconfig  |   9 +++
 drivers/usb/typec/altmodes/Makefile |   2 +
 drivers/usb/typec/altmodes/dummy.c  | 133 
 5 files changed, 147 insertions(+)
 create mode 100644 drivers/usb/typec/altmodes/Kconfig
 create mode 100644 drivers/usb/typec/altmodes/Makefile
 create mode 100644 drivers/usb/typec/altmodes/dummy.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 103cb8bce3e7..c7b3414125ca 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -35,4 +35,6 @@ endif
 
 source "drivers/usb/typec/ucsi/Kconfig"
 
+source "drivers/usb/typec/altmodes/Kconfig"
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index e157cc4526f0..bb98657d4927 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm.o
 obj-y  += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
+obj-y  += altmodes/
diff --git a/drivers/usb/typec/altmodes/Kconfig 
b/drivers/usb/typec/altmodes/Kconfig
new file mode 100644
index ..6d25ad369745
--- /dev/null
+++ b/drivers/usb/typec/altmodes/Kconfig
@@ -0,0 +1,9 @@
+
+menu "USB Type-C Alternate Mode drivers"
+
+config TYPEC_DUMMY_ALTMODE
+   tristate "Dummy Alternate Mode driver"
+   help
+ Driver for Dummy Alternate Mode.
+
+endmenu
diff --git a/drivers/usb/typec/altmodes/Makefile 
b/drivers/usb/typec/altmodes/Makefile
new file mode 100644
index ..a71e62b0acf5
--- /dev/null
+++ b/drivers/usb/typec/altmodes/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_TYPEC_DUMMY_ALTMODE)  += dummy_altmode.o
+dummy_altmode-y:= dummy.o
diff --git a/drivers/usb/typec/altmodes/dummy.c 
b/drivers/usb/typec/altmodes/dummy.c
new file mode 100644
index ..6225cc955726
--- /dev/null
+++ b/drivers/usb/typec/altmodes/dummy.c
@@ -0,0 +1,133 @@
+/**
+ * USB Typec-C DisplayPort Alternate Mode driver
+ *
+ * Copyright (C) 2017 Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* This is an example of an USB Type-C alternate mode driver.  */
+
+#include 
+#include 
+#include 
+
+#define DUMMY_SVID 0x
+
+/* Dummy vendor specific commands */
+#define CMD_DUMMY1 VDO_CMD_VENDOR(1)
+#define CMD_DUMMY2 VDO_CMD_VENDOR(2)
+
+/* Dummy pin configurations */
+enum {
+   DUMMY_CONF_USB,
+   DUMMY_CONF_A,
+   DUMMY_CONF_B,
+};
+
+static void dummy_attention(struct typec_altmode *altmode,
+   u32 header, u32 *vdo, int count)
+{
+   /* Process attention.. */
+}
+
+static void dummy_altmode_vdm(struct typec_altmode *altmode,
+ u32 header, u32 *vdo, int count)
+{
+   int cmd_type = PD_VDO_CMDT(header);
+   int cmd = PD_VDO_CMD(header);
+   u32 message[2];
+
+   switch (cmd_type) {
+   case CMDT_INIT:
+   /* Dummy altmode driver supports currently only DFP */
+
+   if (cmd == CMD_ATTENTION)
+   dummy_attention(altmode, header, vdo, count);
+   break;
+   case CMDT_RSP_ACK:
+   switch (cmd) {
+   case CMD_DISCOVER_MODES:
+   /* We could store the modes here. */
+   break;
+   case CMD_ENTER_MODE:
+   /* Prepare the platform for pin configuration A */
+   if (typec_altmode_notify(altmode, DUMMY_CONF_A, NULL)) {
+   /* Exit Mode? */
+   break;
+   }
+
+   /* Queue dummy1 command for pin configuration A */
+   message[0] = VDO(DUMMY_SVID, 1, CMD_DUMMY1);
+   message[1] = 0x12345678 | DUMMY_CONF_A;
+   typec_altmode_send_vdm(altmode, message[0],
+  &message[1], 2);
+
+   break;
+   case CMD_EXIT_MODE:
+   /*
+* Tell the the platform to put the port to go back to
+* USB mode
+*/
+   typec_altmode_notify(altmode, DUMMY_CONF_USB, NULL);
+
+   break;
+   case CMD_DUMMY1:
+   /* We are happy */
+   break;
+   default:
+   break;
+ 

[RFC PATCH 1/2] usb: typec: Simple bus for alternate modes

[Heikki Krogerus]

Bus for binding SVID specific drivers to the altnernate mode
devices.

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Makefile |   2 +
 drivers/usb/typec/altmode.c| 249 +
 drivers/usb/typec/altmode.h|  46 ++
 drivers/usb/typec/{typec.c => class.c} | 128 -
 drivers/usb/typec/tcpm.c   |   2 +-
 include/linux/usb/typec.h  |   6 +-
 include/linux/usb/typec_altmode.h  |  65 +
 7 files changed, 461 insertions(+), 37 deletions(-)
 create mode 100644 drivers/usb/typec/altmode.c
 create mode 100644 drivers/usb/typec/altmode.h
 rename drivers/usb/typec/{typec.c => class.c} (93%)
 create mode 100644 include/linux/usb/typec_altmode.h

diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b77688ce1f16..e157cc4526f0 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,4 +1,6 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+typec-y:= class.o
+typec-y+= altmode.o
 obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
 obj-y  += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
diff --git a/drivers/usb/typec/altmode.c b/drivers/usb/typec/altmode.c
new file mode 100644
index ..81fe0af37da0
--- /dev/null
+++ b/drivers/usb/typec/altmode.c
@@ -0,0 +1,249 @@
+/**
+ * USB Type-C Alternate Mode bus
+ *
+ * Copyright (C) 2017 Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+
+#include "altmode.h"
+
+/* -- 
*/
+/* Common API */
+
+/**
+ * typec_altmode_notify - Communicate with the platform
+ * @altmode: Handle to the alternate mode
+ * @conf: Alternate mode specific configuration value
+ * @data: Alternate mode specific data to be passed to the partner
+ *
+ * The primary purpose for this function is to allow the alternate mode drivers
+ * to tell the platform which pin configuration has been negotiated with the
+ * partner, but communication to the other direction is also possible, so low
+ * level device drivers can also send notifications to the alternate mode
+ * drivers. The actual communication will be specific to every alternate mode.
+ */
+int typec_altmode_notify(struct typec_altmode *altmode,
+unsigned long conf, void *data)
+{
+   struct typec_altmode *partner;
+
+   if (!altmode)
+   return 0;
+
+   if (!altmode->partner)
+   return -ENODEV;
+
+   partner = altmode->partner;
+
+   /*
+* This is where we will later pass the data to the remote-endpoints,
+* but for now simply passing the data to the port.
+*
+* More information about the remote-endpoint concept:
+*   Documentation/acpi/dsd/graph.txt
+*   Documentation/devicetree/bindings/graph.txt
+*
+* Check drivers/base/property.c to see the API for the endpoint
+* handling (the fwnode_graph* functions).
+*/
+
+   if (partner->ops && partner->ops->notify)
+   return partner->ops->notify(partner, conf, data);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(typec_altmode_notify);
+
+/**
+ * typec_altmode_send_vdm - Send Vendor Defined Messages to the partner
+ * @altmode: Alternate mode handle
+ * @header: VDM Header
+ * @vdo: Array of Vendor Defined Data Objects
+ * @count: Number of Data Objects
+ *
+ * The alternate mode drivers use this function for SVID specific communication
+ * with the partner. The port drivers use it to deliver the Structured VDMs
+ * received from the partners to the alternate mode drivers.
+ */
+int typec_altmode_send_vdm(struct typec_altmode *altmode,
+  u32 header, u32 *vdo, int count)
+{
+   struct typec_altmode *partner;
+
+   if (!altmode)
+   return 0;
+
+   if (!altmode->partner)
+   return -ENODEV;
+
+   partner = altmode->partner;
+
+   if (partner->ops && partner->ops->vdm)
+   partner->ops->vdm(partner, header, vdo, count);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(typec_altmode_send_vdm);
+
+void typec_altmode_set_drvdata(struct typec_altmode *altmode, void *data)
+{
+   dev_set_drvdata(&altmode->dev, data);
+}
+EXPORT_SYMBOL_GPL(typec_altmode_set_drvdata);
+
+void *typec_altmode_get_drvdata(struct typec_altmode *altmode)
+{
+   return dev_get_drvdata(&altmode->dev);
+}
+EXPORT_SYMBOL_GPL(typec_altmode_get_drvdata);
+
+/* -- 
*/
+/* API for the alternate mode drivers */
+
+/**
+ * typec_altmode_register_ops - Register alternate mode specific operations
+ * @altmode: Handle to

Re: Mouse freezes on button depression

[Christian Bullow]

Hi Oliver



That tells us practically nothing. If you press any button nothing
happens? Anything in dmesg?

Regards
Oliver

There is nothing on dmesg. I used dmesg -wH to view output as/when 
anything was occuring and nothing did. Once I use a DPI switch the 
cursor stops moving and appears unresponsive to pressing any of the 
buttons. The only thing I can do is unplug and replug it in, which you 
will see in the output.




[Sep26 13:34] usb 1-1.1: USB disconnect, device number 18
[  +2.269389] usb 1-1.2: new full-speed USB device number 20 using ehci-pci
[  +0.113788] usb 1-1.2: New USB device found, idVendor=1044, idProduct=7a13
[  +0.04] usb 1-1.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[  +0.03] usb 1-1.2: Product: MSP430-USB Mouse
[  +0.02] usb 1-1.2: Manufacturer: Texas Instruments
[  +0.02] usb 1-1.2: SerialNumber: 8C2F0C5132000C00
[  +0.030638] input: Texas Instruments MSP430-USB Mouse as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:1044:7A13.002B/input/input60
[  +0.060274] hid-generic 0003:1044:7A13.002B: input,hidraw0: USB HID 
v1.01 Keyboard [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.2/input0
[  +0.003052] input: Texas Instruments MSP430-USB Mouse as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:1044:7A13.002C/input/input61
[  +0.060784] hid-generic 0003:1044:7A13.002C: input,hidraw2: USB HID 
v1.01 Mouse [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.2/input1
[  +0.003790] input: Texas Instruments MSP430-USB Mouse as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2/0003:1044:7A13.002D/input/input62
[  +0.060828] hid-generic 0003:1044:7A13.002D: input,hiddev0,hidraw3: 
USB HID v1.01 Mouse [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.2/input2

[ +10.045255] hid-generic 0003:1044:7A13.002E: timeout initializing reports
[  +0.000373] hid-generic 0003:1044:7A13.002E: hiddev0,hidraw5: USB HID 
v1.01 Device [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.2/input3

[Sep26 13:35] usb 1-1.2: USB disconnect, device number 20
[  +1.656786] usb 1-1.1: new full-speed USB device number 21 using ehci-pci
[  +0.113879] usb 1-1.1: New USB device found, idVendor=1044, idProduct=7a13
[  +0.04] usb 1-1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[  +0.03] usb 1-1.1: Product: MSP430-USB Mouse
[  +0.02] usb 1-1.1: Manufacturer: Texas Instruments
[  +0.02] usb 1-1.1: SerialNumber: 8C2F0C5132000C00
[  +0.030125] input: Texas Instruments MSP430-USB Mouse as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:1044:7A13.002F/input/input63
[  +0.060673] hid-generic 0003:1044:7A13.002F: input,hidraw0: USB HID 
v1.01 Keyboard [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.1/input0
[  +0.003078] input: Texas Instruments MSP430-USB Mouse as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1/0003:1044:7A13.0030/input/input64
[  +0.060770] hid-generic 0003:1044:7A13.0030: input,hidraw2: USB HID 
v1.01 Mouse [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.1/input1
[  +0.003743] input: Texas Instruments MSP430-USB Mouse as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.2/0003:1044:7A13.0031/input/input65
[  +0.060768] hid-generic 0003:1044:7A13.0031: input,hiddev0,hidraw3: 
USB HID v1.01 Mouse [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.1/input2

[ +10.169147] hid-generic 0003:1044:7A13.0032: timeout initializing reports
[  +0.000267] hid-generic 0003:1044:7A13.0032: hiddev0,hidraw5: USB HID 
v1.01 Device [Texas Instruments MSP430-USB Mouse] on 
usb-:00:1a.0-1.1/input3


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

Re: [RFC PATCH 2/2] usb: typec: dummy alternate mode driver

[Felipe Balbi]

Hi,

Heikki Krogerus  writes:
> +MODULE_DESCRIPTION("DisplayPort Alternate Mode");

huh?

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC PATCH 2/2] usb: typec: dummy alternate mode driver

[Heikki Krogerus]

On Thu, Sep 28, 2017 at 03:22:35PM +0300, Felipe Balbi wrote:
> Heikki Krogerus  writes:
> > +MODULE_DESCRIPTION("DisplayPort Alternate Mode");
> 
> huh?

Copy paste :-)


Cheers,

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

[RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allows to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda 
---
There are few things for discussion (IMO):
1. vendor specific connectors, I have added them here, but maybe better is
   to place them in separate files.
2. physical connector description - I have split it to three properties:
   type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
   This tripled is able to describe all USB-standard connectors, but there
   are also impossible combinations, for example(c, *, micro). Maybe better
   would be to just enumerate all possible connectors in include file.
3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
   Controller. Maybe other functions should be also assigned:
   HS, SS, CC, SBU, ... whatever. Maybe functions should be described
   as an additional property of remote node?
...

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..f3a4e85122d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,49 @@
+USB Connector
+=
+
+Required properties:
+- compatible: "usb-connector"
+  connectors with vendor specific extensions can add one of additional
+  compatibles:
+"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
+- type: the USB connector type: "a", "b", "ab", "c"
+- max-mode: max USB speed mode supported by the connector:
+  "ls", "fs", "hs", "ss", "ss+"
+
+Optional properties:
+- label: a symbolic name for the connector
+- size: size of the connector, should be specified in case of
+  non-standard USB connectors: "mini", "micro", "powered"
+
+Required nodes:
+- any data bus to the connector should be modeled using the
+  OF graph bindings specified in bindings/graph.txt.
+  There should be exactly one port with at least one endpoint to
+  different device nodes. The first endpoint (reg = <0>) should
+  point to USB Interface Controller.
+
+Example
+---
+
+musb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-connector";
+   label = "usb";
+   type = "b";
+   size = "micro";
+   max-mode = "hs";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   musb_con_usb_in: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&muic_usb_out>;
+   };
+
+   musb_con_mhl_in: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mhl_out>;
+   };
+   };
+};
-- 
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

[RFC PATCH 2/4] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda 
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 47 --
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e30bae4cf878..39b1ca0ef4cd 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -135,6 +135,28 @@
"RCV", "HPOUT3R";
status = "okay";
};
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin", "usb-connector";
+   label = "micro-usb";
+   type = "b";
+   size = "micro";
+   max-mode = "hs";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   musb_con_to_muic: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&muic_to_musb_con>;
+   };
+   musb_con_to_mhl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mhl_to_musb_con>;
+   };
+   };
+   };
 };
 
 &adc {
@@ -768,9 +790,22 @@
clocks = <&pmu_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <&hdmi_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <&musb_con_to_mhl>;
+   };
};
};
};
@@ -787,6 +822,12 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   port {
+   muic_to_musb_con: endpoint@0 {
+   remote-endpoint = <&musb_con_to_muic>;
+   };
+   };
};
 
regulators {
-- 
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

[RFC PATCH 0/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

This patchset introduces USB connector bindings, together with working example.
I have added comments in relevant patches to describe possible issues.

Regards
Andrzej


Andrzej Hajda (3):
  dt-bindings: add bindings for USB physical connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  extcon: add possibility to get extcon device by of node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../bindings/connector/usb-connector.txt   | 49 +++
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 47 ++-
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 98 +-
 include/linux/extcon.h |  6 ++
 5 files changed, 228 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

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

[RFC PATCH 3/4] extcon: add possibility to get extcon device by of node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda 
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..fdb8c1d767c1 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(&extcon_dev_list_lock);
+   list_for_each_entry(edev, &extcon_dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto end;
+   edev = ERR_PTR(-EPROBE_DEFER);
+end:
+   mutex_unlock(&extcon_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(&extcon_dev_list_lock);
-   list_for_each_entry(edev, &extcon_dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(&extcon_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(&extcon_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 744d60ca80c3..2f88e7491672 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -261,6 +261,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -382,6 +383,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
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

[RFC PATCH 4/4] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski 

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski 
Signed-off-by: Andrzej Hajda 
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 98 ++--
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 5131bfb94f06..6f40cbc2445e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -78,6 +80,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2102,6 +2108,78 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(&ctx->extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_graph_get_remote_node(musb, -1, 0);
+   of_node_put(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2201,13 +2279,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = &sii8620_bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(&ctx->bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2216,9 +2301,16 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->dev)->irq);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+  &ctx->extcon_nb);
+

Re: [PATCH V3] r8152: add Linksys USB3GIGV1 id

[Doug Anderson]

Hi,

On Wed, Sep 27, 2017 at 5:07 PM, Grant Grundler  wrote:
>>>  #define DELL_VENDOR_ID 0x413C
>>>  #define REALTEK_VENDOR_ID  0x0bda
>>>  #define SAMSUNG_VENDOR_ID  0x04e8
>>> +#define LINKSYS_VENDOR_ID  0x13b1
>>>  #define LENOVO_VENDOR_ID   0x17ef
>>
>> Slight nit that "LI" sorts after "LE".  You got it right in the other case...
>
> The list isn't sorted by any rational thing I can see.  I managed to
> check my OCD reaction to sort the list numerically. :)

Whoops, you're right.  It seems to be in a random order.  I just saw
LE, LI, and N sorted properly and jumped to a conclusion.  In any
case, if it's all the same to you it'd be nice if you were consistent
between LENOVO/LINKSYS in the two files.  :-P

-Doug
--
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 14/17] phy: qcom-qusb2: Set vbus sw-override signal in device mode

[Jack Pham]

Hi Manu,

On Thu, Sep 28, 2017 at 09:30:38AM +0530, Manu Gautam wrote:
> On 9/28/2017 12:46 AM, Jack Pham wrote:
> > On Wed, Sep 27, 2017 at 10:57:41AM -0700, Jack Pham wrote:
> >> On Wed, Sep 27, 2017 at 02:29:10PM +0530, Manu Gautam wrote:
> >>> VBUS signal coming from PHY must be asserted in device for
> >>> controller to start operation or assert pull-up. For some
> >>> platforms where VBUS line is not connected to PHY there is
> >>> HS_PHY_CTRL register in QSCRATCH wrapper that can be used
> >>> by software to override VBUS signal going to controller.
> >>>
> >>> Signed-off-by: Manu Gautam 
> >>> ---
> >>>  
> >>> +static int qusb2_phy_set_mode(struct phy *phy, enum phy_mode mode)
> >>> +{
> >>> + struct qusb2_phy *qphy = phy_get_drvdata(phy);
> >>> +
> >>> + qphy->mode = mode;
> >>> +
> >>> + /* Update VBUS override in qscratch register */
> >>> + if (qphy->qscratch_base) {
> >>> + if (mode == PHY_MODE_USB_DEVICE)
> >>> + qusb2_setbits(qphy->qscratch_base, QSCRATCH_HS_PHY_CTRL,
> >>> +   UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
> >>> + else
> >>> + qusb2_clrbits(qphy->qscratch_base, QSCRATCH_HS_PHY_CTRL,
> >>> +   UTMI_OTG_VBUS_VALID | SW_SESSVLD_SEL);
> >> Wouldn't this be better off handled in the controller glue driver? Two
> >> reasons I think this patch is unattractive:
> >>
> >> - qscratch_base is part of the controller's register space. Your later
> >>   patch 16/17 ("phy: qcom-qmp: Override lane0_power_present signal in
> >>   device mode") does a similar thing and hence both drivers have to
> >>   ioremap() the same register resource while at the same time avoiding
> >>   request_mem_region() (called by devm_ioremap_resource) to allow it to
> >>   be mapped in both places.
> 
> Right. There is one more reason why qusb2 driver needs qscratch:
> - During runtime suspend, it has to check linestate to set correct  polarity 
> for dp/dm
>   wakeup interrupt in order to detect disconnect/resume ion LS and FS/HS 
> modes.

Ugh, oh yeah. The way I understand we did it in our downstream driver
is still to have the controller driver read the linestate but then pass
the information via additional set_mode() flags which the PHY driver
could use to correctly arm the interrupt trigger polarity.

An alternative would be to access a couple of the debug QUSB2PHY
registers that also provide a reading of the current UTMI linestate. The
HPG mentions them vaguely, and I can't remember if we tested that
interface or not. Assuming it works, would that be preferable to reading
a non-PHY register here?

> >> - VBUS override bit becomes asserted simply because the mode is changed
> >>   to device mode but this is irrespective of the actual VBUS state. This
> >>   could break some test setups which perform a logical disconnect by
> >>   switching off/on VBUS while leaving data lines connected. Controller
> >>   would go merrily along thinking it is still attached to the host.
> >>
> >> Instead maybe this could be tied to EXTCON_USB handling in the glue
> >> driver; though it would need to be an additional notifier on top of
> >> dwc3/drd.c which already handles extcon for host/device mode.
> 
> Yes, dwc3/drd.c currently deals with only EXTCON_USB_HOST. So, for platforms
> where role swap happens using only Vbus or single GPIO this should take care 
> of.
> 
> 
> > That is to say, we'd probably need to split out dwc3-qcom from
> > dwc3-of-simple.c into its own driver (again) in order to add this.
> >
> > Jack
> 
> However, I agree that more appropriate place for lane0-pwr-present and
> vbus override update is dwc3 glue driver. Since we don't have one right now,
> 
> IMO once we have dwc3-qcom driver in place, this handling can be moved from
> PHY to glue driver. Until then we can use this approach to get USB device mode
> working on qcom platforms which are using dwc3-of-simple.c e.g. sdm820
> dragonboard.

Could that be done in this series too? IMO better to get it right in one
shot. Is this aimed for 4.15?

Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb/misc/usbtest: null-ptr-deref in usbtest_probe/get_endpoints

[Alan Stern]

On Thu, 28 Sep 2017, Andrey Konovalov wrote:

> Hi!
> 
> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).
> 
> It seems that out pointer ends up being NULL and kernel crashes on
> access to out->desc.bEndpointAddress.
> 
> gadgetfs: bound to dummy_udc driver
> usb 1-1: new full-speed USB device number 2 using dummy_hcd
> gadgetfs: connected
> gadgetfs: disconnected
> gadgetfs: connected
> usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x81 has invalid
> maxpacket 2040, setting to 64
> usb 1-1: config 2 interface 0 altsetting 206 has an invalid endpoint
> with address 0xFF, skipping
> usb 1-1: config 2 interface 0 altsetting 206 endpoint 0x5 has an
> invalid bInterval 255, changing to 4
> usb 1-1: config 2 interface 0 has no altsetting 0
> usb 1-1: New USB device found, idVendor=0525, idProduct=a4a0
> usb 1-1: New USB device strings: Mfr=0, Product=185, SerialNumber=1
> usb 1-1: Product: a
> usb 1-1: SerialNumber: a
> gadgetfs: configuration #2
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] PREEMPT SMP KASAN
> Modules linked in:
> CPU: 1 PID: 1845 Comm: kworker/1:2 Not tainted
> 4.14.0-rc2-42664-gaf7d1481b3cb #297
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 880064328000 task.stack: 880064398000
> RIP: 0010:get_endpoints drivers/usb/misc/usbtest.c:208
> RIP: 0010:usbtest_probe+0x114f/0x1ef0 drivers/usb/misc/usbtest.c:2706

This looks like a simple logic error.

Alan Stern



Index: usb-4.x/drivers/usb/misc/usbtest.c
===
--- usb-4.x.orig/drivers/usb/misc/usbtest.c
+++ usb-4.x/drivers/usb/misc/usbtest.c
@@ -202,12 +202,13 @@ found:
return tmp;
}
 
-   if (in) {
+   if (in)
dev->in_pipe = usb_rcvbulkpipe(udev,
in->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
+   if (out)
dev->out_pipe = usb_sndbulkpipe(udev,
out->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
-   }
+
if (iso_in) {
dev->iso_in = &iso_in->desc;
dev->in_iso_pipe = usb_rcvisocpipe(udev,

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

usb/serial/visor: slab-out-of-bounds in palm_os_3_probe

[Andrey Konovalov]

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).

There's no check on the connection_info->num_ports value when
iterating over ports.

usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use
usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use
==
BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570
Read of size 1 at addr 8800686daa26 by task kworker/0:1/24

CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42748-gcd3da2fe6c25 #324
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x23d/0x350 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 palm_os_3_probe+0x4e4/0x570 drivers/usb/serial/visor.c:348
 visor_probe+0x11c/0x1e0 drivers/usb/serial/visor.c:463
 usb_serial_probe+0x540/0x4090 drivers/usb/serial/usb-serial.c:903
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4984
 hub_port_connect_change drivers/usb/core/hub.c:5090
 port_event drivers/usb/core/hub.c:5196
 hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
 hub_event+0x11b/0x3f0 drivers/usb/core/hub.c:5206
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772
 kmalloc ./include/linux/slab.h:493
 palm_os_3_probe+0x7c/0x570 drivers/usb/serial/visor.c:325
 visor_probe+0x11c/0x1e0 drivers/usb/serial/visor.c:463
 usb_serial_probe+0x540/0x4090 drivers/usb/serial/usb-serial.c:903
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
 hub_port_connect drivers/usb/core/hub.c:4984
 hub_port_connect_change drivers/usb/core/hub.c:5090
 port_event drivers/usb/core/hub.c:5196
 hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
 hub_event+0x11b/0x3f0 drivers/usb/core/hub.c:5206
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2772:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c

[PATCH V4] r8152: add Linksys USB3GIGV1 id

[Grant Grundler]

This linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
   Bus 002 Device 002: ID 13b1:0041 Linksys

Signed-off-by: Grant Grundler 
---
 drivers/net/usb/cdc_ether.c | 10 ++
 drivers/net/usb/r8152.c |  2 ++
 2 files changed, 12 insertions(+)

V4: use IS_ENABLED() to check CONFIG_USB_RTL8152 is m or y.
(verified by adding #error to the new code and trying to compile
 Thanks Doug for the tip!)
Add LINKSYS vendor #define in same order for both drivers.

V3: for backwards compat, add #ifdef CONFIG_USB_RTL8152 around
the cdc_ether blacklist entry so the cdc_ether driver can
still claim the device if r8152 driver isn't configured.

V2: add LINKSYS_VENDOR_ID to cdc_ether blacklist



diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 8ab281b478f2..677a85360db1 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -547,6 +547,7 @@ static const struct driver_info wwan_info = {
 #define REALTEK_VENDOR_ID  0x0bda
 #define SAMSUNG_VENDOR_ID  0x04e8
 #define LENOVO_VENDOR_ID   0x17ef
+#define LINKSYS_VENDOR_ID  0x13b1
 #define NVIDIA_VENDOR_ID   0x0955
 #define HP_VENDOR_ID   0x03f0
 #define MICROSOFT_VENDOR_ID0x045e
@@ -737,6 +738,15 @@ static const struct usb_device_id  products[] = {
.driver_info = 0,
 },
 
+#if IS_ENABLED(CONFIG_USB_RTL8152)
+/* Linksys USB3GIGV1 Ethernet Adapter */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(LINKSYS_VENDOR_ID, 0x0041, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+#endif
+
 /* ThinkPad USB-C Dock (based on Realtek RTL8153) */
 {
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3062, USB_CLASS_COMM,
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ceb78e2ea4f0..941ece08ba78 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -613,6 +613,7 @@ enum rtl8152_flags {
 #define VENDOR_ID_MICROSOFT0x045e
 #define VENDOR_ID_SAMSUNG  0x04e8
 #define VENDOR_ID_LENOVO   0x17ef
+#define VENDOR_ID_LINKSYS  0x13b1
 #define VENDOR_ID_NVIDIA   0x0955
 
 #define MCU_TYPE_PLA   0x0100
@@ -5316,6 +5317,7 @@ static const struct usb_device_id rtl8152_table[] = {
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7205)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x720c)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7214)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041)},
{REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA,  0x09ff)},
{}
 };
-- 
2.14.2.822.g60be5d43e6-goog

--
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: Type-C port on the Asmedia ASM1142

[Adrian Bocaniciu]

On Thu, 28 Sep 2017 14:09:04 +0300
Felipe Balbi  wrote:

> 
> 
> Actually, I think we should go the other way around:
> 
> psic = read_psic_from_register();
> 
> if (psic)
>   setup_supported_speeds_based_on_psic(xhci, psic);
> else
>   setup_supported_speeds_using_default_mappings(xhci);
> 
> This should be enough to sort everything out (assuming no-quirky HW, of
> course). Even if a new spec is released defining a new default mapping
> for 10Gbps and/or adding 0x31 to SBRN, we really don't need to rely on
> that.
> 
> Well, maybe we can rely on SBRN to append a new default
> mapping. Something like (also considering possible quirky hosts):
> 

I also agree with this.


Meanwhile, the USB 3.2 specification has been published.

While much of it was already known, I was curious to see what names will be 
used fothe additional interface speeds.

I really hoped that there will be no inventions of new words, such as 
HyperEnhancedSuperSpeedExtraPlus.

Fortunately, they gave up on such names and they have chosen a more rational 
approach.

Even if the following words are not officially deprecated, we should really 
stop using them, because in the new specification they have become ambiguous 
and their use conveys no useful information: "SuperSpeed", "Enhanced 
SuperSpeed", "SuperSpeedPlus".

The correct names used in the new specification for the 4 speeds that can be 
supported by a USB 3 interface are: "Gen 1x1", "Gen 2x1", "Gen 1x2" and "Gen 
2x2".

In my opinion, when the speed related code from the xHCI driver will be revised 
now, this opportunity should also be used to purge the junk names "SuperSpeed", 
"Enhanced SuperSpeed" and "SuperSpeedPlus" and replace them with the 4 precise 
names for the 4 speeds supported by USB 3.








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

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

[Rustad, Mark D]

> On Sep 27, 2017, at 9:39 AM, Grant Grundler  wrote:
> 
> On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum  wrote:
>> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:
>>> 
>>> I know that for at least some of the adapters in the CDC Ethernet
>>> blacklist it was claimed that the CDC Ethernet support in the adapter
>>> was kinda broken anyway so the blacklist made sense.  ...but for the
>>> Linksys Gigabit adapter the CDC Ethernet driver seems to work OK, it's
>>> just not quite as full featured / efficient as the R8152 driver.
>>> 
>>> Is that not a concern?  I guess you could tell people in this
>>> situation that they simply need to enable the R8152 driver to get
>>> continued support for their Ethernet adapter?
>> 
>> Hi,
>> 
>> yes, it is a valid concern. An #ifdef will be needed.
> 
> Good idea - I will post V3 shortly.
> 
> I'm assuming you mean to add #ifdef CONFIG_USB_RTL8152 around the
> blacklist entry in cdc_ether driver.

Shouldn't that be an #if IS_ENABLED(...) test, since that seems to be the 
proper way to check configured drivers.

--
Mark Rustad, Networking Division, Intel Corporation



signature.asc
Description: Message signed with OpenPGP

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

[Doug Anderson]

Hi,

On Thu, Sep 28, 2017 at 3:28 PM, Rustad, Mark D  wrote:
>
>> On Sep 27, 2017, at 9:39 AM, Grant Grundler  wrote:
>>
>> On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum  wrote:
>>> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:

 I know that for at least some of the adapters in the CDC Ethernet
 blacklist it was claimed that the CDC Ethernet support in the adapter
 was kinda broken anyway so the blacklist made sense.  ...but for the
 Linksys Gigabit adapter the CDC Ethernet driver seems to work OK, it's
 just not quite as full featured / efficient as the R8152 driver.

 Is that not a concern?  I guess you could tell people in this
 situation that they simply need to enable the R8152 driver to get
 continued support for their Ethernet adapter?
>>>
>>> Hi,
>>>
>>> yes, it is a valid concern. An #ifdef will be needed.
>>
>> Good idea - I will post V3 shortly.
>>
>> I'm assuming you mean to add #ifdef CONFIG_USB_RTL8152 around the
>> blacklist entry in cdc_ether driver.
>
> Shouldn't that be an #if IS_ENABLED(...) test, since that seems to be the 
> proper way to check configured drivers.

Yes, I had the same feedback on v3.  See my comments at
.  Grant has fixed it in
v4.  Please see .  :)

-Doug
--
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 V4] r8152: add Linksys USB3GIGV1 id

[Doug Anderson]

Grant,

On Thu, Sep 28, 2017 at 11:35 AM, Grant Grundler  wrote:
> This linksys dongle by default comes up in cdc_ether mode.
> This patch allows r8152 to claim the device:
>Bus 002 Device 002: ID 13b1:0041 Linksys
>
> Signed-off-by: Grant Grundler 
> ---
>  drivers/net/usb/cdc_ether.c | 10 ++
>  drivers/net/usb/r8152.c |  2 ++
>  2 files changed, 12 insertions(+)

This seems nice to me now.  Thanks for all the fixes!  I'm no expert
in this area, but as far as I know this is ready to go now, so FWIW:

Reviewed-by: Douglas Anderson 
--
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

the imfamous asix ax88179 iommu error

[Will Trives]

Hello,

I just saw a post about VIA controllers triggering IOMMU errors.


Just want to also point out that the ax88179 will also trigger PTE read
errors when using the vendor's driver.

I'm nowhere near an expert but I remember seeing that 'TD fragment' is
supported now or some such, which I take to mean that sg/tso should be
supported with usbnet ?

I'm unclear on whether it can ever work with intel hosts because of an
errata ?

Anyway for anyone that wants to see the error you can grab the vendor
driver:

http://www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE.tar.bz2


This driver was working recently-ish perhaps around the same time the
VIA controllers starting having iommu issues.


Regards,


Will


--
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] extcon: Split out extcon header file for consumer and provider device

[Chanwoo Choi]

The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect the
   state/properties of external connector. Also, it notifies the
   state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
   from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API for
both provider and consumer device driver. To clarify the meaning of
header file and to remove the wrong use-case on consumer device,
this patch separates into extcon.h and extcon-provider.h.

[Description for include/linux/{extcon.h|extcon-provider.h}]
- extcon.h includes the extcon API and data structure for extcon consumer
  device driver. This header file contains the following APIs:
  : Register/unregister the notifier to catch the change of extcon device
  : Get the extcon device instance
  : Get the extcon device name
  : Get the state of each external connector
  : Get the property value of each external connector
  : Get the property capability of each external connector

- extcon-provider.h includes the extcon API and data structure for extcon
  provider device driver. This header file contains the following APIs:
  : Include 'include/linux/extcon.h'
  : Allocate the memory for extcon device instance
  : Register/unregister extcon device
  : Set the state of each external connector
  : Set the property value of each external connector
  : Set the property capability of each external connector

Cc: Felipe Balbi 
Cc: Kishon Vijay Abraham I 
Cc: Greg Kroah-Hartman 
Cc: Sebastian Reichel 
Cc: Lee Jones 
Signed-off-by: Chanwoo Choi 
---
 drivers/extcon/extcon-adc-jack.c  |   2 +-
 drivers/extcon/extcon-arizona.c   |   2 +-
 drivers/extcon/extcon-axp288.c|   2 +-
 drivers/extcon/extcon-gpio.c  |   2 +-
 drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
 drivers/extcon/extcon-intel-int3496.c |   2 +-
 drivers/extcon/extcon-max14577.c  |   2 +-
 drivers/extcon/extcon-max3355.c   |   2 +-
 drivers/extcon/extcon-max77693.c  |   2 +-
 drivers/extcon/extcon-max77843.c  |   2 +-
 drivers/extcon/extcon-max8997.c   |   2 +-
 drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
 drivers/extcon/extcon-rt8973a.c   |   2 +-
 drivers/extcon/extcon-sm5502.c|   2 +-
 drivers/extcon/extcon-usb-gpio.c  |   2 +-
 drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
 drivers/extcon/extcon.h   |   2 +-
 drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
 drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
 drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
 drivers/power/supply/qcom_smbb.c  |   2 +-
 drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
 drivers/usb/phy/phy-tahvo.c   |   2 +-
 drivers/usb/renesas_usbhs/common.h|   2 +-
 include/linux/extcon-provider.h   | 142 ++
 include/linux/extcon.h| 109 +---
 include/linux/mfd/palmas.h|   2 +-
 28 files changed, 173 insertions(+), 130 deletions(-)
 create mode 100644 include/linux/extcon-provider.h

diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 6f6537ab0a79..3877d86c746a 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /**
  * struct adc_jack_data - internal data for adc_jack device driver
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index f84da4a17724..da0e9bc4262f 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index f4fd03e58e37..981fba56bc18 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index ebed22f22d75..ab770adcca7e 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -17,7 +17,7 @@
  * GNU General Public License for more details.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-intel-cht-wc.c 
b/drivers/extcon/extcon-intel-cht-wc.c
index 91a0023074af..7c4bc8c44c3f 100644
--- a/drivers/extcon/extcon-intel-cht-wc.c
+++ b/drivers/extcon/extcon-intel-cht-wc.c
@@ -15,7 +15,7 @@
  * more details.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-intel-int3496.c 
b/drivers/extcon/e

RE: [PATCH] extcon: Split out extcon header file for consumer and provider device

[Yoshihiro Shimoda]

Hi,

> From: Chanwoo Choi
> Sent: Friday, September 29, 2017 9:02 AM
> 
< snip >
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
< snip >
>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-

These two drivers need the modification.
But...

< snip >
> diff --git a/drivers/usb/renesas_usbhs/common.h 
> b/drivers/usb/renesas_usbhs/common.h
> index 8c5fc12ad778..a78764bc23eb 100644
> --- a/drivers/usb/renesas_usbhs/common.h
> +++ b/drivers/usb/renesas_usbhs/common.h
> @@ -17,7 +17,7 @@
>  #ifndef RENESAS_USB_DRIVER_H
>  #define RENESAS_USB_DRIVER_H
> 
> -#include 
> +#include 

Since this driver doesn't use any extcon-provider APIs for now,
we doesn't need the modification, IIUC.

Best regards,
Yoshihiro Shimoda

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

[0-Day CI notification] 0-Day kernel test service will be shut down from Sep 30 3PM to Oct 5

[Philip Li]

Hi all, this is Philip who maintains the 0-Day kernel test service. Thanks for
subscribing to 0-Day kernel testing. We will have lab power down from Oct 1
to Oct 5, so that the service will be shut down from Asia Pacific Time Sep 30 
3PM
and will recover from Oct 6 as soon as we can. Sorry for any inconvenience 
caused
due to the service shut down.

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

[PATCH] USB: serial: qcserial: add Dell DW5818, DW5819

[Shrirang Bagul]

Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series which will by default boot with vid 0x413c and pid's 0x81cf,
0x81d0, 0x81d1,0x81d2.

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

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ebc0beea69d6..eb9928963a53 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -174,6 +174,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card (rev3) */
{DEVICE_SWI(0x413c, 0x81b5)},   /* Dell Wireless 5811e QDL */
{DEVICE_SWI(0x413c, 0x81b6)},   /* Dell Wireless 5811e QDL */
+   {DEVICE_SWI(0x413c, 0x81cf)},   /* Dell Wireless 5819 */
+   {DEVICE_SWI(0x413c, 0x81d0)},   /* Dell Wireless 5819 */
+   {DEVICE_SWI(0x413c, 0x81d1)},   /* Dell Wireless 5818 */
+   {DEVICE_SWI(0x413c, 0x81d2)},   /* Dell Wireless 5818 */
 
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
-- 
2.11.0

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

Re: [PATCH] extcon: Split out extcon header file for consumer and provider device

[Chanwoo Choi]

Hi,

On 2017년 09월 29일 11:03, Yoshihiro Shimoda wrote:
> Hi,
> 
>> From: Chanwoo Choi
>> Sent: Friday, September 29, 2017 9:02 AM
>>
> < snip >
>>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
> < snip >
>>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
> 
> These two drivers need the modification.
> But...
> 
> < snip >
>> diff --git a/drivers/usb/renesas_usbhs/common.h 
>> b/drivers/usb/renesas_usbhs/common.h
>> index 8c5fc12ad778..a78764bc23eb 100644
>> --- a/drivers/usb/renesas_usbhs/common.h
>> +++ b/drivers/usb/renesas_usbhs/common.h
>> @@ -17,7 +17,7 @@
>>  #ifndef RENESAS_USB_DRIVER_H
>>  #define RENESAS_USB_DRIVER_H
>>
>> -#include 
>> +#include 
> 
> Since this driver doesn't use any extcon-provider APIs for now,
> we doesn't need the modification, IIUC.

I don't modify 'drivers/usb/renesas_usbhs/common.h'
on v2 patch. Thanks for your comment.

> 
> Best regards,
> Yoshihiro Shimoda
> 
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics
--
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: dwc3: workaround: disable device-initiated U1/U2

[Ran Wang]

Issue: When the USB controller is configured as a USB device
mode, the device initiates low power when an ACK is pending for a
data packet (DP). When operating in SuperSpeed mode and when the
internal condition for low power (u1/u2) is satisfied, the device
initiates u1/u2 even though it has just received a DPH of the DP
header (DPH). This causes the link to enter and exit low power before
the device sends an ACK for the DP. This behavior can cause a
transaction timeout on the host for the DP. Impact: Depending on the
host transaction timeout value, the host may timeout on the
transaction and the host retries the transfer. If the same issue
happens again, this could result in the host resetting the device and
re-enumerating.

Workaround: Disable USB_DCTL (InitU1Ena, InitU2Ena) bits. As a
result,the device does not initiate lowpower requests; however,
it can still accept low-power requests from the host/hub and enter
low power.

Signed-off-by: Ran Wang 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
 drivers/usb/dwc3/core.c| 2 ++
 drivers/usb/dwc3/core.h| 2 ++
 drivers/usb/dwc3/ep0.c | 4 ++--
 drivers/usb/dwc3/gadget.c  | 7 +++
 5 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7d4f90c16cd4..9afa8e95831e 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -47,6 +47,8 @@ Optional properties:
from P0 to P1/P2/P3 without delay.
  - snps,dis-tx-ipgap-linecheck-quirk: when set, disable u2mac linestate check
during HS transmit.
+ - snps,disable_devinit_u1u2: when set, disable device-initiated U1/U2
+   LPM request in USB device mode.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f13096b0900e..63d599872a43 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1143,6 +1143,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
+   dwc->disable_devinit_u1u2_quirk = device_property_read_bool(dev,
+   "snps,disable_devinit_u1u2");
device_property_read_u8(dev, "snps,tx_de_emphasis",
&tx_de_emphasis);
device_property_read_string(dev, "snps,hsphy_interface",
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 7c2f84dc218a..2be63c1a6ab6 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -896,6 +896,7 @@ struct dwc3_scratchpad_array {
  * 1   - -3.5dB de-emphasis
  * 2   - No de-emphasis
  * 3   - Reserved
+ * @disable_devinit_u1u2_quirk: disable device-initiated U1/U2 request.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
  */
@@ -1057,6 +1058,7 @@ struct dwc3 {
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
+   unsigneddisable_devinit_u1u2_quirk:1;
 
u16 imod_interval;
 };
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 827e376bfa97..bbbf46f031e2 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -391,7 +391,7 @@ static int dwc3_ep0_handle_u1(struct dwc3 *dwc, enum 
usb_device_state state,
return -EINVAL;
 
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
-   if (set)
+   if (set && !dwc->disable_devinit_u1u2_quirk)
reg |= DWC3_DCTL_INITU1ENA;
else
reg &= ~DWC3_DCTL_INITU1ENA;
@@ -413,7 +413,7 @@ static int dwc3_ep0_handle_u2(struct dwc3 *dwc, enum 
usb_device_state state,
return -EINVAL;
 
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
-   if (set)
+   if (set && !dwc->disable_devinit_u1u2_quirk)
reg |= DWC3_DCTL_INITU2ENA;
else
reg &= ~DWC3_DCTL_INITU2ENA;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f064f1549333..61141c6350dc 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3199,6 +3199,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
 {
int ret;
int irq;
+   u32 reg;
 
irq = dwc3_gadget_get_irq(dwc);
if (irq < 0) {
@@ -3275,6 +3276,12 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err4;
}
 
+   if (dwc->disable_devinit_u1u2_quirk) {
+   reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+   reg &= ~(DWC3_DCTL_INITU1ENA |