Re: [PATCH net,stable] qmi_wwan/cdc_ether: add device ID for HP lt2523 (Novatel E371) WWAN card

[Dan Williams]

On Tue, 2017-01-24 at 10:36 +0100, Bjørn Mork wrote:
> Bjørn Mork  writes:
> 
> > From: Dan Williams 
> 
> Woops! I didn't intend to blame this on you Dan.  Sorry. I reused
> your
> commit message, and obviously unintentionally also the "author"
> line...
> 
> But you did create the pattern, so it was only fair to give you the
> credit :)

Hey, I'll take whatever credit I can get!

Dan
--
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 17/17] usb: musb: dsps: make dsps_musb_clear_ep_rxintr() static

[Bin Liu]

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/usb/musb/musb_dsps.c:270:6: warning:
 symbol 'dsps_musb_clear_ep_rxintr' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 92cf68f8f2c1..c171a0f13bc3 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -293,7 +293,7 @@ static void otg_timer(unsigned long _musb)
pm_runtime_put_autosuspend(dev);
 }
 
-void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum)
+static void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum)
 {
u32 epintr;
struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
-- 
1.9.1

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

[PATCH 07/17] usb: musb: da8xx: Add support of suspend / resume

[Bin Liu]

From: Alexandre Bailon 

Implement PM methods specifics for da8xx glue.
The only thing to do is to power off the phy.
As the registers are in retention during suspend,
there is no need to save them.

Signed-off-by: Alexandre Bailon 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/da8xx.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d5766ebeb761..eb5acee82173 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -573,6 +573,34 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int da8xx_suspend(struct device *dev)
+{
+   int ret;
+   struct da8xx_glue *glue = dev_get_drvdata(dev);
+
+   ret = phy_power_off(glue->phy);
+   if (ret)
+   return ret;
+   clk_disable_unprepare(glue->clk);
+
+   return 0;
+}
+
+static int da8xx_resume(struct device *dev)
+{
+   int ret;
+   struct da8xx_glue *glue = dev_get_drvdata(dev);
+
+   ret = clk_prepare_enable(glue->clk);
+   if (ret)
+   return ret;
+   return phy_power_on(glue->phy);
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(da8xx_pm_ops, da8xx_suspend, da8xx_resume);
+
 #ifdef CONFIG_OF
 static const struct of_device_id da8xx_id_table[] = {
{
@@ -588,6 +616,7 @@ static int da8xx_remove(struct platform_device *pdev)
.remove = da8xx_remove,
.driver = {
.name   = "musb-da8xx",
+   .pm = _pm_ops,
.of_match_table = of_match_ptr(da8xx_id_table),
},
 };
-- 
1.9.1

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

[PATCH 10/17] usb: musb: sunxi: Uses the resource-managed extcon API when registering extcon notifier

[Bin Liu]

From: Chanwoo Choi 

This patch just uses the resource-managed extcon API when registering
the extcon notifier.

Signed-off-by: Chanwoo Choi 
Acked-by: Maxime Ripard 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/sunxi.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 64545de4871f..05cab67d4106 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -251,14 +251,14 @@ static int sunxi_musb_init(struct musb *musb)
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0);
 
/* Register notifier before calling phy_init() */
-   ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
+   ret = devm_extcon_register_notifier(glue->dev, glue->extcon,
+   EXTCON_USB_HOST, >host_nb);
if (ret)
goto error_reset_assert;
 
ret = phy_init(glue->phy);
if (ret)
-   goto error_unregister_notifier;
+   goto error_reset_assert;
 
musb->isr = sunxi_musb_interrupt;
 
@@ -267,9 +267,6 @@ static int sunxi_musb_init(struct musb *musb)
 
return 0;
 
-error_unregister_notifier:
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
 error_reset_assert:
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
@@ -293,9 +290,6 @@ static int sunxi_musb_exit(struct musb *musb)
 
phy_exit(glue->phy);
 
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
-
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
 
-- 
1.9.1

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

[PATCH 14/17] usb: musb: Add support for optional VBUS irq to dsps glue layer

[Bin Liu]

From: Tony Lindgren 

We can now configure the PMIC interrupt to provide us VBUS
events. In that case we don't need to constantly poll the
status and can make it optional. This is only wired up
for the mini-B interface on beaglebone.

Note that eventually we should get also the connect status
for the host interface when the am335x internal PM coprocessor
provides us with an IRQ chip. For now, we still need to poll
for the host mode status.

Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 117 ++-
 1 file changed, 93 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9542d20b2785..92cf68f8f2c1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -118,6 +118,7 @@ struct dsps_glue {
struct device *dev;
struct platform_device *musb;   /* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
+   int vbus_irq;   /* optional vbus irq */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
bool sw_babble_enabled;
@@ -145,6 +146,29 @@ struct dsps_glue {
{ "mode",   0xe8 },
 };
 
+static void dsps_mod_timer(struct dsps_glue *glue, int wait_ms)
+{
+   int wait;
+
+   if (wait_ms < 0)
+   wait = msecs_to_jiffies(glue->wrp->poll_timeout);
+   else
+   wait = msecs_to_jiffies(wait_ms);
+
+   mod_timer(>timer, jiffies + wait);
+}
+
+/*
+ * If no vbus irq from the PMIC is configured, we need to poll VBUS status.
+ */
+static void dsps_mod_timer_optional(struct dsps_glue *glue)
+{
+   if (glue->vbus_irq)
+   return;
+
+   dsps_mod_timer(glue, -1);
+}
+
 /**
  * dsps_musb_enable - enable interrupts
  */
@@ -167,8 +191,7 @@ static void dsps_musb_enable(struct musb *musb)
/* start polling for ID change in dual-role idle mode */
if (musb->xceiv->otg->state == OTG_STATE_B_IDLE &&
musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
-   mod_timer(>timer, jiffies +
-   msecs_to_jiffies(wrp->poll_timeout));
+   dsps_mod_timer(glue, -1);
 }
 
 /**
@@ -198,6 +221,9 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
u8 devctl;
int skip_session = 0;
 
+   if (glue->vbus_irq)
+   del_timer(>timer);
+
/*
 * We poll because DSPS IP's won't expose several OTG-critical
 * status change events (from the transceiver) otherwise.
@@ -208,8 +234,7 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
 
switch (musb->xceiv->otg->state) {
case OTG_STATE_A_WAIT_VRISE:
-   mod_timer(>timer, jiffies +
-   msecs_to_jiffies(wrp->poll_timeout));
+   dsps_mod_timer_optional(glue);
break;
case OTG_STATE_A_WAIT_BCON:
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
@@ -218,17 +243,19 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
 
case OTG_STATE_A_IDLE:
case OTG_STATE_B_IDLE:
-   if (devctl & MUSB_DEVCTL_BDEVICE) {
-   musb->xceiv->otg->state = OTG_STATE_B_IDLE;
-   MUSB_DEV_MODE(musb);
-   } else {
-   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
-   MUSB_HST_MODE(musb);
+   if (!glue->vbus_irq) {
+   if (devctl & MUSB_DEVCTL_BDEVICE) {
+   musb->xceiv->otg->state = OTG_STATE_B_IDLE;
+   MUSB_DEV_MODE(musb);
+   } else {
+   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
+   MUSB_HST_MODE(musb);
+   }
+   if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session)
+   musb_writeb(mregs, MUSB_DEVCTL,
+   MUSB_DEVCTL_SESSION);
}
-   if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session)
-   musb_writeb(mregs, MUSB_DEVCTL, MUSB_DEVCTL_SESSION);
-   mod_timer(>timer, jiffies +
-   msecs_to_jiffies(wrp->poll_timeout));
+   dsps_mod_timer_optional(glue);
break;
case OTG_STATE_A_WAIT_VFALL:
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
@@ -331,15 +358,13 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 */
musb->int_usb &= ~MUSB_INTR_VBUSERROR;
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VFALL;
-   

[PATCH 08/17] usb: musb: Add a quirk to preserve the session during suspend

[Bin Liu]

From: Alexandre Bailon 

On da8xx, VBUS is not maintained during suspend when musb is in host mode.
On resume, all the connected devices will be disconnected and then will
be enumerated again.
This happens because MUSB_DEVCTL is cleared during suspend.
Add a quirk to not clear MUSB_DEVCTL and then preserve the  session during
a suspend.

Signed-off-by: Alexandre Bailon 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 3 ++-
 drivers/usb/musb/musb_core.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b1f082f42112..27887189fd14 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2659,7 +2659,8 @@ static int musb_suspend(struct device *dev)
 
musb_platform_disable(musb);
musb_disable_interrupts(musb);
-   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+   if (!(musb->io.quirks & MUSB_PRESERVE_SESSION))
+   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
WARN_ON(!list_empty(>pending_list));
 
spin_lock_irqsave(>lock, flags);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ade902ea1221..ab0c858af9d3 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -172,6 +172,7 @@ enum musb_g_ep0_state {
  */
 struct musb_platform_ops {
 
+#define MUSB_PRESERVE_SESSION  BIT(7)
 #define MUSB_DMA_UX500 BIT(6)
 #define MUSB_DMA_CPPI41BIT(5)
 #define MUSB_DMA_CPPI  BIT(4)
-- 
1.9.1

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

[PATCH 16/17] usb: musb: sunxi: add support for the variant in H3/V3s SoC

[Bin Liu]

From: Icenowy Zheng 

Allwinner H3/V3s features a variant of MUSB controller, which lacks one
endpoint.

Add support for it.

Signed-off-by: Icenowy Zheng 
Acked-by: Maxime Ripard 
[b-...@ti.com: added usb: to commit subject prefix]
Signed-off-by: Bin Liu 
---
 .../bindings/usb/allwinner,sun4i-a10-musb.txt  |  4 +--
 drivers/usb/musb/sunxi.c   | 35 --
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index 862cd7c79805..d9b42da016f3 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,8 +2,8 @@ Allwinner sun4i A10 musb DRC/OTG controller
 ---
 
 Required properties:
- - compatible  : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb"
- or "allwinner,sun8i-a33-musb"
+ - compatible  : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb",
+ "allwinner,sun8i-a33-musb" or "allwinner,sun8i-h3-musb"
  - reg : mmio address range of the musb controller
  - clocks  : clock specifier for the musb controller ahb gate clock
  - reset   : reset specifier for the ahb reset (A31 and newer only)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 05cab67d4106..c9a09b5bb6e5 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -639,6 +639,20 @@ static void sunxi_musb_writew(void __iomem *addr, unsigned 
offset, u16 data)
MUSB_EP_FIFO_SINGLE(5, FIFO_RX, 512),
 };
 
+/* H3/V3s OTG supports only 4 endpoints */
+#define SUNXI_MUSB_MAX_EP_NUM_H3   5
+
+static struct musb_fifo_cfg sunxi_musb_mode_cfg_h3[] = {
+   MUSB_EP_FIFO_SINGLE(1, FIFO_TX, 512),
+   MUSB_EP_FIFO_SINGLE(1, FIFO_RX, 512),
+   MUSB_EP_FIFO_SINGLE(2, FIFO_TX, 512),
+   MUSB_EP_FIFO_SINGLE(2, FIFO_RX, 512),
+   MUSB_EP_FIFO_SINGLE(3, FIFO_TX, 512),
+   MUSB_EP_FIFO_SINGLE(3, FIFO_RX, 512),
+   MUSB_EP_FIFO_SINGLE(4, FIFO_TX, 512),
+   MUSB_EP_FIFO_SINGLE(4, FIFO_RX, 512),
+};
+
 static const struct musb_hdrc_config sunxi_musb_hdrc_config = {
.fifo_cfg   = sunxi_musb_mode_cfg,
.fifo_cfg_size  = ARRAY_SIZE(sunxi_musb_mode_cfg),
@@ -650,6 +664,18 @@ static void sunxi_musb_writew(void __iomem *addr, unsigned 
offset, u16 data)
.dma= 0,
 };
 
+static struct musb_hdrc_config sunxi_musb_hdrc_config_h3 = {
+   .fifo_cfg   = sunxi_musb_mode_cfg_h3,
+   .fifo_cfg_size  = ARRAY_SIZE(sunxi_musb_mode_cfg_h3),
+   .multipoint = true,
+   .dyn_fifo   = true,
+   .soft_con   = true,
+   .num_eps= SUNXI_MUSB_MAX_EP_NUM_H3,
+   .ram_bits   = SUNXI_MUSB_RAM_BITS,
+   .dma= 0,
+};
+
+
 static int sunxi_musb_probe(struct platform_device *pdev)
 {
struct musb_hdrc_platform_data  pdata;
@@ -692,7 +718,10 @@ static int sunxi_musb_probe(struct platform_device *pdev)
return -EINVAL;
}
pdata.platform_ops  = _musb_ops;
-   pdata.config= _musb_hdrc_config;
+   if (!of_device_is_compatible(np, "allwinner,sun8i-h3-musb"))
+   pdata.config = _musb_hdrc_config;
+   else
+   pdata.config = _musb_hdrc_config_h3;
 
glue->dev = >dev;
INIT_WORK(>work, sunxi_musb_work);
@@ -704,7 +733,8 @@ static int sunxi_musb_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, "allwinner,sun6i-a31-musb"))
set_bit(SUNXI_MUSB_FL_HAS_RESET, >flags);
 
-   if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb")) {
+   if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb") ||
+   of_device_is_compatible(np, "allwinner,sun8i-h3-musb")) {
set_bit(SUNXI_MUSB_FL_HAS_RESET, >flags);
set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, >flags);
}
@@ -798,6 +828,7 @@ static int sunxi_musb_remove(struct platform_device *pdev)
{ .compatible = "allwinner,sun4i-a10-musb", },
{ .compatible = "allwinner,sun6i-a31-musb", },
{ .compatible = "allwinner,sun8i-a33-musb", },
+   { .compatible = "allwinner,sun8i-h3-musb", },
{}
 };
 MODULE_DEVICE_TABLE(of, sunxi_musb_match);
