Re: [PATCH v2] usb: chipdata: Replace the extcon API

2016-12-30 Thread Chanwoo Choi
Hi Peter,

Please ignore this patch. After posting this patch, I got that this patch was 
already merged by you. I'm sorry to make the confusion.

Regards,
Chanwoo Choi

On 2016년 12월 30일 13:15, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
> 
> Cc: Peter Chen 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Rebase these patches based on v4.10-rc1.
> - Drop the phy/power-supply/dwc3/omap patches.
> 
>  drivers/usb/chipidea/core.c | 30 ++
>  1 file changed, 6 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 3dbb4a21ab44..5c35f25e9bce 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_vbus;
>  
>   if (!IS_ERR(ext_vbus)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
> + ret = extcon_get_state(cable->edev, EXTCON_USB);
>   if (ret)
>   cable->state = true;
>   else
> @@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
>   cable->edev = ext_id;
>  
>   if (!IS_ERR(ext_id)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
> + ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
>   if (ret)
>   cable->state = false;
>   else
> @@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   id = &ci->platdata->id_extcon;
>   id->ci = ci;
>   if (!IS_ERR(id->edev)) {
> - ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
> -&id->nb);
> + ret = devm_extcon_register_notifier(ci->dev, id->edev,
> + EXTCON_USB_HOST, &id->nb);
>   if (ret < 0) {
>   dev_err(ci->dev, "register ID failed\n");
>   return ret;
> @@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   vbus = &ci->platdata->vbus_extcon;
>   vbus->ci = ci;
>   if (!IS_ERR(vbus->edev)) {
> - ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
> -&vbus->nb);
> + ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
> + EXTCON_USB, &vbus->nb);
>   if (ret < 0) {
> - extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
> -&id->nb);
>   dev_err(ci->dev, "register VBUS failed\n");
>   return ret;
>   }
> @@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
>   return 0;
>  }
>  
> -static void ci_extcon_unregister(struct ci_hdrc *ci)
> -{
> - struct ci_hdrc_cable *cable;
> -
> - cable = &ci->platdata->id_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
> -&cable->nb);
> -
> - cable = &ci->platdata->vbus_extcon;
> - if (!IS_ERR(cable->edev))
> - extcon_unregister_notifier(cable->edev, EXTCON_USB, &cable->nb);
> -}
> -
>  static DEFINE_IDA(ci_ida);
>  
>  struct platform_device *ci_hdrc_add_device(struct device *dev,
> @@ -1054,7 +1038,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   if (!ret)
>   return 0;
>  
> - ci_extcon_unregister(ci);
>  stop:
>   ci_role_destroy(ci);
>  deinit_phy:
> @@ -1074,7 +1057,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
>   }
>  
>   dbg_remove_files(ci);
> - ci_extcon_unregister(ci);
>   ci_role_destroy(ci);
>   ci_hdrc_enter_lpm(ci, true);
>   ci_usb_phy_exit(ci);
> 

--
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: orinoco: Use shash instead of ahash for MIC calculations

2016-12-30 Thread Kalle Valo
Andrew Lutomirski  wrote:
> Eric Biggers pointed out that the orinoco driver pointed scatterlists
> at the stack.
> 
> Fix it by switching from ahash to shash.  The result should be
> simpler, faster, and more correct.
> 
> Cc: sta...@vger.kernel.org # 4.9 only
> Reported-by: Eric Biggers 
> Signed-off-by: Andy Lutomirski 

11 patches applied to wireless-drivers-next.git, thanks.

1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
8845254112ac rt2800: rename adjust_freq_offset function
bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
d96324703ffa rt2x00: merge agc and vco works with link tuner
eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch

-- 
https://patchwork.kernel.org/patch/9471353/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

--
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: orinoco: Use shash instead of ahash for MIC calculations

2016-12-30 Thread Kalle Valo
Kalle Valo  writes:

> Andrew Lutomirski  wrote:
>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>> at the stack.
>> 
>> Fix it by switching from ahash to shash.  The result should be
>> simpler, faster, and more correct.
>> 
>> Cc: sta...@vger.kernel.org # 4.9 only
>> Reported-by: Eric Biggers 
>> Signed-off-by: Andy Lutomirski 
>
> 11 patches applied to wireless-drivers-next.git, thanks.
>
> 1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
> a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
> e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
> a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
> 8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
> 8845254112ac rt2800: rename adjust_freq_offset function
> bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
> 24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
> d96324703ffa rt2x00: merge agc and vco works with link tuner
> eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
> 31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch

Oh man, when I was applying rt2800 patches I did an off by one error
with my patchwork script ('commit 2-12' vs 'commit 1-11') and
accidentally applied this orinoco patch to wireless-drivers-next along
with the 10 rt2800 patches above. And failed to spot that before pushing
the tree :(

As this orinoco patch is pretty important I'll cherry pick it manually
to wireless-drivers also so that it goes to 4.10. This means that the
patch is in both trees, but just with a different commit id.

Sorry for the mess.

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


xHCI issues Reset Device Command at invalid states

2016-12-30 Thread Felipe Balbi

Hi Mathias,

So the problem I found with v4.10-rc1 doesn't appear to be a
regression. I can't, however, trigger it with Broadwell, only Skylake
and Kabylake.

According to tracepoints, our Reset Device Command sometimes completes
with "Context State Error", which tells us that we're issuing Reset
Device Command when we shouldn't.

Another thing I noticed is that we're clearing PortFeature(PortReset)
less than 20ms after setting it. Full tracepoint data attached (slot 28
is the device in question. Slot 12, AFAICT, it's parent hub), but here's
a snippet showing both problems:

> device-reset-2819  [002]    154.793058: xhci_urb_enqueue: ep0out-control: 
> urb 8801b8cc90c0 pipe 2147485696 slot 12 length 0/0 sgs 0/0 stream 0 
> flags 0010
> device-reset-2819  [002] d..1   154.793059: xhci_queue_trb: CTRL: 
> bRequestType 23 bRequest 03 wValue 0004 wIndex 0001 wLength 0 length 8 TD 
> size 0 intr 0 type 'Setup Stage' flags b:I:i:c:s:i:e:c

SetPorFeature(PortReset, 1);

> device-reset-2819  [002] d..1   154.793059: xhci_queue_trb: CTRL: Buffer 
>  length 0 TD size 0 intr 0 type 'Status Stage' flags 
> b:i:I:c:s:i:e:C
>   -0 [002] d.h2   154.805677: xhci_handle_event: EVENT: TRB 
> 0001bd90f2b0 status 'Success' len 0 slot 12 ep 1 type 'Transfer Event' 
> flags e:C
>   -0 [002] d.h2   154.805679: xhci_handle_transfer: CTRL: 
> Buffer  length 0 TD size 0 intr 0 type 'Status Stage' flags 
> b:i:I:c:s:i:e:C
>   -0 [002] dNh1   154.805682: xhci_urb_giveback: 
> ep0out-control: urb 8801b8cc90c0 pipe 2147485696 slot 12 length 0/0 sgs 
> 0/0 stream 0 flags 

Hub acked the transfer. Note success status above. Also note timestamp.

> device-reset-2819  [002]    154.816800: xhci_urb_enqueue: ep0out-control: 
> urb 8801b8cc90c0 pipe 2147485824 slot 12 length 0/4 sgs 0/0 stream 0 
> flags 00110200
> device-reset-2819  [002] d..1   154.816800: xhci_queue_trb: CTRL: 
> bRequestType a3 bRequest 00 wValue  wIndex 0001 wLength 4 length 8 TD 
> size 0 intr 0 type 'Setup Stage' flags b:I:i:c:s:i:e:c

GetPortStatus(1);

> device-reset-2819  [002] d..1   154.816800: xhci_queue_trb: CTRL: Buffer 
> 0001bd6dada0 length 4 TD size 0 intr 0 type 'Data Stage' flags 
> b:i:i:c:s:I:e:C
> device-reset-2819  [002] d..1   154.816800: xhci_queue_trb: CTRL: Buffer 
>  length 0 TD size 0 intr 0 type 'Status Stage' flags 
> b:i:I:c:s:i:e:C
>   -0 [002] d.h2   154.816909: xhci_handle_event: EVENT: TRB 
> 0001bd90f2e0 status 'Success' len 0 slot 12 ep 1 type 'Transfer Event' 
> flags e:C
>   -0 [002] d.h2   154.816910: xhci_handle_transfer: CTRL: 
> Buffer  length 0 TD size 0 intr 0 type 'Status Stage' flags 
> b:i:I:c:s:i:e:C
>   -0 [002] dNh1   154.816910: xhci_urb_giveback: 
> ep0out-control: urb 8801b8cc90c0 pipe 2147485824 slot 12 length 4/4 sgs 
> 0/0 stream 0 flags 0200
> device-reset-2819  [002]    154.816914: xhci_urb_enqueue: ep0out-control: 
> urb 8801b8cc90c0 pipe 2147485696 slot 12 length 0/0 sgs 0/0 stream 0 
> flags 0010
> device-reset-2819  [002] d..1   154.816914: xhci_queue_trb: CTRL: 
> bRequestType 23 bRequest 01 wValue 0014 wIndex 0001 wLength 0 length 8 TD 
> size 0 intr 0 type 'Setup Stage' flags b:I:i:c:s:i:e:c

CleartPortFeature(C_PortReset, 1);

> device-reset-2819  [002] d..1   154.816915: xhci_queue_trb: CTRL: Buffer 
>  length 0 TD size 0 intr 0 type 'Status Stage' flags 
> b:i:I:c:s:i:e:C
>   -0 [002] d.h2   154.817056: xhci_handle_event: EVENT: TRB 
> 0001bd90f300 status 'Success' len 0 slot 12 ep 1 type 'Transfer Event' 
> flags e:C
>   -0 [002] d.h2   154.817056: xhci_handle_transfer: CTRL: 
> Buffer  length 0 TD size 0 intr 0 type 'Status Stage' flags 
> b:i:I:c:s:i:e:C
>   -0 [002] dNh1   154.817057: xhci_urb_giveback: 
> ep0out-control: urb 8801b8cc90c0 pipe 2147485696 slot 12 length 0/0 sgs 
> 0/0 stream 0 flags 

completed. It took 0.011375 S, or 11.375 mS. Even though we had a
GetPortStatus() in between. This should've been more than 20 mS, right? 

> device-reset-2819  [002] d..1   154.868782: xhci_queue_trb: CMD: Reset Device 
> Command: slot 28 flags C
>   -0 [003] d.h2   154.868832: xhci_handle_event: EVENT: TRB 
> 0001be2b2e60 status 'Context State Error' len 0 slot 28 ep 0 type 
> 'Command Completion Event' flags e:C

And here's xHCI telling us that slot 28's Context was is invalid status.

>   -0 [003] d.h2   154.868832: xhci_handle_command: CMD: Reset 
> Device Command: slot 28 flags C
> device-reset-2819  [002]    154.868961: xhci_dbg_address: Successful 
> setup address command
> device-reset-2819  [002]    154.868963: xhci_dbg_address: Op regs DCBAA 
> ptr = 0x01be2b3000
> device-reset-2819  [002]    154.868964: xhci_dbg_address: Slot ID 28 
> dcbaa entry @8801be2b30e0 = 0x01b8f89000
> device-reset-2819  [002] .

Re: orinoco: Use shash instead of ahash for MIC calculations

2016-12-30 Thread Kalle Valo
Kalle Valo  writes:

> Kalle Valo  writes:
>
>> Andrew Lutomirski  wrote:
>>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>>> at the stack.
>>> 
>>> Fix it by switching from ahash to shash.  The result should be
>>> simpler, faster, and more correct.
>>> 
>>> Cc: sta...@vger.kernel.org # 4.9 only
>>> Reported-by: Eric Biggers 
>>> Signed-off-by: Andy Lutomirski 
>>
>> 11 patches applied to wireless-drivers-next.git, thanks.
>>
>> 1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
>> a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
>> e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
>> a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
>> 8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
>> 8845254112ac rt2800: rename adjust_freq_offset function
>> bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
>> 24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
>> d96324703ffa rt2x00: merge agc and vco works with link tuner
>> eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
>> 31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
>
> Oh man, when I was applying rt2800 patches I did an off by one error
> with my patchwork script ('commit 2-12' vs 'commit 1-11') and
> accidentally applied this orinoco patch to wireless-drivers-next along
> with the 10 rt2800 patches above. And failed to spot that before pushing
> the tree :(
>
> As this orinoco patch is pretty important I'll cherry pick it manually
> to wireless-drivers also so that it goes to 4.10. This means that the
> patch is in both trees, but just with a different commit id.

This is the commit in wireless-drivers:

commit 570b90fa230b8021f51a67fab2245fe8df6fe37d
Author: Andrew Lutomirski 
Date:   Mon Dec 12 12:55:55 2016 -0800

orinoco: Use shash instead of ahash for MIC calculations

Eric Biggers pointed out that the orinoco driver pointed
scatterlists
at the stack.

Fix it by switching from ahash to shash.  The result should be
simpler, faster, and more correct.

kvalo: cherry picked from commit
1fef293b8a9850cfa124a53c1d8878d355010403 as I
accidentally applied this patch to wireless-drivers-next when I was
supposed to
apply this wireless-drivers

Cc: sta...@vger.kernel.org # 4.9 only
Reported-by: Eric Biggers 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Kalle Valo 

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


[no subject]

2016-12-30 Thread christina koch
Ciao,

è un piacere conoscerti.Io sono Christina H. Koch, uno Stato ufficiale
dell'Esercito da stati uniti d'America,ho una cosa importante da
discutere con te, che può portare a un business partner o
qualcos'altro, mi presento meglio e inviare le mie foto non appena ho
ricevuto la tua mail.

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


dwc3 gadget broken on 4.10-rc1 + Andy's Edison patches

2016-12-30 Thread Vincent Pelletier
Hello,

While testing Andy's current Edison kernel[1], I notice a regression
compared to the 4.9-rc8:
loading dwc3 module emits:
  [ 1637.327602] dwc3 dwc3.1.auto: can't allocate event buffer
  [ 1637.333201] dwc3 dwc3.1.auto: failed to allocate event buffers
  [ 1637.341101] dwc3: probe of dwc3.1.auto failed with error -12

A quick kgdb session finds:
  Thread 121 hit Breakpoint 3, dma_alloc_from_coherent
(dev=0xf4e6440c, size=256, dma_handle=0xf4901eac, ret=0xf4895cd8) at
drivers/base/dma-coherent.c:165
  165 int order = get_order(size);
  (gdb) print dev->dma_mem
  $8 = (struct dma_coherent_mem *) 0x0

Which I traced back to:
  commit d64ff406e51e4f359afedbf2468a10440d6d8cef
  Author: Arnd Bergmann 
  Date:   Thu Nov 17 17:13:47 2016 +0530

 usb: dwc3: use bus->sysdev for DMA configuration

I am not sure where to go from here: I believe there is no specific
change in Andy's tree related to the dwc3, but I'm not familiar with
how devices are discovered (and even less how dma memory is assigned).
I did not (yet) tried with this commit (and the one following it)
reverted.

[1] https://github.com/andy-shev/linux/tree/eds as of
3cfd6f93b96355542e044240f2daf11840dda0b2

Regards,
-- 
Vincent Pelletier
--
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: dwc3 gadget broken on 4.10-rc1 + Andy's Edison patches

2016-12-30 Thread Vincent Pelletier
...and I should have checked balbi/usb.git:testing/fixes, which
already has a fix for it:
  
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/fixes&id=a3543b33edc746870a540d40bda2916a1d107185

Sorry for the noise.
-- 
Vincent Pelletier
--
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