Re: [PATCH] Revert "usb: gadget: f_fs: Fix ExtCompat descriptor validation"

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 10:07:11AM +0200, Felipe Balbi wrote:
> Janusz Dziedzic  writes:
> > This reverts commit ac670a3a650b899fc020b81f63e810d06015b865.
> >
> > This introduce bug we already fixed in
> > commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof 
> > OS_DESC_EXT_COMPAT")
> >
> > Next FFS (adb) SS enumeration fail with Windows OS.
> >
> > Signed-off-by: Janusz Dziedzic 
> 
> Greg, can you still pick patches for -rc1? If you can, this is a pretty
> clear regression. If you want, you could pick it as a patch, or we can
> wait until -rc1 is out and I'll send it to you together with other fixes
> I may collect. In any case:
> 
> Acked-off-by: Felipe Balbi 

I am not going to have any time to apply anything to my tree until after
4.10 is out, so not just yet for -rc1, sorry.  Normal path should be
fine.

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: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Frederic Weisbecker]

On Fri, Feb 17, 2017 at 06:05:08PM +0100, Pavel Machek wrote:
> On Fri 2017-02-17 17:37:47, Thomas Gleixner wrote:
> > On Fri, 17 Feb 2017, Frederic Weisbecker wrote:
> > > On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote:
> > > > On Thu, 16 Feb 2017, Frederic Weisbecker wrote:
> > > > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote:
> > > > > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker
> > > > > >  wrote:
> > > > > > >
> > > > > > > I haven't followed the discussion but this patch has a known 
> > > > > > > issue which is fixed
> > > > > > > with:
> > > > > > > 7bdb59f1ad474bd7161adc8f923cdef10f2638d1
> > > > > > > "tick/nohz: Fix possible missing clock reprog after tick soft 
> > > > > > > restart"
> > > > > > >
> > > > > > > I hope this fixes your issue.
> > > > > > 
> > > > > > No, Pavel saw the problem with rc8 too, which already has that fix.
> > > > > > 
> > > > > > So I think we'll just need to revert that original patch (and that
> > > > > > means that we have to revert the commit you point to as well, since
> > > > > > that ->next_tick field was added by the original commit).
> > > > > 
> > > > > Aw too bad, but indeed that late we don't have the choice.
> > > > 
> > > > Hint: Look for CPU hotplug interaction of these patches. I bet something
> > > > becomes stale when the CPU goes down and does not get reset when it 
> > > > comes
> > > > back online.
> > > 
> > > Indeed I should check that. But Pavel is seeing this on boot, where the
> > 
> > I don't think so. He observed it on suspend resume and by doing hotplug
> > operations in a loop. But I might be wrong as usual.
> 
> These are different bugs.
> 
> On x60, I see failures doing hotplug/unplug in a loop, or lot of
> suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit.
> 
> Desktop machine was failing to boot, and had some fun with
> suspend/resume too. Boot hang was reproducible with right
> procedure. (Hard poweroff, cold boot.). That one was introduced in
> 4.10-rc cycle.

Pavel, is there any chance you could apply this patch on top of latest linus 
tree
and send me your resulting dmesg log? This has the two reverted patches plus 
some
debugging code. The amount of printk shouldn't be too big, I tested it home 
without
issue.

If you can't manage to dump the dmesg, please try to take a picture of your 
screen
so that I can see the last messages starting with "NEXT_TICK_READ".

Thanks!

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 2c115fd..504cb41 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -658,6 +658,8 @@ static void tick_nohz_restart(struct tick_sched *ts, 
ktime_t now)
tick_program_event(hrtimer_get_expires(>sched_timer), 1);
 }
 
+static DEFINE_PER_CPU(u64, prev_next_tick);
+
 static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
 ktime_t now, int cpu)
 {
@@ -725,6 +727,11 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
 */
if (delta == 0) {
tick_nohz_restart(ts, now);
+   /*
+* Make sure next tick stop doesn't get fooled by past
+* clock deadline
+*/
+   ts->next_tick = 0;
goto out;
}
}
@@ -767,8 +774,15 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
tick = expires;
 
/* Skip reprogram of event if its not changed */
-   if (ts->tick_stopped && (expires == dev->next_event))
-   goto out;
+   if (ts->tick_stopped) {
+   if (system_state == SYSTEM_BOOTING) {
+   if (ts->next_tick != this_cpu_read(prev_next_tick))
+   printk("NEXT_TICK_READ: CPU: %d Expires: %llu 
ts->next_tick:%llu\n", smp_processor_id(), expires, ts->next_tick);
+   this_cpu_write(prev_next_tick, ts->next_tick);
+   }
+   if (expires == ts->next_tick)
+   goto out;
+   }
 
/*
 * nohz_stop_sched_tick can be called several times before
@@ -787,6 +801,8 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
trace_tick_stop(1, TICK_DEP_MASK_NONE);
}
 
+   ts->next_tick = tick;
+
/*
 * If the expiration time == KTIME_MAX, then we simply stop
 * the tick timer.
@@ -802,7 +818,10 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched 
*ts,
else
tick_program_event(tick, 1);
 out:
-   /* Update the estimated sleep length */
+   /*
+* Update the estimated sleep length until the next timer
+* (not only the tick).
+*/
ts->sleep_length = ktime_sub(dev->next_event, now);
return tick;
 }
diff --git 

Re: USB Based Touchscreen support

[Greg KH]

On Fri, Feb 17, 2017 at 08:35:35PM +0530, Sriram V wrote:
> Hi Greg,
> 
> I am planning to buy multiple devices. Therefore, I wanted to find out
> if there exists a universal driver or we need to do customisations.