-- 
1.9.1

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

[PATCH 11/17] usb: musb: debugfs: allow forcing host mode together with speed in testmode

[Bin Liu]

From: Pali Rohár 

Based on the musb ug, force_host bit is allowed to be set along with
force_hs or force_fs bit.

It could help to implement forced host mode via testmode on Nokia N900.

Signed-off-by: Pali Rohár 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_debugfs.c | 46 ++---
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index dd70c88419d2..952733ceaac8 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -153,28 +153,34 @@ static int musb_test_mode_show(struct seq_file *s, void 
*unused)
pm_runtime_mark_last_busy(musb->controller);
pm_runtime_put_autosuspend(musb->controller);
 
-   if (test & MUSB_TEST_FORCE_HOST)
+   if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+   seq_printf(s, "force host full-speed\n");
+
+   else if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+   seq_printf(s, "force host high-speed\n");
+
+   else if (test == MUSB_TEST_FORCE_HOST)
seq_printf(s, "force host\n");
 
-   if (test & MUSB_TEST_FIFO_ACCESS)
+   else if (test == MUSB_TEST_FIFO_ACCESS)
seq_printf(s, "fifo access\n");
 
-   if (test & MUSB_TEST_FORCE_FS)
+   else if (test == MUSB_TEST_FORCE_FS)
seq_printf(s, "force full-speed\n");
 
-   if (test & MUSB_TEST_FORCE_HS)
+   else if (test == MUSB_TEST_FORCE_HS)
seq_printf(s, "force high-speed\n");
 
-   if (test & MUSB_TEST_PACKET)
+   else if (test == MUSB_TEST_PACKET)
seq_printf(s, "test packet\n");
 
-   if (test & MUSB_TEST_K)
+   else if (test == MUSB_TEST_K)
seq_printf(s, "test K\n");
 
-   if (test & MUSB_TEST_J)
+   else if (test == MUSB_TEST_J)
seq_printf(s, "test J\n");
 
-   if (test & MUSB_TEST_SE0_NAK)
+   else if (test == MUSB_TEST_SE0_NAK)
seq_printf(s, "test SE0 NAK\n");
 
return 0;
@@ -198,7 +204,7 @@ static ssize_t musb_test_mode_write(struct file *file,
struct seq_file *s = file->private_data;
struct musb *musb = s->private;
u8  test;
-   charbuf[18];
+   charbuf[24];
 
pm_runtime_get_sync(musb->controller);
test = musb_readb(musb->mregs, MUSB_TESTMODE);
@@ -213,30 +219,36 @@ static ssize_t musb_test_mode_write(struct file *file,
if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
 
-   if (strstarts(buf, "force host"))
+   if (strstarts(buf, "force host full-speed"))
+   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+   else if (strstarts(buf, "force host high-speed"))
+   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+   else if (strstarts(buf, "force host"))
test = MUSB_TEST_FORCE_HOST;
 
-   if (strstarts(buf, "fifo access"))
+   else if (strstarts(buf, "fifo access"))
test = MUSB_TEST_FIFO_ACCESS;
 
-   if (strstarts(buf, "force full-speed"))
+   else if (strstarts(buf, "force full-speed"))
test = MUSB_TEST_FORCE_FS;
 
-   if (strstarts(buf, "force high-speed"))
+   else if (strstarts(buf, "force high-speed"))
test = MUSB_TEST_FORCE_HS;
 
-   if (strstarts(buf, "test packet")) {
+   else if (strstarts(buf, "test packet")) {
test = MUSB_TEST_PACKET;
musb_load_testpacket(musb);
}
 
-   if (strstarts(buf, "test K"))
+   else if (strstarts(buf, "test K"))
test = MUSB_TEST_K;
 
-   if (strstarts(buf, "test J"))
+   else if (strstarts(buf, "test J"))
test = MUSB_TEST_J;
 
-   if (strstarts(buf, "test SE0 NAK"))
+   else if (strstarts(buf, "test SE0 NAK"))
test = MUSB_TEST_SE0_NAK;
 
musb_writeb(musb->mregs, MUSB_TESTMODE, test);
-- 
1.9.1

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

[PATCH 15/17] usb: musb: omap2430: constify dev_pm_ops structures

[Bin Liu]

From: Bhumika Goyal 

Declare dev_pm_ops structures as const as they are only stored in the pm
field of a device_driver structure. This field is of type const, so
dev_pm_ops structures having similar properties can be declared const
too.

Size details after cross compiling the .o file for arm
architecture.

File size before: drivers/usb/musb/omap2430.o
   textdata bss dec hex filename
   4141 400   8454911c5 usb/musb/omap2430.o

File size after: drivers/usb/musb/omap2430.o
   textdata bss dec hex filename
   4333 200   8454111bd usb/musb/omap2430.o

Signed-off-by: Bhumika Goyal 
[b-...@ti.com: added omap2430 in commit subject prefix]
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/omap2430.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 8b73214a9ea3..456f3e6ecf03 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -575,7 +575,7 @@ static int omap2430_runtime_resume(struct device *dev)
return 0;
 }
 
-static struct dev_pm_ops omap2430_pm_ops = {
+static const struct dev_pm_ops omap2430_pm_ops = {
.runtime_suspend = omap2430_runtime_suspend,
.runtime_resume = omap2430_runtime_resume,
 };
-- 
1.9.1

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

[PATCH 09/17] usb: musb: da8xx: Fix host mode suspend

[Bin Liu]

From: Alexandre Bailon 

On da8xx, VBUS is not maintained during suspend when musb is in host mode.
On resume, all the connected devices will be disconnected and then will
be enumerated again.
This happens because MUSB_DEVCTL is cleared during suspend.

Use the quirk MUSB_PRESERVE_SESSION to preseve MUSB_DEVCTL during suspend.

Signed-off-by: Alexandre Bailon 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/da8xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index eb5acee82173..d79c288ccbf2 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -457,7 +457,7 @@ static inline u8 get_vbus_power(struct device *dev)
 }
 
 static const struct musb_platform_ops da8xx_ops = {
-   .quirks = MUSB_INDEXED_EP,
+   .quirks = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
-- 
1.9.1

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

[PATCH 13/17] usb: musb: blackfin: fix unused warnings on suspend/resume

[Bin Liu]

From: Jérémy Lefaure 

When CONFIG_PM_SLEEP is disabled, SIMPLE_DEV_PM_OPS does not use
bfin_resume and bfin_suspend even if CONFIG_PM is enabled:

drivers/usb/musb/blackfin.c:602:12: warning: ‘bfin_resume’ defined but
not used [-Wunused-function]
 static int bfin_resume(struct device *dev)
^~~
drivers/usb/musb/blackfin.c:585:12: warning: ‘bfin_suspend’ defined but
not used [-Wunused-function]
 static int bfin_suspend(struct device *dev)
^~~~

The preprocessor condition should be on CONFIG_PM_SLEEP, not on CONFIG_PM.
However it is better to mark these functions as __maybe_unused.

Signed-off-by: Jérémy Lefaure 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/blackfin.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 896798071817..4418574a36a1 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -581,8 +581,7 @@ static int bfin_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int bfin_suspend(struct device *dev)
+static int __maybe_unused bfin_suspend(struct device *dev)
 {
struct bfin_glue*glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
@@ -599,7 +598,7 @@ static int bfin_suspend(struct device *dev)
return 0;
 }
 
-static int bfin_resume(struct device *dev)
+static int __maybe_unused bfin_resume(struct device *dev)
 {
struct bfin_glue*glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
@@ -608,7 +607,6 @@ static int bfin_resume(struct device *dev)
 
return 0;
 }
-#endif
 
 static SIMPLE_DEV_PM_OPS(bfin_pm_ops, bfin_suspend, bfin_resume);
 
-- 
1.9.1

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

[PATCH 12/17] usb: musb: dsps: switch to static id for musb-hdrc platform devices

[Bin Liu]

The dsps glue uses PLATFORM_DEVID_AUTO when creating the musb-hdrc
platform devices, this causes that the id will change in each system
depending on the order of driver probe, the order of the usb instances
defined in device-tree, or the list of enabled devices which use also
PLATFORM_DEVID_AUTO in kernel config. This id inconsistency causes
trouble in shell scripting or user guide documentation.

So switch it to static id, starting from 0 to the musb instance with
lower MMR offset. This scheme is also aligned to the naming in the SoC.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index ceb646be20d9..9542d20b2785 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -695,7 +695,8 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
resources[1] = *res;
 
/* allocate the child platform device */
-   musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
+   musb = platform_device_alloc("musb-hdrc",
+   (resources[0].start & 0xFFF) == 0x400 ? 0 : 1);
if (!musb) {
dev_err(dev, "failed to allocate musb device\n");
return -ENOMEM;
-- 
1.9.1

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

[PATCH 05/17] usb: musb: am35x: remove redundant code

[Bin Liu]

The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/am35x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 50ca8052bc8e..02fbb4fe3745 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -121,7 +121,6 @@ static void am35x_musb_disable(struct musb *musb)
musb_writel(reg_base, CORE_INTR_MASK_CLEAR_REG, AM35X_INTR_USB_MASK);
musb_writel(reg_base, EP_INTR_MASK_CLEAR_REG,
 AM35X_TX_INTR_MASK | AM35X_RX_INTR_MASK);
-   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
musb_writel(reg_base, USB_END_OF_INTR_REG, 0);
 }
 
-- 
1.9.1

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

[PATCH 06/17] usb: musb: davinci: remove redundant code

[Bin Liu]

The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/davinci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index cee61a51645e..52b491d3d5d8 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -133,7 +133,6 @@ static void davinci_musb_disable(struct musb *musb)
  DAVINCI_USB_USBINT_MASK
| DAVINCI_USB_TXINT_MASK
| DAVINCI_USB_RXINT_MASK);
-   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
musb_writel(musb->ctrl_base, DAVINCI_USB_EOI_REG, 0);
 
if (is_dma_capable() && !dma_off)
-- 
1.9.1

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

[PATCH 04/17] usb: musb: da8xx: remove redundant code

[Bin Liu]

The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/da8xx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cd3d763720b3..d5766ebeb761 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -125,7 +125,6 @@ static void da8xx_musb_disable(struct musb *musb)
musb_writel(reg_base, DA8XX_USB_INTR_MASK_CLEAR_REG,
DA8XX_INTR_USB_MASK |
DA8XX_INTR_TX_MASK | DA8XX_INTR_RX_MASK);
-   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
musb_writel(reg_base, DA8XX_USB_END_OF_INTR_REG, 0);
 }
 
-- 
1.9.1

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

[PATCH 00/17] musb patches for v4.11-rc1

[Bin Liu]

Hi Greg,

This musb patch set is for next v4.11-rc1. It adds suspend/resume support in
DA8xx glue, adds H3/V3s SoC support, fixes incorrect CPPI reference in DA8xx
glue, switch to static id naming for musb-hdrc device to give consistent user
experience, and a few compile warning fixes and cleanups. It also changes the
musb test mode handling which should enable the host mode for Nokia N900.

Please let me know if any change is needed.

Regards,
-Bin.
---

Alexandre Bailon (4):
  usb: musb: da8xx: Remove CPPI 3.0 quirk and methods
  usb: musb: da8xx: Add support of suspend / resume
  usb: musb: Add a quirk to preserve the session during suspend
  usb: musb: da8xx: Fix host mode suspend

Bhumika Goyal (1):
  usb: musb: omap2430: constify dev_pm_ops structures

Bin Liu (6):
  usb: musb: remove musb_generic_disable function
  usb: musb: dsps: remove redundant code
  usb: musb: da8xx: remove redundant code
  usb: musb: am35x: remove redundant code
  usb: musb: davinci: remove redundant code
  usb: musb: dsps: switch to static id for musb-hdrc platform devices

Chanwoo Choi (1):
  usb: musb: sunxi: Uses the resource-managed extcon API when
registering extcon notifier

Icenowy Zheng (1):
  usb: musb: sunxi: add support for the variant in H3/V3s SoC

Jérémy Lefaure (1):
  usb: musb: blackfin: fix unused warnings on suspend/resume

Pali Rohár (1):
  usb: musb: debugfs: allow forcing host mode together with speed in
testmode

Tony Lindgren (1):
  usb: musb: Add support for optional VBUS irq to dsps glue layer

Wei Yongjun (1):
  usb: musb: dsps: make dsps_musb_clear_ep_rxintr() static

 .../bindings/usb/allwinner,sun4i-a10-musb.txt  |   4 +-
 drivers/usb/musb/am35x.c   |   1 -
 drivers/usb/musb/blackfin.c|   6 +-
 drivers/usb/musb/da8xx.c   |  36 +-
 drivers/usb/musb/davinci.c |   1 -
 drivers/usb/musb/musb_core.c   |  27 ++---
 drivers/usb/musb/musb_core.h   |   1 +
 drivers/usb/musb/musb_debugfs.c|  46 +---
 drivers/usb/musb/musb_dsps.c   | 123 -
 drivers/usb/musb/omap2430.c|   2 +-
 drivers/usb/musb/sunxi.c   |  47 ++--
 11 files changed, 208 insertions(+), 86 deletions(-)

-- 
1.9.1

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

[PATCH 03/17] usb: musb: dsps: remove redundant code

[Bin Liu]

The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9f125e179acd..ceb646be20d9 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -186,7 +186,6 @@ static void dsps_musb_disable(struct musb *musb)
musb_writel(reg_base, wrp->epintr_clear,
 wrp->txep_bitmap | wrp->rxep_bitmap);
del_timer_sync(>timer);
-   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 }
 
 /* Caller must take musb->lock */