Again, it all depends on the device itself.  There is a standard spec,
but not all devices follow it.  Try buying a device and testing it out.

Good luck!

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: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Fri 2017-02-17 17:37:47, Thomas Gleixner wrote:
> On Fri, 17 Feb 2017, Frederic Weisbecker wrote:
> > On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote:
> > > On Thu, 16 Feb 2017, Frederic Weisbecker wrote:
> > > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote:
> > > > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker
> > > > >  wrote:
> > > > > >
> > > > > > I haven't followed the discussion but this patch has a known issue 
> > > > > > which is fixed
> > > > > > with:
> > > > > > 7bdb59f1ad474bd7161adc8f923cdef10f2638d1
> > > > > > "tick/nohz: Fix possible missing clock reprog after tick soft 
> > > > > > restart"
> > > > > >
> > > > > > I hope this fixes your issue.
> > > > > 
> > > > > No, Pavel saw the problem with rc8 too, which already has that fix.
> > > > > 
> > > > > So I think we'll just need to revert that original patch (and that
> > > > > means that we have to revert the commit you point to as well, since
> > > > > that ->next_tick field was added by the original commit).
> > > > 
> > > > Aw too bad, but indeed that late we don't have the choice.
> > > 
> > > Hint: Look for CPU hotplug interaction of these patches. I bet something
> > > becomes stale when the CPU goes down and does not get reset when it comes
> > > back online.
> > 
> > Indeed I should check that. But Pavel is seeing this on boot, where the
> 
> I don't think so. He observed it on suspend resume and by doing hotplug
> operations in a loop. But I might be wrong as usual.

These are different bugs.

On x60, I see failures doing hotplug/unplug in a loop, or lot of
suspends. Someone seen it in v4.8-stable etc. Old bug. Rare to hit.

Desktop machine was failing to boot, and had some fun with
suspend/resume too. Boot hang was reproducible with right
procedure. (Hard poweroff, cold boot.). That one was introduced in
4.10-rc cycle.


Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Thomas Gleixner]

On Fri, 17 Feb 2017, Frederic Weisbecker wrote:
> On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote:
> > On Thu, 16 Feb 2017, Frederic Weisbecker wrote:
> > > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote:
> > > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker
> > > >  wrote:
> > > > >
> > > > > I haven't followed the discussion but this patch has a known issue 
> > > > > which is fixed
> > > > > with:
> > > > > 7bdb59f1ad474bd7161adc8f923cdef10f2638d1
> > > > > "tick/nohz: Fix possible missing clock reprog after tick soft 
> > > > > restart"
> > > > >
> > > > > I hope this fixes your issue.
> > > > 
> > > > No, Pavel saw the problem with rc8 too, which already has that fix.
> > > > 
> > > > So I think we'll just need to revert that original patch (and that
> > > > means that we have to revert the commit you point to as well, since
> > > > that ->next_tick field was added by the original commit).
> > > 
> > > Aw too bad, but indeed that late we don't have the choice.
> > 
> > Hint: Look for CPU hotplug interaction of these patches. I bet something
> > becomes stale when the CPU goes down and does not get reset when it comes
> > back online.
> 
> Indeed I should check that. But Pavel is seeing this on boot, where the

I don't think so. He observed it on suspend resume and by doing hotplug
operations in a loop. But I might be wrong as usual.

> only hotplug operations that happen are CPU UP without preceding CPU DOWN
> that may have retained stale values. I think the value of ts->next_tick should
> be initially 0 for all CPUs. So perhaps that 0 value confuses stuff. But
> looking at the code I don't see how. It maybe something more subtle.
> 
--
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] Revert "ARM: at91/dt: sama5d2: Use new compatible for ohci node"

[Alexandre Belloni]