-- 
1.9.1

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

[PATCH 02/17] usb: musb: remove musb_generic_disable function

[Bin Liu]

musb_generic_disable() only has two lines of code. So remove it and let
the callers directly call those two lines.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index fca288bbc800..b1f082f42112 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1040,16 +1040,6 @@ static void musb_enable_interrupts(struct musb *musb)
 
 }
 
-static void musb_generic_disable(struct musb *musb)
-{
-   void __iomem*mbase = musb->mregs;
-
-   musb_disable_interrupts(musb);
-
-   /* off */
-   musb_writeb(mbase, MUSB_DEVCTL, 0);
-}
-
 /*
  * Program the HDRC to start (enable interrupts, dma, etc.).
  */
@@ -1106,8 +1096,8 @@ void musb_stop(struct musb *musb)
 {
/* stop IRQs, timers, ... */
musb_platform_disable(musb);
-   musb_generic_disable(musb);
-   musb_dbg(musb, "HDRC disabled");
+   musb_disable_interrupts(musb);
+   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 
/* FIXME
 *  - mark host and/or peripheral drivers unusable/inactive
@@ -2312,7 +2302,8 @@ static void musb_deassert_reset(struct work_struct *work)
 
/* be sure interrupts are disabled before connecting ISR */
musb_platform_disable(musb);
-   musb_generic_disable(musb);
+   musb_disable_interrupts(musb);
+   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 
/* Init IRQ workqueue before request_irq */
INIT_DELAYED_WORK(>irq_work, musb_irq_work);
@@ -2486,11 +2477,13 @@ static int musb_remove(struct platform_device *pdev)
pm_runtime_get_sync(musb->controller);
musb_host_cleanup(musb);
musb_gadget_cleanup(musb);
+
spin_lock_irqsave(>lock, flags);
musb_platform_disable(musb);
-   musb_generic_disable(musb);
-   spin_unlock_irqrestore(>lock, flags);
+   musb_disable_interrupts(musb);
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+   spin_unlock_irqrestore(>lock, flags);
+
pm_runtime_dont_use_autosuspend(musb->controller);
pm_runtime_put_sync(musb->controller);
pm_runtime_disable(musb->controller);
@@ -2665,7 +2658,8 @@ static int musb_suspend(struct device *dev)
unsigned long   flags;
 
musb_platform_disable(musb);
-   musb_generic_disable(musb);
+   musb_disable_interrupts(musb);
+   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
WARN_ON(!list_empty(>pending_list));
 
spin_lock_irqsave(>lock, flags);
-- 
1.9.1

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

[PATCH 01/17] usb: musb: da8xx: Remove CPPI 3.0 quirk and methods

[Bin Liu]

From: Alexandre Bailon 

DA8xx driver is registering and using the CPPI 3.0 DMA controller but
actually, the DA8xx has a CPPI 4.1 DMA controller.
Remove the CPPI 3.0 quirk and methods.

Fixes: f8e9f34f80a2 ("usb: musb: Fix up DMA related macros")
Fixes: 7f6283ed6fe8 ("usb: musb: Set up function pointers for DMA")
Cc: 
Signed-off-by: Alexandre Bailon 
Acked-by: Sergei Shtylyov 
Acked-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/da8xx.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index e89708d839e5..cd3d763720b3 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -458,15 +458,11 @@ static inline u8 get_vbus_power(struct device *dev)
 }
 
 static const struct musb_platform_ops da8xx_ops = {
-   .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
+   .quirks = MUSB_INDEXED_EP,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
.fifo_mode  = 2,
-#ifdef CONFIG_USB_TI_CPPI_DMA
-   .dma_init   = cppi_dma_controller_create,
-   .dma_exit   = cppi_dma_controller_destroy,
-#endif
.enable = da8xx_musb_enable,
.disable= da8xx_musb_disable,
 
-- 
1.9.1

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

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Rafał Miłecki]

On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:

On 02/01/2017 04:56 PM, Rafał Miłecki wrote:

On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:

On 01/31/2017 05:11 PM, Rafał Miłecki wrote:

Thanks a lot Jacek for this explanation (and sorry but I needed a bit of
time to
think about this). I can finally see your point, I think we're on the
same page
now.

I think that for all this time I was thinking from the pure DT
perspective. If
you ignore fact that Linux has multiple LED trigger drivers, then
"led-triggers"
may not sound that bad.

After reading your description however I can see this property can be
misleading
as Linux people may think "drivers" when seeing "triggers".

I still think this is a useful property and I hope we can still find a
way to
name it in a sane way: to be nice from DT PoV and march Linux LEDs
subsystem.


I also see the need for this property.


I think we should still work on some generic property (without linux,
prefix) as
this seems to be something generic, not really specific to Linux
implementation.
Specifying relation between LED and devices is something than AFAICS
can be
reused by other systems as well.

So my suggestion is to try some new name & leave linux,default-trigger
to allow
specifying one single trigger driver as required by current Linux
implementation.

What do you think about this?

There are few suggestions to came to my mind:
"trigger-sources"
"trigger-devices"
"led-trigger-devices"
"led-related-devices"
"led-event-devices"


trigger-devices would work in this specific use case,
where we can give phandles to usb ports. Nonetheless, we
have also other kernel based events serving as trigger
sources - e.g. timer.

In this case I'd go for trigger-sources, but we'd need
to have some generic way of defining the source like timer.


I'd leave timer for later discussion but I'm glad you brought this problem.
Maybe we could discuss this on another example that is more supported like
GPIOs?

We know this property allows specifying USB ports and we want it to support
mixing various sources. So a very simple sample case seems to be using
it for
specifying GPIO as trigger source.

Is this possible to mix various entries in a list assigned to single
property?
Let's say:
trigger-sources =
<_port1>,
<_port1>,
< 1 GPIO_ACTIVE_HIGH>;


According to my knowledge all elements in the list are elements
of one array, no matter if they are comma separated or space separated
in "<>" brackets. DT maintainer would have to confirm that though.


This matches my knowledge as well.



Is this possible to support this? If so, which function I can use to detect
what is pointed by a phandle?
I'm not that familiar with DT and I'm not sure how to handle this.


I wonder if this is correct way to go. Maybe we should think of
creating entirely new trigger mechanism that would allow for having
multiple active triggers at a time.


I'm OK with reworking Linux's triggers if it need be. I think we should agree
on binding(s) first though.



Of course trigger-sources would be still useful for defining
a list of devices of the same type like in case of usbport trigger.
Nonetheless, I have a problem with this property being a part of
LED class device DT bindings. Triggers are not tightly coupled with
LED class devices, but trigger-sources being a list of usb ports
would be applicable only to usbport trigger. What if there was
another combo trigger e.g. for reporting activity on mulitple GPIOs?


That was exactly my point with above trigger-sources example including 2 USB
ports & GPIO.



Should we have separate list of trigger sources per any possible
existing trigger type? Aren't we going to far from pure hardware
description the Device Tree was initially predestined to?


That would simplify things, but it gets us back to *multiple* properties like
led-usb-triggers (or led-usb-trigger-sources)
led-pci-triggers (or led-pci-trigger-sources)
led-gpio-triggers (or led-gpio-trigger-sources)
etc.

Last time Rob said he's not going to accept something like this, see:

On 23 January 2017 at 17:45, Rob Herring  wrote:
> I'm not going to accept something specific to USB. So the choice is make
> the existing property work for USB or design something more flexible and
> generic.

So I think the main question right now is if this is possible to support mixed
entries in a list like that
trigger-sources =
<_port1>,
<_port1>,
< 1 GPIO_ACTIVE_HIGH>;

I posted as example.

I was also trying to find help on IRC #devicetree channel but didn't get any
response:
[09:15]  hi, i've a question about mixing various entries in a single 
list
[09:16]  is this possible to have different /syntax/ in every list 
element
[09:16]  and have driver detect what does it reference?
[09:16]  i'll post an example
[09:17]  trigger-sources = <_port1>, <_port1>, < 1 
GPIO_ACTIVE_HIGH>;
[09:18]  this question is related to my work in [PATCH V2 1/2] 
dt-bindings: leds: document new 

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

On 02/01/2017 04:56 PM, Rafał Miłecki wrote:
> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:
>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:
>>> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:
 On 01/25/2017 10:03 AM, Rafał Miłecki wrote:
> On 21 January 2017 at 22:42, Jacek Anaszewski
>  wrote:
>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
>>> On 20 January 2017 at 23:35, Jacek Anaszewski
>>>  wrote:
 On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
>
> Some LEDs can be related to particular devices described in DT.
> This
> property allows specifying such relations. E.g. USB LED should
> usually
> be used to indicate some USB port(s) state.
>
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Replace "usb-ports" with "led-triggers" property which is
> more generic and
> allows specifying other devices as well.
>
> When bindings patch is related to some followup implementation,
> they usually go
> through the same tree.
>
> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds:
> Improve examples by
> adding some context") from kernel/git/j.anaszewski/linux-leds.git
> . Is there any
> way to solve this dependency issue? Or should this patch wait
> until 3.11 is
> released?
> ---
>  Documentation/devicetree/bindings/leds/common.txt | 16
> 
>  1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.txt
> b/Documentation/devicetree/bindings/leds/common.txt
> index 24b656014089..17632a041196 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>  - panic-indicator : This property specifies that the LED should
> be used,
>   if at all possible, as a panic indicator.
>
> +- led-triggers : List of devices that should trigger this LED
> activity. Some
> +  LEDs can be related to a specific device and
> should somehow
> +  indicate its state. E.g. USB 2.0 LED may react to
> device(s) in
> +  a USB 2.0 port(s). Another common example is
> switch or router
> +  with multiple Ethernet ports each of them having
> its own LED
> +  assigned (assuminled-trigger-usbportg they are not
> hardwired).
> +  In such cases this property should contain
> phandle(s) of
> +  related device(s). In many cases LED can be
> related to more
> +  than one device (e.g. one USB LED vs. multiple USB
> ports) so a
> +  list of entries can be specified.
> +

 This implies that it is possible to define multiple triggers for
 a LED class device but it is not supported by LED Trigger core.
 There is linux,default-trigger property which allows to define one
 trigger that will be initially assigned.
>>
>>> With proposed "led-triggers" property one could assign different
>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports,
>>> network
>>> device & CPU to a single LED. For reason explained above Linux
>>> couldn't support all of them at once.
>>>
>>>
 I am aware that this is renamed usb-ports property from v1,
 that attempts to address Rob's comment, but we can't do that this
 way.
 Maybe usb-ports property could be documented in
 led-trigger-usbport's
 specific bindings and a reference to it could be added next to the
 related entry on the list of the available LED triggers (which is
 actually missing) in
 Documentation/devicetree/bindings/leds/common.txt.
>>>
>>> I'm wondering if we need to care about this Linux limitation and
>>> if it
>>> should stop us from adding this flexible DT property. Maybe we could
>>> live with Linux having limitation of supporting one trigger type
>>> at a
>>> time?
>>
>> That's what I meant. Generally I have objections to the generic
>> property for defining list of allowed triggers. That's why I proposed
>> to stay by usb-ports property that would be specific to only one
>> trigger: led-trigger-usbport.
>>
>> led-trigger-usbport in fact is an entirely new type of LED trigger.
>> LED triggers is a kernel based source of events. All existing
>> triggers
>> react only to a 

Re: [PATCH 4.10-rc3 11/13] net: liquidio: fix build errors when linux/phy*.h is removed from net/dsa.h

[Felix Manlunas]

Russell King  wrote on Tue [2017-Jan-31 19:19:19 
+]:
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: type defaults 
> to 'int' in declaration of 'MODULE_AUTHOR'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: type defaults 
> to 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: type defaults 
> to 'int' in declaration of 'MODULE_LICENSE'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: type defaults 
> to 'int' in declaration of 'MODULE_VERSION'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:36: error: expected ')' 
> before 'int'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:37: error: expected ')' 
> before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: error: type defaults 
> to 'int' in declaration of 'MODULE_DEVICE_TABLE'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: parameter 
> names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: error: type defaults 
> to 'int' in declaration of 'module_init'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: parameter 
> names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: error: type defaults 
> to 'int' in declaration of 'module_exit'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: parameter 
> names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: type defaults to 
> 'int' in declaration of 'MODULE_AUTHOR'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: type defaults to 
> 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: type defaults to 
> 'int' in declaration of 'MODULE_LICENSE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: type 

Re: [PATCH] usb: gadget: udc: atmel: fix debug output

[Nicolas Ferre]

Le 01/02/2017 à 18:00, Alexandre Belloni a écrit :
> On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote:
>> The debug output now contains the wrong variable, as seen from the compiler
>> warning:
>>
>> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable':
>> drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be 
>> used uninitialized in this function [-Werror=maybe-uninitialized]
>>   DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
>>
>> This changes the debug output the same way as the other code.
>>
>> Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation 
>> scheme")
>> Signed-off-by: Arnd Bergmann 
> Acked-by: Alexandre Belloni 