On 17/02/2017 at 16:12:50 +0100, Romain Izard wrote:
> This reverts commit cab43282682e ("ARM: at91/dt: sama5d2: Use new
> compatible for ohci node")
> 
> It depends from commit 7150bc9b4d43 ("usb: ohci-at91: Forcibly suspend
> ports while USB suspend") which was reverted and implemented
> differently. With the new implementation, the compatible string must
> remain the same.
> 
> The compatible string introduced by this commit has been used in the
> default SAMA5D2 dtsi starting from Linux 4.8. As it has never been
> working correctly in an official release, removing it should not be
> breaking the stability rules.
> 
> Fixes: cab43282682e ("ARM: at91/dt: sama5d2: Use new compatible for ohci 
> node")
> Signed-off-by: Romain Izard 
> cc: 
> ---
>  arch/arm/boot/dts/sama5d2.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Sure, I'll take it as a fix once 4.11-rc1 is released.

> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index ceb9783ff7e1..ff7eae833a6d 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -266,7 +266,7 @@
>   };
>  
>   usb1: ohci@0040 {
> - compatible = "atmel,sama5d2-ohci", "usb-ohci";
> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
>   reg = <0x0040 0x10>;
>   interrupts = <41 IRQ_TYPE_LEVEL_HIGH 2>;
>   clocks = <_clk>, <_clk>, <>;
> -- 
> 2.9.3
> 

-- 
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] Revert "ARM: at91/dt: sama5d2: Use new compatible for ohci node"

[Romain Izard]

This reverts commit cab43282682e ("ARM: at91/dt: sama5d2: Use new
compatible for ohci node")

It depends from commit 7150bc9b4d43 ("usb: ohci-at91: Forcibly suspend
ports while USB suspend") which was reverted and implemented
differently. With the new implementation, the compatible string must
remain the same.

The compatible string introduced by this commit has been used in the
default SAMA5D2 dtsi starting from Linux 4.8. As it has never been
working correctly in an official release, removing it should not be
breaking the stability rules.

Fixes: cab43282682e ("ARM: at91/dt: sama5d2: Use new compatible for ohci node")
Signed-off-by: Romain Izard 
cc: 
---
 arch/arm/boot/dts/sama5d2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index ceb9783ff7e1..ff7eae833a6d 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -266,7 +266,7 @@
};
 
usb1: ohci@0040 {
-   compatible = "atmel,sama5d2-ohci", "usb-ohci";
+   compatible = "atmel,at91rm9200-ohci", "usb-ohci";
reg = <0x0040 0x10>;
interrupts = <41 IRQ_TYPE_LEVEL_HIGH 2>;
clocks = <_clk>, <_clk>, <>;
-- 
2.9.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: USB Based Touchscreen support

[Sriram V]

Hi Greg,

I am planning to buy multiple devices. Therefore, I wanted to find out
if there exists a universal driver or
we need to do customisations.

The driver sources lists only 17 devices which are supported.
Therefore, the question.
I thought there is a standard like the keyboard/mouse. which
practically support any keyboard/mouse.

Anyway, as you say it depends on the device and there is no single
driver which works for all.

Thanks.
Sriram



On Fri, Feb 17, 2017 at 8:23 PM, Greg KH  wrote:
> On Fri, Feb 17, 2017 at 04:56:38PM +0530, Sriram V wrote:
>> Hi,
>>
>> I wanted to check if the linux kernel support
>> (drivers/input/touchscreen/usbtouchscreen.c) supports all the usb
>> based touch screen
>> like the standard usb mouse/keyboard
>>
>> Or is there any vendor specific drivers need to be supported.
>
> It depends on your device, do you have a device that is not currently
> supported by the in-kernel drivers?
>
> 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: USB Based Touchscreen support

[Greg KH]

On Fri, Feb 17, 2017 at 04:56:38PM +0530, Sriram V wrote:
> Hi,
> 
> I wanted to check if the linux kernel support
> (drivers/input/touchscreen/usbtouchscreen.c) supports all the usb
> based touch screen
> like the standard usb mouse/keyboard
> 
> Or is there any vendor specific drivers need to be supported.

It depends on your device, do you have a device that is not currently
supported by the in-kernel drivers?

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: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Frederic Weisbecker]

On Thu, Feb 16, 2017 at 08:06:04PM +0100, Pavel Machek wrote:
> On Thu 2017-02-16 18:25:35, Pavel Machek wrote:
> > Hi!
> > 
> > > > > 4.10-rc4 broken
> > > > > 4.10-rc3 ok
> > > > 
> > > > Hmm. If those actually end up being reliable, then there's not a whole
> > > > lot in between them wrt PCI or USB.
> > > > 
> > > > What looked like the most likely candidate seems to be xhci-specific, 
> > > > though.
> > > > 
> > > > But maybe it's something that isn't directly in drivers/{pci,usb}/ and
> > > > just interacts badly.
> > > 
> > > Ok. I _hope_ my tests are ok. Bisect log so far is:
> > 
> > And the winner is:
> > 
> > pavel@half:/data/l/linux$ git bisect bad
> > 24b91e360ef521a2808771633d76ebc68bd5604b is the first bad commit
> > commit 24b91e360ef521a2808771633d76ebc68bd5604b
> > Author: Frederic Weisbecker 
> > Date:   Wed Jan 4 15:12:04 2017 +0100
> > 
> > nohz: Fix collision between tick and other hrtimers
> > 
> 
> I had to revert 7bdb59f1ad474bd7161adc8f923cdef10f2638d1, too,
> otherwise -rc8 does not compile.
> 
> With 24b91e360ef521a28087716 and 7bdb59f1ad474 reverted, it seems to
> boot ok. (I did few tries.)

Do you still have the config that triggered this? I don't have much expectations
about reproducing, this has almost never worked for me, but at least I could 
narrow
down the context.

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

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Frederic Weisbecker]

On Thu, Feb 16, 2017 at 08:34:45PM +0100, Thomas Gleixner wrote:
> On Thu, 16 Feb 2017, Frederic Weisbecker wrote:
> > On Thu, Feb 16, 2017 at 10:20:14AM -0800, Linus Torvalds wrote:
> > > On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker
> > >  wrote:
> > > >
> > > > I haven't followed the discussion but this patch has a known issue 
> > > > which is fixed
> > > > with:
> > > > 7bdb59f1ad474bd7161adc8f923cdef10f2638d1
> > > > "tick/nohz: Fix possible missing clock reprog after tick soft 
> > > > restart"
> > > >
> > > > I hope this fixes your issue.
> > > 
> > > No, Pavel saw the problem with rc8 too, which already has that fix.
> > > 
> > > So I think we'll just need to revert that original patch (and that
> > > means that we have to revert the commit you point to as well, since
> > > that ->next_tick field was added by the original commit).
> > 
> > Aw too bad, but indeed that late we don't have the choice.
> 
> Hint: Look for CPU hotplug interaction of these patches. I bet something
> becomes stale when the CPU goes down and does not get reset when it comes
> back online.

Indeed I should check that. But Pavel is seeing this on boot, where the
only hotplug operations that happen are CPU UP without preceding CPU DOWN
that may have retained stale values. I think the value of ts->next_tick should
be initially 0 for all CPUs. So perhaps that 0 value confuses stuff. But
looking at the code I don't see how. It maybe something more subtle.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] usb: dwc2: pci: Fix error handling in dwc2_pci_probe

[Vardan Mikayelyan]

Move usb_phy_generic_register() function call to the top, to simplify
error handling.

Replace kzalloc() with devm_kzalloc().

After platform_device_add(), if we error out, we must do
platform_device_unregister(), which also does the put. So lets move
devm_kzalloc() to simplify error handling and avoid
calling of platform_device_unregister().

Reviewed-by: Wei Yongjun 
Signed-off-by: Vardan Mikayelyan 
---
Changes in v2:
 - Remove kfree(glue) as suggested Janusz Dziedzic.

 drivers/usb/dwc2/pci.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
index fdeb8c7..70b0b9c 100644
--- a/drivers/usb/dwc2/pci.c
+++ b/drivers/usb/dwc2/pci.c
@@ -82,7 +82,6 @@ static void dwc2_pci_remove(struct pci_dev *pci)
 
platform_device_unregister(glue->dwc2);
usb_phy_generic_unregister(glue->phy);
-   kfree(glue);
pci_set_drvdata(pci, NULL);
 }
 