Acked-by: Nicolas Ferre 

> 
>> ---
>>  drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
>> b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> index 11bbce28bc23..2035906b8ced 100644
>> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> @@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
>> usb_endpoint_descriptor *desc)
>>  {
>>  struct usba_ep *ep = to_usba_ep(_ep);
>>  struct usba_udc *udc = ep->udc;
>> -unsigned long flags, ept_cfg, maxpacket;
>> +unsigned long flags, maxpacket;
>>  unsigned int nr_trans;
>>  
>>  DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc);
>> @@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
>> usb_endpoint_descriptor *desc)
>>  ep->is_in = 0;
>>  
>>  DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
>> -ep->ep.name, ept_cfg, maxpacket);
>> +ep->ep.name, ep->ept_cfg, maxpacket);
>>  
>>  if (usb_endpoint_dir_in(desc)) {
>>  ep->is_in = 1;
>> -- 
>> 2.9.0
>>
> 


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

Re: [PATCH] usb: gadget: udc: atmel: fix debug output

[Alexandre Belloni]

On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote:
> The debug output now contains the wrong variable, as seen from the compiler
> warning:
> 
> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable':
> drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>   DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
> 
> This changes the debug output the same way as the other code.
> 
> Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation 
> scheme")
> Signed-off-by: Arnd Bergmann 
Acked-by: Alexandre Belloni 

> ---
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
> b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 11bbce28bc23..2035906b8ced 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
> usb_endpoint_descriptor *desc)
>  {
>   struct usba_ep *ep = to_usba_ep(_ep);
>   struct usba_udc *udc = ep->udc;
> - unsigned long flags, ept_cfg, maxpacket;
> + unsigned long flags, maxpacket;
>   unsigned int nr_trans;
>  
>   DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc);
> @@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
> usb_endpoint_descriptor *desc)
>   ep->is_in = 0;
>  
>   DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
> - ep->ep.name, ept_cfg, maxpacket);
> + ep->ep.name, ep->ept_cfg, maxpacket);
>  
>   if (usb_endpoint_dir_in(desc)) {
>   ep->is_in = 1;
> -- 
> 2.9.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

Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric

[Stefan Agner]

On 2017-02-01 00:06, Greg KH wrote:
> On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote:
>> Currently qw_sign requires UTF-8 character to set, but returns UTF-16
>> when read. This isn't obvious when simply using cat since the null
>> characters are not visible, but hexdump unveils the true string:
>>
>>   # echo MSFT100 > os_desc/qw_sign
>>   # hexdump -C os_desc/qw_sign
>>     4d 00 53 00 46 00 54 00  31 00 30 00 30 00
>> |M.S.F.T.1.0.0.|
>>
>> Make qw_sign symmetric by returning an UTF-8 string too. Also follow
>> common convention and add a new line at the end.
> 
> Doesn't USB require that strings be in UTF-16?  So why have the kernel
> convert them?

That is a discussion we should have had when the write side of this has
been added:

static ssize_t os_desc_qw_sign_store(struct config_item *item, const
char *page,
 size_t len)
{
struct gadget_info *gi = os_desc_item_to_gadget_info(item);
int res, l;

l = min((int)len, OS_STRING_QW_SIGN_LEN >> 1);
if (page[l - 1] == '\n')
--l;

mutex_lock(>lock);
res = utf8s_to_utf16s(page, l,
  UTF16_LITTLE_ENDIAN, (wchar_t *) gi->qw_sign,
  OS_STRING_QW_SIGN_LEN);
if (res > 0)
res = len;
mutex_unlock(>lock);

return res;
}


The store function is definitely already in use today, e.g. this script
used for ev3dev:
https://github.com/ev3dev/ev3-systemd/blob/ev3dev-jessie/scripts/ev3-usb.sh

Changing it to UTF-16 would break that script... So changing the store
part is the lesser of two evils.

Regarding new line: Just following what other attributes are doing by
using the GS_STRINGS_R macro.

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

Re: [PATCH 2/2] fs: configfs: use hexadecimal values and new line

[Stefan Agner]

On 2017-02-01 01:02, Felipe Balbi wrote:
> Hi,
> 
> Greg KH  writes:
>> On Tue, Jan 31, 2017 at 06:19:17PM -0800, Stefan Agner wrote:
>>> Other unsigned properties return hexadecimal values, follow this
>>> convention when printing b_vendor_code too. Also add newlines to
>>> the OS Descriptor support related properties, like other sysfs
>>> files use.
>>
>> configfs is not sysfs, so watch out, you might not need/want those new
>> lines as tools read the values and are not expecting them.
>>
>> Have you verified that nothing will break with this?  How have you
>> tested it?

I am actually writing OS Descriptor support for libusbgx (fork of
libusbg) when I stumbled upon this. The helper function there do not
care about the new line, but I just thought we should fix it for the
sake of coherency to the other properties. I am also fine dropping this
patch.

> 
> I would rather not change things like that, specially since Android guys
> are alreadying using configfs.

Do you happen to know where the source of that part is? So we could
check if they make use of any OS Descriptor support yet...

--
Stefan

--
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: gadget: udc: atmel: fix debug output

[Arnd Bergmann]

The debug output now contains the wrong variable, as seen from the compiler
warning:

drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable':
drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
  DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",

This changes the debug output the same way as the other code.

Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation 
scheme")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 11bbce28bc23..2035906b8ced 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
usb_endpoint_descriptor *desc)
 {
struct usba_ep *ep = to_usba_ep(_ep);
struct usba_udc *udc = ep->udc;
-   unsigned long flags, ept_cfg, maxpacket;
+   unsigned long flags, maxpacket;
unsigned int nr_trans;
 
DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc);
@@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
usb_endpoint_descriptor *desc)
ep->is_in = 0;
 
DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
-   ep->ep.name, ept_cfg, maxpacket);
+   ep->ep.name, ep->ept_cfg, maxpacket);
 
if (usb_endpoint_dir_in(desc)) {
ep->is_in = 1;
-- 
2.9.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 5/6] DT bindings documentation for Broadcom IPROC USB Device controller.

[Rob Herring]

On Mon, Jan 30, 2017 at 01:26:12PM +0530, Raviteja Garimella wrote:
> The device node is used for UDCs integrated into Broadcom's
> iProc family of SoCs'. The UDC is based on Synopsys Designware
> Cores AHB Subsystem USB Device Controller IP.
> 
> Signed-off-by: Raviteja Garimella 
> ---
>  .../bindings/usb/brcm,iproc-snps-udc.txt   | 24 
> ++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt 
> b/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
> new file mode 100644
> index 000..537dd4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
> @@ -0,0 +1,24 @@
> +Broadcom IPROC USB Device controller.
> +
> +The device node is used for UDCs integrated into Broadcom's
> +iProc family of SoCs'. The UDC is based on Synopsys Designware
> +Cores AHB Subsystem Device Controller.
> +
> +Required properties:
> + - compatible: should be "brcm,iproc-snps-udc"

Adding "snps" in here adds nothing really. Again, please use per SoC 
compatible strings.

> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - extcon: phandle to the extcon device. This is optional and
> +   not required for those that don't require extcon support.
> +   Extcon support will be required if the UDC is connected to
> +   a Dual Role Device Phy that supports both Host and Device
> +   mode based on the external cable.

Drop this property.

> +
> +Example:
> + udc_dwc: usb@664e {
> + compatible = "brcm,iproc-snps-udc";
> + reg = <0x664e 0x2000>;
> + interrupts = ;
> + phys = <_phy>;
> + extcon = <_phy>";
> -- 
> 2.1.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Rafał Miłecki]

On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:

On 01/31/2017 05:11 PM, Rafał Miłecki wrote:

On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:

On 01/25/2017 10:03 AM, Rafał Miłecki wrote:

On 21 January 2017 at 22:42, Jacek Anaszewski
 wrote:

On 01/21/2017 05:24 PM, Rafał Miłecki wrote:

On 20 January 2017 at 23:35, Jacek Anaszewski
 wrote:

On 01/20/2017 10:56 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Some LEDs can be related to particular devices described in DT. This
property allows specifying such relations. E.g. USB LED should
usually
be used to indicate some USB port(s) state.

Signed-off-by: Rafał Miłecki 
---
V2: Replace "usb-ports" with "led-triggers" property which is
more generic and
allows specifying other devices as well.

When bindings patch is related to some followup implementation,
they usually go
through the same tree.

Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds:
Improve examples by
adding some context") from kernel/git/j.anaszewski/linux-leds.git
. Is there any
way to solve this dependency issue? Or should this patch wait
until 3.11 is
released?
---
 Documentation/devicetree/bindings/leds/common.txt | 16

 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index 24b656014089..17632a041196 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -49,6 +49,17 @@ Optional properties for child nodes:
 - panic-indicator : This property specifies that the LED should
be used,
  if at all possible, as a panic indicator.

+- led-triggers : List of devices that should trigger this LED
activity. Some
+  LEDs can be related to a specific device and
should somehow
+  indicate its state. E.g. USB 2.0 LED may react to
device(s) in
+  a USB 2.0 port(s). Another common example is
switch or router
+  with multiple Ethernet ports each of them having
its own LED
+  assigned (assuminled-trigger-usbportg they are not
hardwired).
+  In such cases this property should contain
phandle(s) of
+  related device(s). In many cases LED can be
related to more
+  than one device (e.g. one USB LED vs. multiple USB
ports) so a
+  list of entries can be specified.
+


This implies that it is possible to define multiple triggers for
a LED class device but it is not supported by LED Trigger core.
There is linux,default-trigger property which allows to define one
trigger that will be initially assigned.



With proposed "led-triggers" property one could assign different
trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
device & CPU to a single LED. For reason explained above Linux
couldn't support all of them at once.



I am aware that this is renamed usb-ports property from v1,
that attempts to address Rob's comment, but we can't do that this
way.
Maybe usb-ports property could be documented in led-trigger-usbport's
specific bindings and a reference to it could be added next to the
related entry on the list of the available LED triggers (which is
actually missing) in
Documentation/devicetree/bindings/leds/common.txt.


I'm wondering if we need to care about this Linux limitation and if it
should stop us from adding this flexible DT property. Maybe we could
live with Linux having limitation of supporting one trigger type at a
time?


That's what I meant. Generally I have objections to the generic
property for defining list of allowed triggers. That's why I proposed
to stay by usb-ports property that would be specific to only one
trigger: led-trigger-usbport.

led-trigger-usbport in fact is an entirely new type of LED trigger.
LED triggers is a kernel based source of events. All existing triggers
react only to a single, well defined source of events, whereas
led-trigger-usbport allows to define the scope of events (usb ports)
to notify about. Activity on each port is treated similarly and the LED
class device that listens to the trigger notifications doesn't know
which exact port triggered the notification.

From this POV led-trigger-usbport is kind of facade, which allows
for it to fit well into the LED Trigger design and API, and usb ports
are not identical with LED triggers, but sit rather one level below.
It is led-trigger-usbport which is visible to the LED subsystem, and
not every single usb port.


So e.g. if one assigns 2 USB ports + network device + CPU and
decides to use "usport" trigger driver he'll get LED indicating status
of USB ports only.


How would it be different from the current state? Only in limiting
the scope of triggers available for a LED class device.


It won't differ from the current state. I just wanted to make it clear
Linux trigger drivers may respect only 

Re: [PATCH 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h

[Rafał Miłecki]

On 01/31/2017 08:18 PM, Russell King wrote:

drivers/net/ethernet/broadcom/bgmac.c:1015:17: error: dereferencing pointer to 
incomplete type 'struct mii_bus'
drivers/net/ethernet/broadcom/bgmac.c:1185:2: error: implicit declaration of 
function 'phy_start' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1198:2: error: implicit declaration of 
function 'phy_stop' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1239:9: error: implicit declaration of 
function 'phy_mii_ioctl' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1389:28: error: 
'phy_ethtool_get_link_ksettings' undeclared here (not in a function)
drivers/net/ethernet/broadcom/bgmac.c:1390:28: error: 
'phy_ethtool_set_link_ksettings' undeclared here (not in a function)
drivers/net/ethernet/broadcom/bgmac.c:1403:13: error: dereferencing pointer to 
incomplete type 'struct phy_device'
drivers/net/ethernet/broadcom/bgmac.c:1417:3: error: implicit declaration of 
function 'phy_print_status' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1424:26: error: storage size of 
'fphy_status' isn't known
drivers/net/ethernet/broadcom/bgmac.c:1424:9: error: variable 'fphy_status' has 
initializer but incomplete type
drivers/net/ethernet/broadcom/bgmac.c:1425:11: warning: excess elements in 
struct initializer
drivers/net/ethernet/broadcom/bgmac.c:1425:3: error: unknown field 'link' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1426:12: note: in expansion of macro 
'SPEED_1000'
drivers/net/ethernet/broadcom/bgmac.c:1426:3: error: unknown field 'speed' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1427:13: note: in expansion of macro 
'DUPLEX_FULL'
drivers/net/ethernet/broadcom/bgmac.c:1427:3: error: unknown field 'duplex' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1432:12: error: implicit declaration of 
function 'fixed_phy_register' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1432:31: error: 'PHY_POLL' undeclared 
(first use in this function)
drivers/net/ethernet/broadcom/bgmac.c:1438:8: error: implicit declaration of 
function 'phy_connect_direct' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1439:6: error: 'PHY_INTERFACE_MODE_MII' 
undeclared (first use in this function)
drivers/net/ethernet/broadcom/bgmac.c:1521:2: error: implicit declaration of 
function 'phy_disconnect' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1541:15: error: expected declaration 
specifiers or '...' before string constant

Add linux/phy.h to bgmac.c

Signed-off-by: Russell King 


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

Re: [PATCH 4.10-rc3 07/13] net: mvneta: fix build errors when linux/phy*.h is removed from net/dsa.h

[Thomas Petazzoni]

Hello,

On Tue, 31 Jan 2017 19:18:59 +, Russell King wrote:
> drivers/net/ethernet/marvell/mvneta.c:2694:26: error: storage size of 
> 'status' isn't known
> drivers/net/ethernet/marvell/mvneta.c:2695:26: error: storage size of 
> 'changed' isn't known
> drivers/net/ethernet/marvell/mvneta.c:2695:9: error: variable 'changed' has 
> initializer but incomplete type
> drivers/net/ethernet/marvell/mvneta.c:2709:2: error: implicit declaration of 
> function 'fixed_phy_update_state' [-Werror=implicit-function-declaration]
> 
> Add linux/phy_fixed.h to mvneta.c
> 
> Signed-off-by: Russell King 

Acked-by: Thomas Petazzoni 
-- 
Thomas Petazzoni, CTO, 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

Re: [PATCH 4.10-rc3 03/13] net: macb: fix build errors when linux/phy*.h is removed from net/dsa.h

[Nicolas Ferre]

Le 31/01/2017 à 20:18, Russell King a écrit :
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: expected ; at end of 
> declaration
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: Expected } at end of 
> struct-union-enum-specifier
> drivers/net/ethernet/cadence/macb.h:862:33: sparse: got phy_interface
> drivers/net/ethernet/cadence/macb.h:877:1: sparse: Expected ; at the end of 
> type declaration
> drivers/net/ethernet/cadence/macb.h:877:1: sparse: got }
> In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
> drivers/net/ethernet/cadence/macb.h:862:2: error: unknown type name 
> 'phy_interface_t'
>  phy_interface_t  phy_interface;
>  ^~~
> 
> Add linux/phy.h to macb.h
> 
> Signed-off-by: Russell King 

Acked-by: Nicolas Ferre 

> ---
>  drivers/net/ethernet/cadence/macb.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.h 
> b/drivers/net/ethernet/cadence/macb.h
> index d67adad67be1..383da8cf5f6d 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -10,6 +10,8 @@
>  #ifndef _MACB_H
>  #define _MACB_H
>  
> +#include 
> +
>  #define MACB_GREGS_NBR 16
>  #define MACB_GREGS_VERSION 2
>  #define MACB_MAX_QUEUES 8
> 


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

Re: [PATCH 2/2] fs: configfs: use hexadecimal values and new line

[Felipe Balbi]

Hi,

Greg KH  writes:
> On Tue, Jan 31, 2017 at 06:19:17PM -0800, Stefan Agner wrote:
>> Other unsigned properties return hexadecimal values, follow this
>> convention when printing b_vendor_code too. Also add newlines to
>> the OS Descriptor support related properties, like other sysfs
>> files use.
>
> configfs is not sysfs, so watch out, you might not need/want those new
> lines as tools read the values and are not expecting them.
>
> Have you verified that nothing will break with this?  How have you
> tested it?

I would rather not change things like that, specially since Android guys
are alreadying using configfs.

-- 
balbi


signature.asc
Description: PGP signature

Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Wed, Feb 01, 2017 at 07:24:44AM +, Ajay Kaher wrote:
>  
> >> At boot time, probe function of multiple connected devices
> >> (proprietary devices) execute simultaneously.
> >
> >What exactly do you mean here?  How can probe happen "simultaneously"?
> >The USB core prevents this, right?
> 
> I have observed two scenarios to call probe function:
> 
> Scenario #1: Driver inserted and attaching USB Device:
> Yes, you are right, two probes at same time is not happening
> in this scenario.
> 
> Scenario #2: USB Device attached and inserting Driver:
> In this case probe has been called in context of insmod,
> refer following code flow:
> init -> usb_register_driver -> driver_register -> bus_add_driver ->
> driver_attach -> bus_for_each_dev -> __driver_attach ->
> driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev
> 
> I have observed the crash in Scenario #2, as two probes executes at
> same time in this scenario. And init_usb_class_mutex lock require to
> prevent race condition.

What about the fact that in __driver_attach() we call device_lock() so
that probe never gets called at the same time for the same device?

Or are you saying that you can load multiple USB modules at the same
time?  If so, how is insmod running on multiple cpus at the same time?
I thought we had a global lock there to prevent that from happening
(i.e. only one module can be loaded at a time.)  Or is that what has
recently changed?

What is causing your modules to be loaded from userspace?  What type of
device is this happening for?  And why haven't we seen this before?
What kernel versions have you had a problem with this?

And what for what drivers specifically?

> >> And because of the following code path race condition happens:
> >> probe->usb_register_dev->init_usb_class
> >
> >Why is this just showing up now, and hasn't been an issue for the decade
> >or so this code has been around?  What changed?
> >
> >> Tested with these changes, and problem has been solved.
> >
> >What changes?
> 
> Tested with my patch (i.e. locking with init_usb_class_mutex).

I don't see a patch here :(

thanks,

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

RE: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

 
>> At boot time, probe function of multiple connected devices
>> (proprietary devices) execute simultaneously.
>
>What exactly do you mean here?  How can probe happen "simultaneously"?
>The USB core prevents this, right?

I have observed two scenarios to call probe function:

Scenario #1: Driver inserted and attaching USB Device:
Yes, you are right, two probes at same time is not happening
in this scenario.

Scenario #2: USB Device attached and inserting Driver:
In this case probe has been called in context of insmod,
refer following code flow:
init -> usb_register_driver -> driver_register -> bus_add_driver ->
driver_attach -> bus_for_each_dev -> __driver_attach ->
driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev

I have observed the crash in Scenario #2, as two probes executes at
same time in this scenario. And init_usb_class_mutex lock require to
prevent race condition.

>> And because of the following code path race condition happens:
>> probe->usb_register_dev->init_usb_class
>
>Why is this just showing up now, and hasn't been an issue for the decade
>or so this code has been around?  What changed?
>
>> Tested with these changes, and problem has been solved.
>
>What changes?

Tested with my patch (i.e. locking with init_usb_class_mutex).

thanks,

ajay kaher


 
- Original Message -
Sender : gre...@linuxfoundation.org 
Date   : 2017-01-31 12:31 (GMT+5:30)
Title  : Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race 
Condition when two USB class drivers try to call init_usb_class simultaneously
 
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
 
A: No.
Q: Should I include quotations after my reply?
 
 
http://daringfireball.net/2007/07/on_top
 
On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.
 
What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?
 
And what do you mean exactly by "(proprietary devices)"?
 
> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class
 
Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?
 
> Tested with these changes, and problem has been solved.
 
What changes?
 
thanks,
 
greg k-h
 
 
Thanks and Regards,
Ajay Kaher

Re: [PATCH 2/8] power: add power sequence library

[Greg Kroah-Hartman]

On Wed, Feb 01, 2017 at 12:10:17AM +0100, Rafael J. Wysocki wrote:
> On Tue, Jan 3, 2017 at 7:33 AM, Peter Chen  wrote:
> > We have an well-known problem that the device needs to do some power
> > sequence before it can be recognized by related host, the typical
> > example like hard-wired mmc devices and usb devices.
> >
> > This power sequence is hard to be described at device tree and handled by
> > related host driver, so we have created a common power sequence
> > library to cover this requirement. The core code has supplied
> > some common helpers for host driver, and individual power sequence
> > libraries handle kinds of power sequence for devices. The pwrseq
> > librares always need to allocate extra instance for compatible
> > string match.
> >
> > pwrseq_generic is intended for general purpose of power sequence, which
> > handles gpios and clocks currently, and can cover other controls in
> > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence is needed, else call of_pwrseq_on_list
> > /of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > For new power sequence library, it can add its compatible string
> > to pwrseq_of_match_table, then the pwrseq core will match it with
> > DT's, and choose this library at runtime.
> >
> > Signed-off-by: Peter Chen 
> > Tested-by: Maciej S. Szmigiero 
> > Tested-by Joshua Clayton 
> > Reviewed-by: Matthias Kaehlcke 
> > Tested-by: Matthias Kaehlcke 
> 
> Quite honestly, I have a really hard time with trying to follow this
> code and the total lack of documentation makes it even harder.  In
> particular, the generic power sequence code is not even commented at
> all, so it really is hard to say how this is going to work, let alone
> deciding whether or not to apply it.
> 
> Plus, of course, the USB core changes must be acked by the maintainer
> thereof for me to be able to handle the series.

Ah crap, I wanted you to explain it as I too couldn't figure it out :)

> But at this point I basically need you to explain the design to me, please.

Same here.

thanks,

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

Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric

[Greg KH]

On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote:
> Currently qw_sign requires UTF-8 character to set, but returns UTF-16
> when read. This isn't obvious when simply using cat since the null
> characters are not visible, but hexdump unveils the true string:
> 
>   # echo MSFT100 > os_desc/qw_sign
>   # hexdump -C os_desc/qw_sign
>     4d 00 53 00 46 00 54 00  31 00 30 00 30 00|M.S.F.T.1.0.0.|
> 
> Make qw_sign symmetric by returning an UTF-8 string too. Also follow
> common convention and add a new line at the end.

The newline is not part of the descriptor, so why add it?

thanks,

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

Re: [PATCH 2/2] fs: configfs: use hexadecimal values and new line

[Greg KH]

On Tue, Jan 31, 2017 at 06:19:17PM -0800, Stefan Agner wrote:
> Other unsigned properties return hexadecimal values, follow this
> convention when printing b_vendor_code too. Also add newlines to
> the OS Descriptor support related properties, like other sysfs
> files use.

configfs is not sysfs, so watch out, you might not need/want those new
lines as tools read the values and are not expecting them.

Have you verified that nothing will break with this?  How have you
tested it?

thanks,

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

Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric

[Greg KH]

On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote:
> Currently qw_sign requires UTF-8 character to set, but returns UTF-16
> when read. This isn't obvious when simply using cat since the null
> characters are not visible, but hexdump unveils the true string:
> 
>   # echo MSFT100 > os_desc/qw_sign
>   # hexdump -C os_desc/qw_sign
>     4d 00 53 00 46 00 54 00  31 00 30 00 30 00|M.S.F.T.1.0.0.|
> 
> Make qw_sign symmetric by returning an UTF-8 string too. Also follow
> common convention and add a new line at the end.

Doesn't USB require that strings be in UTF-16?  So why have the kernel
convert them?

thanks,

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