@@ -104,10 +103,17 @@ static int dwc2_pci_probe(struct pci_dev *pci,
 
pci_set_master(pci);
 
+   phy = usb_phy_generic_register();
+   if (IS_ERR(phy)) {
+   dev_err(dev, "error registering generic PHY (%ld)\n",
+   PTR_ERR(phy));
+   return PTR_ERR(phy);
+   }
+
dwc2 = platform_device_alloc("dwc2", PLATFORM_DEVID_AUTO);
if (!dwc2) {
dev_err(dev, "couldn't allocate dwc2 device\n");
-   return -ENOMEM;
+   goto err;
}
 
memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
@@ -124,32 +130,25 @@ static int dwc2_pci_probe(struct pci_dev *pci,
ret = platform_device_add_resources(dwc2, res, ARRAY_SIZE(res));
if (ret) {
dev_err(dev, "couldn't add resources to dwc2 device\n");
-   return ret;
+   goto err;
}
 
dwc2->dev.parent = dev;
 
-   phy = usb_phy_generic_register();
-   if (IS_ERR(phy)) {
-   dev_err(dev, "error registering generic PHY (%ld)\n",
-   PTR_ERR(phy));
-   return PTR_ERR(phy);
-   }
-
ret = dwc2_pci_quirks(pci, dwc2);
if (ret)
goto err;
 
+   glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
+   if (!glue)
+   goto err;
+
ret = platform_device_add(dwc2);
if (ret) {
dev_err(dev, "failed to register dwc2 device\n");
goto err;
}
 
-   glue = kzalloc(sizeof(*glue), GFP_KERNEL);
-   if (!glue)
-   return -ENOMEM;
-
glue->phy = phy;
glue->dwc2 = dwc2;
pci_set_drvdata(pci, glue);
-- 
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] usb: dwc2: pci: Fix error handling in dwc2_pci_probe

[Janusz Dziedzic]

On 17 February 2017 at 14:01, Vardan Mikayelyan
 wrote:
> Move usb_phy_generic_register() function call to the top, to simplify
> error handling.
>
> Replace kzalloc() with devm_kzalloc().
>
> After platform_device_add(), if we error out, we must do
> platform_device_unregister(), which also does the put. So lets move
> devm_kzalloc() to simplify error handling and avoid
> calling of platform_device_unregister().
>
> Reviewed-by: Wei Yongjun 
> Signed-off-by: Vardan Mikayelyan 
> ---
>  drivers/usb/dwc2/pci.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
> index fdeb8c7..7696131 100644
> --- a/drivers/usb/dwc2/pci.c
> +++ b/drivers/usb/dwc2/pci.c
> @@ -104,10 +104,17 @@ static int dwc2_pci_probe(struct pci_dev *pci,
>
> pci_set_master(pci);
>
> +   phy = usb_phy_generic_register();
> +   if (IS_ERR(phy)) {
> +   dev_err(dev, "error registering generic PHY (%ld)\n",
> +   PTR_ERR(phy));
> +   return PTR_ERR(phy);
> +   }
> +
> dwc2 = platform_device_alloc("dwc2", PLATFORM_DEVID_AUTO);
> if (!dwc2) {
> dev_err(dev, "couldn't allocate dwc2 device\n");
> -   return -ENOMEM;
> +   goto err;
> }
>
> memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
> @@ -124,32 +131,25 @@ static int dwc2_pci_probe(struct pci_dev *pci,
> ret = platform_device_add_resources(dwc2, res, ARRAY_SIZE(res));
> if (ret) {
> dev_err(dev, "couldn't add resources to dwc2 device\n");
> -   return ret;
> +   goto err;
> }
>
> dwc2->dev.parent = dev;
>
> -   phy = usb_phy_generic_register();
> -   if (IS_ERR(phy)) {
> -   dev_err(dev, "error registering generic PHY (%ld)\n",
> -   PTR_ERR(phy));
> -   return PTR_ERR(phy);
> -   }
> -
> ret = dwc2_pci_quirks(pci, dwc2);
> if (ret)
> goto err;
>
> +   glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
> +   if (!glue)
> +   goto err;
> +

Seems you can also remove kfree(glue) ...

> ret = platform_device_add(dwc2);
> if (ret) {
> dev_err(dev, "failed to register dwc2 device\n");
> goto err;
> }
>
> -   glue = kzalloc(sizeof(*glue), GFP_KERNEL);
> -   if (!glue)
> -   return -ENOMEM;
> -
> glue->phy = phy;
> glue->dwc2 = dwc2;
> pci_set_drvdata(pci, glue);
> --
> 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
--
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: dwc2: pci: Fix error handling in dwc2_pci_probe

[Vardan Mikayelyan]

Move usb_phy_generic_register() function call to the top, to simplify
error handling.

Replace kzalloc() with devm_kzalloc().

After platform_device_add(), if we error out, we must do
platform_device_unregister(), which also does the put. So lets move
devm_kzalloc() to simplify error handling and avoid
calling of platform_device_unregister().

Reviewed-by: Wei Yongjun 
Signed-off-by: Vardan Mikayelyan 
---
 drivers/usb/dwc2/pci.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
index fdeb8c7..7696131 100644
--- a/drivers/usb/dwc2/pci.c
+++ b/drivers/usb/dwc2/pci.c
@@ -104,10 +104,17 @@ static int dwc2_pci_probe(struct pci_dev *pci,
 
pci_set_master(pci);
 
+   phy = usb_phy_generic_register();
+   if (IS_ERR(phy)) {
+   dev_err(dev, "error registering generic PHY (%ld)\n",
+   PTR_ERR(phy));
+   return PTR_ERR(phy);
+   }
+
dwc2 = platform_device_alloc("dwc2", PLATFORM_DEVID_AUTO);
if (!dwc2) {
dev_err(dev, "couldn't allocate dwc2 device\n");
-   return -ENOMEM;
+   goto err;
}
 
memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
@@ -124,32 +131,25 @@ static int dwc2_pci_probe(struct pci_dev *pci,
ret = platform_device_add_resources(dwc2, res, ARRAY_SIZE(res));
if (ret) {
dev_err(dev, "couldn't add resources to dwc2 device\n");
-   return ret;
+   goto err;
}
 
dwc2->dev.parent = dev;
 
-   phy = usb_phy_generic_register();
-   if (IS_ERR(phy)) {
-   dev_err(dev, "error registering generic PHY (%ld)\n",
-   PTR_ERR(phy));
-   return PTR_ERR(phy);
-   }
-
ret = dwc2_pci_quirks(pci, dwc2);
if (ret)
goto err;
 
+   glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
+   if (!glue)
+   goto err;
+
ret = platform_device_add(dwc2);
if (ret) {
dev_err(dev, "failed to register dwc2 device\n");
goto err;
}
 
-   glue = kzalloc(sizeof(*glue), GFP_KERNEL);
-   if (!glue)
-   return -ENOMEM;
-
glue->phy = phy;
glue->dwc2 = dwc2;
pci_set_drvdata(pci, glue);
-- 
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

USB Based Touchscreen support

[Sriram V]

Hi,

I wanted to check if the linux kernel support
(drivers/input/touchscreen/usbtouchscreen.c) supports all the usb
based touch screen
like the standard usb mouse/keyboard

Or is there any vendor specific drivers need to be supported.

Regards,
Sriram
--
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: gadget: f_fs: Fix ExtCompat documentation in uapi header

[Vincent Pelletier]

The code was fixed in
commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof 
OS_DESC_EXT_COMPAT")
but the in-header documentation kept referencing 0 as the expected value.
Reference 1 instead as per original commit message.

Signed-off-by: Vincent Pelletier 
---
 include/uapi/linux/usb/functionfs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/usb/functionfs.h 
b/include/uapi/linux/usb/functionfs.h
index b2a31a55a612..062606f02309 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -158,7 +158,7 @@ struct usb_ext_prop_desc {
  * |-+---+--+-|
  * |   0 | bFirstInterfaceNumber | U8   | index of the interface or of the 1st|
  * | |   |  | interface in an IAD group   |
- * |   1 | Reserved  | U8   | 0   |
+ * |   1 | Reserved  | U8   | 1   |
  * |   2 | CompatibleID  | U8[8]| compatible ID string|
  * |  10 | SubCompatibleID   | U8[8]| subcompatible ID string |
  * |  18 | Reserved  | U8[6]| 0   |
-- 
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 1/3 v3] usb: host: fotg2: add device tree probing

[Hans Ulli Kroll]

Add device tree probing for fotg2-hcd driver
This device in a dual role hcd/otg device and it's used on Gemini Soc.

Currently all Gemini Soc based devices uses only the hcd part.

v2:
fix wrong name in MODULE_DEVICE_TABLE()

v3:
better commit message
remove dma_coerce_mask_and_coherent() suggested by Arnd

Acked-by: Linus Walleij 
Signed-off-by: Hans Ulli Kroll 
---
 drivers/usb/host/fotg210-hcd.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/host/fotg210-hcd.c 
b/drivers/usb/host/fotg210-hcd.c
index 9d0b0518290a..ff6e4275fcf6 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -23,6 +23,7 @@
  * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -5676,9 +5677,18 @@ static int fotg210_hcd_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id fotg210_ehci_match[] = {
+   { .compatible = "faraday,fotg210-hcd" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, fotg210_ehci_match);
+#endif
+
 static struct platform_driver fotg210_hcd_driver = {
.driver = {
.name   = "fotg210-hcd",
+   .of_match_table = of_match_ptr(fotg210_ehci_match),
},
.probe  = fotg210_hcd_probe,
.remove = fotg210_hcd_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

Re: [PATCH 1/3 v2] usb: host: fotg2: add device tree probing

[Hans Ulli Kroll]

Hi Linus

On Fri, 10 Feb 2017, Linus Walleij wrote:

> On Thu, Feb 9, 2017 at 3:20 PM, Hans Ulli Kroll
>  wrote:
> 
> > Add device tree probe for fotg2 driver
> >
> > v2:
> > fix in wrong MODULE_DEVICE_TABLE
> >
> > Signed-off-by: Hans Ulli Kroll 
> 
> Acked-by: Linus Walleij 
> 
> > +   /* Right now device-tree probed devices don't get dma_mask set.
> > +* Since shared usb code relies on it, set it here for now.
> > +* Once we have dma capability bindings this can go away.
> > +*/
> > +
> > +   retval = dma_coerce_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> > +   if (retval)
> > +   goto fail_create_hcd;
> 
> Were you able to test this part? 

The driver itself is tested on my NAS 4220, which has *two* USB Ports. I 
transfered about 4 GB from one USB thumb drive to another one.

I must check my Inventory. I can remember of some Samsung SE-208BW.
It's CD/DVD Wifi device which uses also Gemini SoC, and has one host and 
gadget port.

And with the handling with the gadget port is odd. If this is connected 
with an USB host controller all parts are powerd off, only the CD/DVD part 
is running and the USB lines are passed trough. So there must be some 
switch device here.

There is also some VBUS and USB-ID pins controlled by the Gemini SoC, but 
these are not used on my NAS, maybe the CD/DVD Writer.

> I saw the gemini has some DMA engine
> but I never saw a driver for it. It looks like a reasonable thing to do to
> my untrained DMA eye.

I think the DMA engine is used for other stuff.
Some quick grep with SL2312_GENERAL_DMA_BASE and WRITE_DMA_REG
in the NAS 4420 sources 

drivers/char/gemini_i2s.c
drivers/telephony/gemini_ssp.c
drivers/telephony/gemini_ssp.h
include/asm-arm/arch-sl2312/gemini_i2s.h
include/asm-arm/arch-sl2312/gemini_ssp.h
sound/oss/Storm_ssp.c
sound/oss/storm_ssp.h

sound (via i2s) and telephone ???

Oh and your powercontroler is in
drivers/char/gemini_pwr.c

Greetings
Hans Ulli Kroll

--
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: gadget: properly increment dequeue pointer on ep_dequeue

[Felipe Balbi]

If request was already started, this means we had to
stop the transfer. With that we also need to ignore
all TRBs used by the request, however TRBs can only
be modified after completion of END_TRANSFER
command. So what we have to do here is wait for
END_TRANSFER completion and only after that jump
over TRBs by clearing HWO and incrementing dequeue
pointer.

Note that we have 2 possible types of transfers
here:

i) Linear buffer request
ii) SG-list based request

SG-list based requests will have r->num_pending_sgs
set to a valid number (> 0). Linear requests,
normally use a single TRB.

For each of these two cases, if r->unaligned flag is
set, one extra TRB has been used to align transfer
size to wMaxPacketSize.

All of these cases need to be taken into
consideration so we don't mess up our TRB ring
pointers.

Tested-by: Janusz Dziedzic 
Signed-off-by: Felipe Balbi 
---

Will be sent on pull request after -rc1 is tagged

 drivers/usb/dwc3/gadget.c | 63 +++
 1 file changed, 63 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4db97ecae885..f875b3f4b0ec 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1342,6 +1342,68 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
if (r == req) {
/* wait until it is processed */
dwc3_stop_active_transfer(dwc, dep->number, true);
+
+   /*
+* If request was already started, this means we had to
+* stop the transfer. With that we also need to ignore
+* all TRBs used by the request, however TRBs can only
+* be modified after completion of END_TRANSFER
+* command. So what we do here is that we wait for
+* END_TRANSFER completion and only after that, we jump
+* over TRBs by clearing HWO and incrementing dequeue
+* pointer.
+*
+* Note that we have 2 possible types of transfers here:
+*
+* i) Linear buffer request
+* ii) SG-list based request
+*
+* SG-list based requests will have r->num_pending_sgs
+* set to a valid number (> 0). Linear requests,
+* normally use a single TRB.
+*
+* For each of these two cases, if r->unaligned flag is
+* set, one extra TRB has been used to align transfer
+* size to wMaxPacketSize.
+*
+* All of these cases need to be taken into
+* consideration so we don't mess up our TRB ring
+* pointers.
+*/
+   wait_event_lock_irq(dep->wait_end_transfer,
+   !(dep->flags & 
DWC3_EP_END_TRANSFER_PENDING),
+   dwc->lock);
+
+   if (!r->trb)
+   goto out1;
+
+   if (r->num_pending_sgs) {
+   struct dwc3_trb *trb;
+   int i = 0;
+
+   for (i = 0; i < r->num_pending_sgs; i++) {
+   trb = r->trb + i;
+   trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+   dwc3_ep_inc_deq(dep);
+   }
+
+   if (r->unaligned) {
+   trb = r->trb + r->num_pending_sgs + 1;
+   trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+   dwc3_ep_inc_deq(dep);
+   }
+   } else {
+   struct dwc3_trb *trb = r->trb;
+
+   trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+   dwc3_ep_inc_deq(dep);
+
+   if (r->unaligned) {
+   trb = r->trb + 1;
+   trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+   dwc3_ep_inc_deq(dep);
+   }
+   }
goto out1;
}
dev_err(dwc->dev, "request %p was not queued to %s\n",
@@ -1352,6 +1414,7 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
 
 out1:
/* giveback the request */
+   dep->queued_requests--;
dwc3_gadget_giveback(dep, req, -ECONNRESET);
 
 out0:
-- 

Re: [PATCH v3] watchdog: add driver for StreamLabs USB watchdog device

[Guenter Roeck]

On 02/17/2017 01:25 AM, Alexey Klimov wrote:

This patch creates new driver that supports StreamLabs usb watchdog
device. This device plugs into 9-pin usb header and connects to
reset pin and reset button on common PC.

USB commands used to communicate with device were reverse
engineered using usbmon.

Signed-off-by: Alexey Klimov 
---

Changes in v3:
 -- coding style cleanups and rebase;
 -- buffer is allocated with separate allocation;
 -- adding comments about max/min limits;
 -- rework start/stop commands implementation;
 -- fix first if-check in probe() function;

Previous version: https://www.spinics.net/lists/linux-watchdog/msg09092.html

 drivers/watchdog/Kconfig  |  16 ++
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/streamlabs_wdt.c | 321 ++
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/watchdog/streamlabs_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b53a520..6a2195d8cc5c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1852,6 +1852,22 @@ config USBPCWATCHDOG

  Most people will say N.

+config USB_STREAMLABS_WATCHDOG
+   tristate "StreamLabs USB watchdog driver"
+   depends on USB
+   ---help---
+ This is the driver for the USB Watchdog dongle from StreamLabs.
+ If you correctly connect reset pins to motherboard Reset pin and
+ to Reset button then this device will simply watch your kernel to make
+ sure it doesn't freeze, and if it does, it reboots your computer
+ after a certain amount of time.
+
+
+ To compile this driver as a module, choose M here: the
+ module will be called streamlabs_wdt.
+
+ Most people will say N. Say yes or M if you want to use such usb 
device.
+
 comment "Watchdog Pretimeout Governors"

 config WATCHDOG_PRETIMEOUT_GOV
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e3c334..d4a61222ccd2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_WDTPCI) += wdt_pci.o

 # USB-based Watchdog Cards
 obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
+obj-$(CONFIG_USB_STREAMLABS_WATCHDOG) += streamlabs_wdt.o

 # ALPHA Architecture

diff --git a/drivers/watchdog/streamlabs_wdt.c 
b/drivers/watchdog/streamlabs_wdt.c
new file mode 100644
index ..4442d053d9f7
--- /dev/null
+++ b/drivers/watchdog/streamlabs_wdt.c
@@ -0,0 +1,321 @@
+/*
+ * StreamLabs USB Watchdog driver
+ *
+ * Copyright (c) 2016-2017 Alexey Klimov 
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * USB Watchdog device from Streamlabs:
+ * https://www.stream-labs.com/en/catalog/?cat_id=1203_id=323
+ *
+ * USB commands have been reverse engineered using usbmon.
+ */
+
+#define DRIVER_AUTHOR "Alexey Klimov "
+#define DRIVER_DESC "StreamLabs USB watchdog driver"
+#define DRIVER_NAME "usb_streamlabs_wdt"
+
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+
+#define USB_STREAMLABS_WATCHDOG_VENDOR 0x13c0
+#define USB_STREAMLABS_WATCHDOG_PRODUCT0x0011
+
+/*
+ * one buffer is used for communication, however transmitted message is only
+ * 32 bytes long
+ */
+#define BUFFER_TRANSFER_LENGTH 32
+#define BUFFER_LENGTH  64
+#define USB_TIMEOUT350
+
+#define STREAMLABS_CMD_START   0xaacc
+#define STREAMLABS_CMD_STOP0xbbff
+
+/* timeouts values are taken from windows program */
+#define STREAMLABS_WDT_MIN_TIMEOUT 1
+#define STREAMLABS_WDT_MAX_TIMEOUT 46
+
+struct streamlabs_wdt {
+   struct watchdog_device wdt_dev;
+   struct usb_interface *intf;
+
+   struct mutex lock;
+   u8 *buffer;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+/*
+ * This function is used to check if watchdog actually changed
+ * its state to disabled that is reported in first two bytes of response
+ * message.
+ */
+static int usb_streamlabs_wdt_check_stop(u16 *buf)
+{
+   if (buf[0] != cpu_to_le16(STREAMLABS_CMD_STOP))
+   return -EINVAL;
+
+   return 0;
+}
+
+static int usb_streamlabs_wdt_validate_response(u8 *buf)
+{
+   /*
+* If watchdog device understood the command it will acknowledge
+* with values 1,2,3,4 at indexes 10, 11, 12, 13 in response message
+* when 

Re: [PATCH 2/3] usb: add DT bindings for farady fotg2 host controller

[Hans Ulli Kroll]

Hi Rob,

On Wed, 15 Feb 2017, Rob Herring wrote:

> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote:
> > This adds DT bindings for the Faraday FOTG2 host controller.
> > 
> > Signed-off-by: Hans Ulli Kroll 
> > ---
> >  Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++
> >  1 file changed, 15 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt 
> > b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> > new file mode 100644
> > index ..4c07566a4bf5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> > @@ -0,0 +1,15 @@
> > +Faraday FOTG Host controller
> > +
> > +Required properties:
> > +
> > +- compatible: should be "faraday,fotg210-hcd"
> 
> hcd as in "host controller driver"? Bindings describe h/w not drivers.
> 
> It's an OTG controller or host controller?
> 

here only the host controller part used.

faraday fotg2 is a dual role hcd/otg device and here is only the 
host part used.

Greetings
ans Ulli Kroll

--
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 v3] watchdog: add driver for StreamLabs USB watchdog device

[Alexey Klimov]

This patch creates new driver that supports StreamLabs usb watchdog
device. This device plugs into 9-pin usb header and connects to
reset pin and reset button on common PC.

USB commands used to communicate with device were reverse
engineered using usbmon.

Signed-off-by: Alexey Klimov 
---

Changes in v3:
 -- coding style cleanups and rebase;
 -- buffer is allocated with separate allocation;
 -- adding comments about max/min limits;
 -- rework start/stop commands implementation;
 -- fix first if-check in probe() function;

Previous version: https://www.spinics.net/lists/linux-watchdog/msg09092.html

 drivers/watchdog/Kconfig  |  16 ++
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/streamlabs_wdt.c | 321 ++
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/watchdog/streamlabs_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b53a520..6a2195d8cc5c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1852,6 +1852,22 @@ config USBPCWATCHDOG
 
  Most people will say N.
 
+config USB_STREAMLABS_WATCHDOG
+   tristate "StreamLabs USB watchdog driver"
+   depends on USB
+   ---help---
+ This is the driver for the USB Watchdog dongle from StreamLabs.
+ If you correctly connect reset pins to motherboard Reset pin and
+ to Reset button then this device will simply watch your kernel to make
+ sure it doesn't freeze, and if it does, it reboots your computer
+ after a certain amount of time.
+
+
+ To compile this driver as a module, choose M here: the
+ module will be called streamlabs_wdt.
+
+ Most people will say N. Say yes or M if you want to use such usb 
device.
+
 comment "Watchdog Pretimeout Governors"
 
 config WATCHDOG_PRETIMEOUT_GOV
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e3c334..d4a61222ccd2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_WDTPCI) += wdt_pci.o
 
 # USB-based Watchdog Cards
 obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
+obj-$(CONFIG_USB_STREAMLABS_WATCHDOG) += streamlabs_wdt.o
 
 # ALPHA Architecture
 
diff --git a/drivers/watchdog/streamlabs_wdt.c 
b/drivers/watchdog/streamlabs_wdt.c
new file mode 100644
index ..4442d053d9f7
--- /dev/null
+++ b/drivers/watchdog/streamlabs_wdt.c
@@ -0,0 +1,321 @@
+/*
+ * StreamLabs USB Watchdog driver
+ *
+ * Copyright (c) 2016-2017 Alexey Klimov 
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * USB Watchdog device from Streamlabs:
+ * https://www.stream-labs.com/en/catalog/?cat_id=1203_id=323
+ *
+ * USB commands have been reverse engineered using usbmon.
+ */
+
+#define DRIVER_AUTHOR "Alexey Klimov "
+#define DRIVER_DESC "StreamLabs USB watchdog driver"
+#define DRIVER_NAME "usb_streamlabs_wdt"
+
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
+
+#define USB_STREAMLABS_WATCHDOG_VENDOR 0x13c0
+#define USB_STREAMLABS_WATCHDOG_PRODUCT0x0011
+
+/*
+ * one buffer is used for communication, however transmitted message is only
+ * 32 bytes long
+ */
+#define BUFFER_TRANSFER_LENGTH 32
+#define BUFFER_LENGTH  64
+#define USB_TIMEOUT350
+
+#define STREAMLABS_CMD_START   0xaacc
+#define STREAMLABS_CMD_STOP0xbbff
+
+/* timeouts values are taken from windows program */
+#define STREAMLABS_WDT_MIN_TIMEOUT 1
+#define STREAMLABS_WDT_MAX_TIMEOUT 46
+
+struct streamlabs_wdt {
+   struct watchdog_device wdt_dev;
+   struct usb_interface *intf;
+
+   struct mutex lock;
+   u8 *buffer;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+/*
+ * This function is used to check if watchdog actually changed
+ * its state to disabled that is reported in first two bytes of response
+ * message.
+ */
+static int usb_streamlabs_wdt_check_stop(u16 *buf)
+{
+   if (buf[0] != cpu_to_le16(STREAMLABS_CMD_STOP))
+   return -EINVAL;
+
+   return 0;
+}
+
+static int usb_streamlabs_wdt_validate_response(u8 *buf)
+{
+   /*
+* If watchdog device understood the command it will acknowledge
+* with values 1,2,3,4 at indexes 10, 11, 12, 13 in response message
+* when response treated as 8bit message.
+*/
+  

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Felipe Balbi]

Hi,

Baolin Wang  writes:
>>> (One possible approach would be to have the setup routine return
>>> different values for explicit and implicit status stages -- for
>>> example, return 1 if it wants to submit an explicit status request.
>>> That wouldn't be very different from the current
>>> USB_GADGET_DELAYED_STATUS approach.)
>>
>> not really, no. The idea was for composite.c and/or functions to support
>> both methods (temporarily) and use "gadget->wants_explicit_stages" to
>> explicitly queue DATA and STATUS. That would mean that f_mass_storage
>> wouldn't have to return DELAYED_STATUS if
>> (gadget->wants_explicit_stages).
>>
>> After all UDCs are converted over and set wants_explicit_stages (which
>> should all be done in a single series), then we get rid of the flag and
>> the older method of DELAYED_STATUS.
>
> (Sorry for late reply due to my holiday)
> I also met the problem pointed by Alan, from my test, I still want to
> need one return value to indicate if it wants to submit an explicit
> status request. Think about the Control-IN with a data stage, we can
> not get the STATUS phase request from usb_ep_queue() call, and we need

why not? wLength tells you that this is a 3-stage transfer. Gadget
driver should be able to figure out that it needs to usb_ep_queue()
another request for status stage.

> to handle this STATUS phase request in dwc3_ep0_xfernotready(). But
> Control-OUT will get one 0-length IN request for the status stage from
> usb_ep_queue(), so we need one return value from setup routine to

no we don't :-)

> distinguish these in dwc3_ep0_xfernotready(), or we can not handle
> status request correctly. Maybe I missed something else.
>>
>>> On the other hand, I am very doubtful about requiring explicit setup
>>> requests.
>>
>> right, me too ;-)
>
> So do you suggest me continue to try to do this? Thanks.

explicit setup? no
explicit status? yes

If you don't wanna do it, it's fine :-) I'll just add to my TODO
list. It just depends on how much other tasks you have on your end ;-)

-- 
balbi


signature.asc
Description: PGP signature