,Your urgent confirmation

[James Williams]

Attn: Beneficiary,

We have contacted the Federal Ministry of Finance on your Behalf and
they have brought a solution to your problem by coordinating your
payment in total (10,000,000.00) Ten Million Dollars in an atm card
which you can use to withdraw money from any ATM MACHINE CENTER
anywhere in the world with a maximum of 1 Dollars daily. You now
have the lawful right to claim your fund in an atm card. Since the
Federal Bureau of Investigation is involved in this transaction, you
have to be rest assured for this is 100% risk free it is our duty to
protect the American Citizens, European Citizens, Asian Citizen. All I
want you to do is to contact the atm card CENTER Via email or call the
office telephone number one of the Consultant will assist you for
their requirements to proceed and procure your Approval Slip on your
behalf.

CONTACT INFORMATION
NAME: James  Williams
EMAIL: paymasterofficed...@gmail.com


Do contact us with your details:

Full name//
Address// Age//
 Telephone Numbers//
Occupation//
 Your Country//
Bank Details//

So your files would be updated after which the Delivery of your
atm card will be affected to your designated home Address without any
further delay and the bank will transfer your funds in total
(10,000,000.00) Ten Million Dollars to your Bank account. We
will reply you with the secret code (1600 atm card). We advice you get
back to the payment office after you have contacted the ATM SWIFT CARD
CENTER and we do await your response so we can move on with our
Investigation and make sure your ATM SWIFT CARD gets to you.


Best Regards
James Williams
Paymaster General
Federal Republic Of Nigeri
--
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 AUTOSEL for 4.9 002/190] usb: dwc2: Make sure we disconnect the gadget state

[Sasha Levin]

From: John Stultz 

[ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]

I had seen some odd behavior with HiKey's usb-gadget interface
that I finally seemed to have chased down. Basically every other
time I plugged in the OTG port, the gadget interface would
properly initialize. The other times, I'd get a big WARN_ON
in dwc2_hsotg_init_fifo() about the fifo_map not being clear.

Ends up if we don't disconnect the gadget state, the fifo-map
doesn't get cleared properly, which causes WARN_ON messages and
also results in the device not properly being setup as a gadget
every other time the OTG port is connected.

So this patch adds a call to dwc2_hsotg_disconnect() in the
reset path so the state is properly cleared.

With it, the gadget interface initializes properly on every
plug in.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: John Youn 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/dwc2/hcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index df5a06578005..dfc0566bb155 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3220,6 +3220,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(>lock, flags);
+   dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(>lock, flags);
dwc2_hsotg_core_connect(hsotg);
-- 
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH AUTOSEL for 4.4 001/101] usb: dwc2: Make sure we disconnect the gadget state

[Sasha Levin]

From: John Stultz 

[ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ]

I had seen some odd behavior with HiKey's usb-gadget interface
that I finally seemed to have chased down. Basically every other
time I plugged in the OTG port, the gadget interface would
properly initialize. The other times, I'd get a big WARN_ON
in dwc2_hsotg_init_fifo() about the fifo_map not being clear.

Ends up if we don't disconnect the gadget state, the fifo-map
doesn't get cleared properly, which causes WARN_ON messages and
also results in the device not properly being setup as a gadget
every other time the OTG port is connected.

So this patch adds a call to dwc2_hsotg_disconnect() in the
reset path so the state is properly cleared.

With it, the gadget interface initializes properly on every
plug in.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: John Youn 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/dwc2/hcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 571c21727ff9..88bd950665fa 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
dwc2_core_init(hsotg, false, -1);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(>lock, flags);
+   dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(>lock, flags);
dwc2_hsotg_core_connect(hsotg);
-- 
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5] usb: core: Add "quirks" parameter for usbcore

[Kai-Heng Feng]

Trying quirks in usbcore needs to rebuild the driver or the entire
kernel if it's builtin. It can save a lot of time if usbcore has similar
ability like "usbhid.quirks=" and "usb-storage.quirks=".

Rename the original quirk detection function to "static" as we introduce
this new "dynamic" function.

Now users can use "usbcore.quirks=" as short term workaround before the
next kernel release. Also, the quirk parameter can XOR the builtin
quirks for debugging purpose.

This is inspired by usbhid and usb-storage.

Signed-off-by: Kai-Heng Feng 
---
v5: Use module_param_cb() to get notified when parameter changes.
Replace linked list with array.

v4: Use kmalloc() to reduce memory usage.
Remove tolower() so we can use capital character in the future.

v3: Stop overridding static quirks.
Use XOR for dynamic quirks.
Save parsed quirk as a list to avoid parsing quirk table everytime.

v2: Use in-kernel tolower() function.

 Documentation/admin-guide/kernel-parameters.txt |  55 
 drivers/usb/core/quirks.c   | 177 +++-
 drivers/usb/core/usb.c  |   1 +
 drivers/usb/core/usb.h  |   1 +
 4 files changed, 229 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..70a7398c20e2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4368,6 +4368,61 @@
 
usbcore.nousb   [USB] Disable the USB subsystem
 
+   usbcore.quirks=
+   [USB] A list of quirks entries to supplement or
+   override the built-in usb core quirk list.  List
+   entries are separated by commas.  Each entry has
+   the form VID:PID:Flags where VID and PID are Vendor
+   and Product ID values (4-digit hex numbers) and
+   Flags is a set of characters, each corresponding
+   to a common usb core quirk flag as follows:
+   a = USB_QUIRK_STRING_FETCH_255 (string
+   descriptors must not be fetched using
+   a 255-byte read);
+   b = USB_QUIRK_RESET_RESUME (device can't resume
+   correctly so reset it instead);
+   c = USB_QUIRK_NO_SET_INTF (device can't handle
+   Set-Interface requests);
+   d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
+   handle its Configuration or Interface
+   strings);
+   e = USB_QUIRK_RESET (device can't be reset
+   (e.g morph devices), don't use reset);
+   f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
+   more interface descriptions than the
+   bNumInterfaces count, and can't handle
+   talking to these interfaces);
+   g = USB_QUIRK_DELAY_INIT (device needs a pause
+   during initialization, after we read
+   the device descriptor);
+   h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
+   high speed and super speed interrupt
+   endpoints, the USB 2.0 and USB 3.0 spec
+   require the interval in microframes (1
+   microframe = 125 microseconds) to be
+   calculated as interval = 2 ^
+   (bInterval-1).
+   Devices with this quirk report their
+   bInterval as the result of this
+   calculation instead of the exponent
+   variable used in the calculation);
+   i = USB_QUIRK_DEVICE_QUALIFIER (device can't
+   handle device_qualifier descriptor
+   requests);
+   j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
+   generates spurious wakeup, ignore
+   remote wakeup capability);
+   k = USB_QUIRK_NO_LPM (device can't handle Link
+   Power Management);
+   l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
+  

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Chanwoo Choi]

Hi Andrzej, Archit,

On 2018년 03월 07일 20:13, Andrzej Hajda wrote:
> Hi Chanwoo, Archit,
> 
> On 07.03.2018 05:48, Chanwoo Choi wrote:
>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>>> Hi Rob and Andrzej,
>>>
>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
 Hi Rob, Chanwoo, Krzysztof,


 On 27.02.2018 08:11, Andrzej Hajda wrote:
> Hi,
>
> Thanks for reviews of previous iterations.
>
> This patchset introduces USB physical connector bindings, together with
> working example.
> I have removed RFC prefix - the patchset seems to be heading
> to a happy end :)
>
> v5: fixed extra parenthesis in dts, renamed extcon function.
> v4: improved binding descriptions, added missing reg in dts.
> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
> example.
> v2: I have addressed comments by Rob and Laurent, thanks 
>
> Changes in datail are described in the patches.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (5):
>   dt-bindings: add bindings for USB physical connector
>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>   arm64: dts: exynos: add OF graph between MHL and USB connector
>   extcon: add possibility to get extcon device by OF node
>
> Maciej Purski (1):
>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
 It looks like all patches received R-B or acks (I forgot add Krzysztof's
 acks for dts part).
 Now I have a question how to merge them.
 The only functional dependency is between bridge and extcon, and from
 the formal PoV bindings should be merged 1st.
 I can merge it:
 1. All patches via drm-misc tree.
 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
 samsung-soc tree.

 Is it OK, for all? Better ideas?
>>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>>> v4.16-rc1
>>> and apply them except for dts patchs. And I'll send the immutable branch to 
>>> Rob and Andrzej.
>>>
>>>
>> I made the immutable branch[1] as following: If you agree, I'll send pull 
>> request.
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>>
>> Or you can make the immutable branch and send pull request to Rob and me.
>>
> 
> It seems you took v5 instead of v6 version of extcon patch.

My mistake. I picked v6 and made the new immutable branch.
After Archit confirm it, I'll send pull request.

> 
> Beside it I am OK with your immutable branch, Archit is it OK to do it
> this way in drm-misc?
> 
> 
> Regards
> 
> Andrzej
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


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

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

Hi
> -Original Message-
> From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> Sent: 2018年3月6日 20:02
> To: Jun Li 
> Cc: Andrzej Hajda ; gre...@linuxfoundation.org;
> robh...@kernel.org; li...@roeck-us.net; mark.rutl...@arm.com;
> yue...@google.com; Peter Chen ;
> garsi...@embeddedor.com; o_leve...@orange.fr;
> shufan_...@richtek.com; linux-usb@vger.kernel.org;
> devicet...@vger.kernel.org; dl-linux-imx 
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> Hi guys,
> 
> On Tue, Mar 06, 2018 at 09:38:59AM +, Jun Li wrote:
> > > >>> diff --git
> > > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> index e1463f1..242f6df 100644
> > > >>> ---
> > > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> +++
> > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> @@ -15,6 +15,30 @@ Optional properties:
> > > >>>  - type: size of the connector, should be specified in case of
> > > >>> USB-A,
> > > USB-B
> > > >>>non-fullsize connectors: "mini", "micro".
> > > >>>
> > > >>> +Required properties for usb-c-connector with power delivery
> support:
> > > >>> +- port-type: should be one of "source", "sink" or "dual".
> > > >>> +- default-role: preferred power role if port-type is
> > > >>> +"dual"(drp), should be
> > > >>> +  "sink" or "source".
> > > >> Since port carries data and power, it would be better to
> > > >> explicitly mention it in names of properties which can be ambiguous.
> > > >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > > > Port-type is align with the name of typec coding and ABI, 'power-role'
> > > > is more like for the current role rather than the port's ability.
> > >
> > > I am not sure what are you exactly mean by "coding and ABI", but I
> > > guess it is just about Power-Delivery part of USB-C. And if you want
> > > to put this property into USB node without mark it is related to PD
> > > part of USB connector, you risk confusion with possible USB data related
> properties.
> >
> > Understood your concern, I am following typec naming conventions, for
> > typec, port-type property has the same meaning as
> > /sys/class/typec/portx/port_type which is not only for power, also for
> > data, there are dedicated sys files power_role for power and data_role
> > for data.
> >
> > > Simple question, what if somebody wants to add property describing
> > > USB data capabilities (DFP, UFP, DRD), how should it be named?
> > >
> >
> > Then we may use data-role?
> >
> > > >
> > > >> Other thing is that default-role is required only in case of DRP,
> > > >> so maybe better would be to squash it in power-role, for example:
> > > >> ?? power-role: should be on of "source", "sink",
> > > >> "dual-source", "dual-sink", in case of dual roles suffix determines
> preferred role.
> > > > I don't know how much this squash can benefit, "dual-source/sink"
> > > > is not directly showing its meaning by name.
> > >
> > > Some benefit is simpler binding, no conditionally-required property.
> > >
> >
> > There is already string definition for port type and preferred role
> > parse static const char * const typec_port_types[] = {
> >  [TYPEC_PORT_DFP] = "source",
> >  [TYPEC_PORT_UFP] = "sink",
> >  [TYPEC_PORT_DRP] = "dual",
> > };
> > And I think there will be other conditionally-required properties to
> > be extended later, are we going to name all of them by this way?
> > Either way is OK for me, I am not sure if there is principle like we
> > should avoid conditionally-required property, if we should, maybe
> > "dual-preferred-source/sink" is better.
> >
> > Hi Heikki,
> > Do you have any comments/preference here?
> 
> In the first versions of USB Type-C specification the data and power roles
> were in practice coupled together. There were no data role specific modes,
> just DFP, UFP and DRP. However, v1.2 of the spec.
> introduced separate modes for the data roles as well, and I have a patch for
> that (attached).
> 
> If you are asking my opinion, the data role must be handled as separate
> capability of the port, i.e. you probable want to have separate properties for
> the power role and data role, even if we did not support that yet in the class
> code. Don't use "port-type" name, just call them "power-role" and
> "data-role" from now on.
> 

OK, I will introduce power-role and data-role, meanwhile, I think the class code
should be changed accordingly(looks like your attached patch is doing that).

> The default-role should tell the state machines whether Try.SNK or Try.SRC
> states should be used or not. Perhaps you should have boolean property for
> both: "try-snk" and "try-src" (note: both can not be true).
> 

try-sink and try-source, both are optional, 

Re: [PATCH v5 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type

[Rob Herring]

On Tue, Mar 06, 2018 at 04:59:10PM +0800, Ran Wang wrote:
> Property "snps,incr-burst-type-adjustment = , ..." for USB3.0 DWC3.
> When only one value means INCRx mode with fix burst type.
> When more than one value, means undefined length burst mode, USB controller
> can use the length less than or equal to the largest enabled burst length.
> 
> While enabling undefined length INCR burst type and INCR16 burst type,
> get better write performance on NXP Layerscape platforms:
> around 3% improvement (from 364MB/s to 375MB/s).
> 
> Signed-off-by: Changming Huang 
> Signed-off-by: Ran Wang 
> ---
> Changes in v5:
>   - add support for ls1021a, ls1012a, ls1046a, ls1088a, ls1021a
>   - update ls208xa support according to code base change
> Changes in v4:
>   - change definition for this property.
> Changes in v3:
>   - add new property for INCR burst in usb node.
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt |6 ++
>  arch/arm/boot/dts/ls1021a.dtsi |1 +
>  arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi |1 +
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi |3 +++
>  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi |2 ++
>  arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |2 ++
>  7 files changed, 18 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index 44e8bab..d1779b2 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -59,6 +59,11 @@ Optional properties:
>   fladj_30mhz_sdbnd signal is invalid or incorrect.
>  
>   -  tx-fifo-resize: determines if the FIFO *has* to be 
> reallocated.
> + - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
> + register, undefined length INCR burst type enable and INCRx type.
> + When just one value, which means INCRX burst mode. When more than one
> + value, which means undefined length INCR burst type enabled.
> + The values can be 1, 4, 8, 16, 32, 64, 128 and 256.

I don't understand the multiple values for undefined length burst. Why 
do you need burst length if length is undefined? Looking at the driver, 
it looks like you only care about the largest value.

Rob
--
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 v5 3/3] USB3/DWC3: Enable undefined length INCR burst type

[Rob Herring]

On Tue, Mar 06, 2018 at 04:59:11PM +0800, Ran Wang wrote:
> Enable the undefined length INCR burst type and set INCRx.
> Different platform may has the different burst size type.
> In order to get best performance, we need to tune the burst size to
> one special value, instead of the default value.
> 
> Signed-off-by: Changming Huang 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: Ran Wang 
> ---
> Changes in v5:
>   - no change
> Changes in v4:
>   - Modify the codes according to the definition of this property.
> Changes in v3:
>   - add new property for INCR burst in usb node to reset GSBUSCFG0.
> Changes in v2:
>   - split patch
>   - create one new function to handle soc bus configuration register.
> 
>  drivers/usb/dwc3/core.c |   83 
> +++
>  drivers/usb/dwc3/core.h |7 
>  2 files changed, 90 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index f1d838a..8ea2bc8 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -741,6 +741,87 @@ static void dwc3_core_setup_global_control(struct dwc3 
> *dwc)
>  static int dwc3_core_get_phy(struct dwc3 *dwc);
>  static int dwc3_core_ulpi_init(struct dwc3 *dwc);
>  
> +/* set global soc bus configuration registers */
> +static void dwc3_set_soc_bus_cfg(struct dwc3 *dwc)
> +{
> + struct device *dev = dwc->dev;
> + u32 *vals;
> + u32 cfg;
> + int ntype;
> + int ret;
> + int i;
> +
> + cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
> +
> + /*
> +  * Handle property "snps,incr-burst-type-adjustment".
> +  * Get the number of value from this property:
> +  * result <= 0, means this property is not supported.
> +  * result = 1, means INCRx burst mode supported.
> +  * result > 1, means undefined length burst mode supported.
> +  */
> + ntype = device_property_read_u32_array(dev,
> + "snps,incr-burst-type-adjustment", NULL, 0);

Can't you just do:

if (ntype <= 0)
return;

> + if (ntype > 0) {

And then save a level of indentation.

> + vals = kcalloc(ntype, sizeof(u32), GFP_KERNEL);
> + if (!vals) {
> + dev_err(dev, "Error to get memory\n");
> + return;
> + }
> + /* Get INCR burst type, and parse it */
> + ret = device_property_read_u32_array(dev,
> + "snps,incr-burst-type-adjustment", vals, ntype);
> + if (ret) {
> + dev_err(dev, "Error to get property\n");
> + return;
> + }
> + *(dwc->incrx_type + 1) = vals[0];
> + if (ntype > 1) {
> + *dwc->incrx_type = 1;
> + for (i = 1; i < ntype; i++) {
> + if (vals[i] > *(dwc->incrx_type + 1))
> + *(dwc->incrx_type + 1) = vals[i];
> + }
> + } else
> + *dwc->incrx_type = 0;

This code is hard to follow. Why do you have an array to store a boolean 
(INCR burst enable) and the burst size. 2 elements with more descriptive 
names would be better.


> +
> + /* Enable Undefined Length INCR Burst and Enable INCRx Burst */
> + cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
> + if (*dwc->incrx_type)
> + cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
> + switch (*(dwc->incrx_type + 1)) {
> + case 256:
> + cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
> + break;
> + case 128:
> + cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
> + break;
> + case 64:
> + cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
> + break;
> + case 32:
> + cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
> + break;
> + case 16:
> + cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
> + break;
> + case 8:
> + cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
> + break;
> + case 4:
> + cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
> + break;
> + case 1:
> + break;
> + default:
> + dev_err(dev, "Invalid property\n");
> + break;
> + }
> + }
> +
> + dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
> +}
> +
>  /**
>   * dwc3_core_init - Low-level initialization of DWC3 Core
>   * @dwc: Pointer to our controller context structure
> @@ -803,6 +884,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
>   /* Adjust Frame Length */
>   dwc3_frame_length_adjustment(dwc);
>  
> + dwc3_set_soc_bus_cfg(dwc);
> +
>   

Re: usb: musb: error when trying to unbind musb-hdrc.0.auto

[Merlijn Wajer]

Hi,

I suspected that the issue was similar to the one fixed in this commit:
0c3aae9bd59978fb8c3557d7883380bef0f2cfa1 (USB: musb: fix late external
abort on suspend)

I've applied a similar fix to the musb_remove function (as well as
moving musb_platform_exit just before spin_unlock_irqrestore), and now I
can unbind successfully. I will try to send a patch for review soon.

Cheers,
Merlijn

On 07/03/18 23:41, Merlijn Wajer wrote:
> Hi,
> 
> I am trying to unbind the musb driver on my Nokia N900, but I get the
> following kernel oops [1].
> 
> This is the command that I issued:
> 
> root@n900devuan:/sys/bus/platform/drivers/musb-hdrc# echo
> musb-hdrc.0.auto > unbind
> 
> This might be omap specific. I thought that as with the vbus issue,
> calls to pm_runtime_{get,put}_sync were required, but it seems that
> pm_runtime_disable gets called before musb_platform_exit is called.
> 
> I've tried simply moving the call so that it is called before
> pm_runtime_disable (actually just before spin_unlock_irqrestore in
> musb_remove) but this doesn't seem to help.
> 
> Any thoughts?
> 
> Cheers,
> Merlijn
> 
> [1]
> 
> [ 7232.484985] Unhandled fault: external abort on non-linefetch (0x1028)
> at 0xfa0ab414
> [ 7232.485015] pgd = 9b0f7685
> [ 7232.485046] [fa0ab414] *pgd=48011452(bad)
> [ 7232.485076] Internal error: : 1028 [#1] PREEMPT ARM
> [ 7232.485076] Modules linked in: u_ether u_serial bluetooth
> ecdh_generic ipv6 omaplfb ctr
>  aes_arm_bs crypto_simd cryptd ccm pvrsrvkm cmt_speech nokia_modem
> ssi_protocol radio_plat
> form_si4713 mousedev arc4 joydev hsi_char wl1251_spi crc7 wl1251
> ir_lirc_codec mac80211 li
> rc_dev ir_rx51 rc_core smc91x gpio_keys rx51_battery pwm_omap_dmtimer
> isp1704_charger mii
> sha256_generic omap3_isp videobuf2_dma_contig v4l2_fwnode cfg80211
> videobuf2_memops si4713
>  videobuf2_v4l2 adp1653 videobuf2_core v4l2_common tsc2005 tsc200x_core
> videodev bq27xxx_b
> attery_i2c bq27xxx_battery bq2415x_charger leds_lp5523
> leds_lp55xx_common media tsl2563 rt
> c_twl twl4030_vibra ff_memless omap_ssi lis3lv02d_i2c lis3lv02d hsi
> input_polldev ti_soc_t
> hermal vfat fat [last unloaded: libcomposite]
> [ 7232.485412] CPU: 0 PID: 2803 Comm: bash Not tainted 4.15.6+ #1
> [ 7232.485412] Hardware name: Nokia RX-51 board
> [ 7232.485473] PC is at musb_default_readl+0x4/0xc
> [ 7232.485473] LR is at omap2430_musb_exit+0x2c/0x70
> [ 7232.485504] pc : []lr : []psr: a0020013
> [ 7232.485504] sp : cb2afe70  ip :   fp : 
> [ 7232.485534] r10:   r9 : 0051  r8 : 200f0013
> [ 7232.485534] r7 : c2a65920  r6 : ce354d10  r5 :   r4 : ce52e010
> [ 7232.485565] r3 : c05220f4  r2 :   r1 : fa0ab414  r0 : fa0ab000
> [ 7232.485595] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment none
> [ 7232.485595] Control: 10c5387d  Table: 8bfa4019  DAC: 0051
> [ 7232.485626] Process bash (pid: 2803, stack limit = 0x5105ec71)
> [ 7232.485626] Stack: (0xcb2afe70 to 0xcb2b)
> [ 7232.485656] fe60: ce52e010
> e000 ce388a10 c0521c
> dc
> [ 7232.485687] fe80: ce388a10 ce388a10 c0a325e8 ce388a44 0034
> c04c34d8 ce388a10 00
> 00
> [ 7232.485717] fea0: c0a325e8 c04c2170 0011 ce388a10 c0a325e8
> c0a2fef8 c9cde410 c04c0a
> 8c
> [ 7232.485717] fec0: 0011 cd8f7e00 c9cde400 cb2aff88 c9cde410
> c0259554  00
> 00
> [ 7232.485748] fee0: 0011 cb6b1600 c0259424  cb2aff88
> 000e4408 cb2ae000 c01eda
> 74
> [ 7232.485778] ff00: 0100  cb3b0180 c020a948 cb3b0cc0
> 000a cb3b0cc0 00
> 01
> [ 7232.485809] ff20: cb3b0cc0 000a 0001 c020aefc 0001
>  cb3b0cc0 c01fd4
> f4
> [ 7232.485839] ff40: cb6b1600 0002 cb6b1600 0011 
> cb2aff88 000e4408 c01edd30
> [ 7232.485870] ff60: cb6b1600 000e4408 0011 cb6b1600 cb6b1600
> 000e4408 0011 c0106fc4
> [ 7232.485900] ff80: cb2ae000 c01edee8   0011
> 0011 000e4408 b6eb3d60
> [ 7232.485900] ffa0: 0004 c0106de0 0011 000e4408 0001
> 000e4408 0011 
> [ 7232.485931] ffc0: 0011 000e4408 b6eb3d60 0004 000e4408
> 0011  
> [ 7232.485961] ffe0:  bedd1eec b6e161bb b6e52b46 0030
> 0001  
> [ 7232.485992] [] (musb_default_readl) from []
> (omap2430_musb_exit+0x2c/0x70)
> [ 7232.486022] [] (omap2430_musb_exit) from []
> (musb_remove+0x110/0x158)
> [ 7232.486053] [] (musb_remove) from []
> (platform_drv_remove+0x24/0x3c)
> [ 7232.486114] [] (platform_drv_remove) from []
> (device_release_driver_internal+0xd4/0x1dc)
> [ 7232.486145] [] (device_release_driver_internal) from
> [] (unbind_store+0x58/0x8c)
> [ 7232.486175] [] (unbind_store) from []
> (kernfs_fop_write+0x130/0x1a0)
> [ 7232.486206] [] (kernfs_fop_write) from []
> (__vfs_write+0x1c/0x11c)
> [ 7232.486236] [] (__vfs_write) from []
> (vfs_write+0xb8/0x18c)
> [ 7232.486267] [] (vfs_write) from []
> (SyS_write+0x3c/0x74)
> [ 7232.486297] [] (SyS_write) 

Re: High CPU load produced by USB (DW2)

[Marek Vasut]

On 03/06/2018 09:09 AM, Minas Harutyunyan wrote:

Hi,

On 3/6/2018 10:45 AM, Minas Harutyunyan wrote:

Hi,

On 3/5/2018 11:14 PM, Marek Vasut wrote:

On 02/20/2018 06:51 AM, Minas Harutyunyan wrote:
[...]

Is there a way to reduce that or is that the absolute minimum in HS mode?


We already discussed, in this email thread earlier, why SOF interrupts
required and unmasked.
Only in case when connected device with CTRL+BLK EP's only (like flash
drive) and directly connected to cores root HUB, SOF's will be masked.


That's the setup I have on Altera SoCFPGA, yet the SOFs are still present.


Could you please send verbose lsusb on connected to dwc2 device


See attached


and driver debug log.


What exactly do you mean by this one ?

Enable debugging messages and verbose debugging messages for dwc2 from
make menuconfig. Provide dmesg starting from dwc2 load till HS device
connected to dwc2 port and enumerated.

Thanks,
Minas







Driver debug log not required.
Based on lsusb output: to dwc2 port connected "Standard Microsystems
Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp.
Ultra". Because of connected HUB, which have periodic endpoint
(Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask
SOF interrupts.


I don't understand the last part, can you rephrase ?

What does that mean regarding the SOF question above ?
--
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: musb: error when trying to unbind musb-hdrc.0.auto

[Merlijn Wajer]

Hi,

I am trying to unbind the musb driver on my Nokia N900, but I get the
following kernel oops [1].

This is the command that I issued:

root@n900devuan:/sys/bus/platform/drivers/musb-hdrc# echo
musb-hdrc.0.auto > unbind

This might be omap specific. I thought that as with the vbus issue,
calls to pm_runtime_{get,put}_sync were required, but it seems that
pm_runtime_disable gets called before musb_platform_exit is called.

I've tried simply moving the call so that it is called before
pm_runtime_disable (actually just before spin_unlock_irqrestore in
musb_remove) but this doesn't seem to help.

Any thoughts?

Cheers,
Merlijn

[1]

[ 7232.484985] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfa0ab414
[ 7232.485015] pgd = 9b0f7685
[ 7232.485046] [fa0ab414] *pgd=48011452(bad)
[ 7232.485076] Internal error: : 1028 [#1] PREEMPT ARM
[ 7232.485076] Modules linked in: u_ether u_serial bluetooth
ecdh_generic ipv6 omaplfb ctr
 aes_arm_bs crypto_simd cryptd ccm pvrsrvkm cmt_speech nokia_modem
ssi_protocol radio_plat
form_si4713 mousedev arc4 joydev hsi_char wl1251_spi crc7 wl1251
ir_lirc_codec mac80211 li
rc_dev ir_rx51 rc_core smc91x gpio_keys rx51_battery pwm_omap_dmtimer
isp1704_charger mii
sha256_generic omap3_isp videobuf2_dma_contig v4l2_fwnode cfg80211
videobuf2_memops si4713
 videobuf2_v4l2 adp1653 videobuf2_core v4l2_common tsc2005 tsc200x_core
videodev bq27xxx_b
attery_i2c bq27xxx_battery bq2415x_charger leds_lp5523
leds_lp55xx_common media tsl2563 rt
c_twl twl4030_vibra ff_memless omap_ssi lis3lv02d_i2c lis3lv02d hsi
input_polldev ti_soc_t
hermal vfat fat [last unloaded: libcomposite]
[ 7232.485412] CPU: 0 PID: 2803 Comm: bash Not tainted 4.15.6+ #1
[ 7232.485412] Hardware name: Nokia RX-51 board
[ 7232.485473] PC is at musb_default_readl+0x4/0xc
[ 7232.485473] LR is at omap2430_musb_exit+0x2c/0x70
[ 7232.485504] pc : []lr : []psr: a0020013
[ 7232.485504] sp : cb2afe70  ip :   fp : 
[ 7232.485534] r10:   r9 : 0051  r8 : 200f0013
[ 7232.485534] r7 : c2a65920  r6 : ce354d10  r5 :   r4 : ce52e010
[ 7232.485565] r3 : c05220f4  r2 :   r1 : fa0ab414  r0 : fa0ab000
[ 7232.485595] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
[ 7232.485595] Control: 10c5387d  Table: 8bfa4019  DAC: 0051
[ 7232.485626] Process bash (pid: 2803, stack limit = 0x5105ec71)
[ 7232.485626] Stack: (0xcb2afe70 to 0xcb2b)
[ 7232.485656] fe60: ce52e010
e000 ce388a10 c0521c
dc
[ 7232.485687] fe80: ce388a10 ce388a10 c0a325e8 ce388a44 0034
c04c34d8 ce388a10 00
00
[ 7232.485717] fea0: c0a325e8 c04c2170 0011 ce388a10 c0a325e8
c0a2fef8 c9cde410 c04c0a
8c
[ 7232.485717] fec0: 0011 cd8f7e00 c9cde400 cb2aff88 c9cde410
c0259554  00
00
[ 7232.485748] fee0: 0011 cb6b1600 c0259424  cb2aff88
000e4408 cb2ae000 c01eda
74
[ 7232.485778] ff00: 0100  cb3b0180 c020a948 cb3b0cc0
000a cb3b0cc0 00
01
[ 7232.485809] ff20: cb3b0cc0 000a 0001 c020aefc 0001
 cb3b0cc0 c01fd4
f4
[ 7232.485839] ff40: cb6b1600 0002 cb6b1600 0011 
cb2aff88 000e4408 c01edd30
[ 7232.485870] ff60: cb6b1600 000e4408 0011 cb6b1600 cb6b1600
000e4408 0011 c0106fc4
[ 7232.485900] ff80: cb2ae000 c01edee8   0011
0011 000e4408 b6eb3d60
[ 7232.485900] ffa0: 0004 c0106de0 0011 000e4408 0001
000e4408 0011 
[ 7232.485931] ffc0: 0011 000e4408 b6eb3d60 0004 000e4408
0011  
[ 7232.485961] ffe0:  bedd1eec b6e161bb b6e52b46 0030
0001  
[ 7232.485992] [] (musb_default_readl) from []
(omap2430_musb_exit+0x2c/0x70)
[ 7232.486022] [] (omap2430_musb_exit) from []
(musb_remove+0x110/0x158)
[ 7232.486053] [] (musb_remove) from []
(platform_drv_remove+0x24/0x3c)
[ 7232.486114] [] (platform_drv_remove) from []
(device_release_driver_internal+0xd4/0x1dc)
[ 7232.486145] [] (device_release_driver_internal) from
[] (unbind_store+0x58/0x8c)
[ 7232.486175] [] (unbind_store) from []
(kernfs_fop_write+0x130/0x1a0)
[ 7232.486206] [] (kernfs_fop_write) from []
(__vfs_write+0x1c/0x11c)
[ 7232.486236] [] (__vfs_write) from []
(vfs_write+0xb8/0x18c)
[ 7232.486267] [] (vfs_write) from []
(SyS_write+0x3c/0x74)
[ 7232.486297] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x54)
[ 7232.486328] Code: e0801001 e5812000 e12fff1e e0801001 (e591)
[ 7232.486328] ---[ end trace 1dd18c3e3b5270ba ]---
[ 7232.497070] In-band Error seen by MPU  at address 0
[ 7232.497100] [ cut here ]
[ 7232.497161] WARNING: CPU: 0 PID: 2803 at
drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xcc/0x114
[ 7232.497161] Modules linked in: u_ether u_serial bluetooth
ecdh_generic ipv6 omaplfb ctr aes_arm_bs crypto_simd cryptd ccm pvrsrvkm
cmt_speech nokia_modem ssi_protocol radio_platform_si4713 mousedev arc4
joydev hsi_char wl1251_spi crc7 wl1251 ir_lirc_codec mac80211 lirc_dev
ir_rx51 rc_core 

Re: [PATCH v1 1/1] USB: serial: Add boundry check for read_urbs array access

[sathyanarayanan kuppuswamy]

On 03/07/2018 12:58 PM, Greg KH wrote:

On Wed, Mar 07, 2018 at 12:23:56PM -0800, 
sathyanarayanan.kuppusw...@linux.intel.com wrote:

From: Kuppuswamy Sathyanarayanan 

In usb_serial_generic_submit_read_urb() function we are accessing the
port->read_urbs array without any boundry checks. This might lead to
kernel panic when index value goes above array length.

One posible call path for this issue is,

usb_serial_generic_read_bulk_callback()
{
  ...
  if (!port->throttled) {
usb_serial_generic_submit_read_urb(port, i, GFP_ATOMIC);
  ...
}

How does i ever get to be greater than the array size here in this
function?  It directly came from looking in that array in the first
place :)

So I don't see why your check is needed, what other code path would ever
call this function in a way that the bounds check would be needed?

void usb_serial_generic_read_bulk_callback(struct urb *urb)

385 for (i = 0; i < ARRAY_SIZE(port->read_urbs); ++i) {
386 if (urb == port->read_urbs[i])
387 break;
388 }

In here, after this for loop is done (without any matching urb), i value 
will be equal to ARRAY_SIZE(port->read_urbs). So there is a possibility 
of usb_serial_generic_submit_read_urb() getting called with this invalid 
index.




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



--
Sathyanarayanan Kuppuswamy
Linux kernel developer

--
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 v1 1/1] USB: serial: Add boundry check for read_urbs array access

[Greg KH]

On Wed, Mar 07, 2018 at 12:23:56PM -0800, 
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan 
> 
> In usb_serial_generic_submit_read_urb() function we are accessing the
> port->read_urbs array without any boundry checks. This might lead to
> kernel panic when index value goes above array length.
> 
> One posible call path for this issue is,
> 
> usb_serial_generic_read_bulk_callback()
> {
>  ...
>  if (!port->throttled) {
>   usb_serial_generic_submit_read_urb(port, i, GFP_ATOMIC);
>  ...
> }

How does i ever get to be greater than the array size here in this
function?  It directly came from looking in that array in the first
place :)

So I don't see why your check is needed, what other code path would ever
call this function in a way that the bounds check would be needed?

thanks,

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

[PATCH 2/3] usbip: usbip_host_common: Use new error codes to return request status

[Shuah Khan]

Currently ST_OK and ST_NA are the only values used to communicate
status of a request from a client. Use new error codes to clearly
indicate what failed. For example, when client sends request to
import a device that isn't export-able, send ST_DEV_BUSY to the client.

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/libsrc/usbip_host_common.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
b/tools/usb/usbip/libsrc/usbip_host_common.c
index 6ff7b601f854..dc93fadbee96 100644
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -234,14 +234,17 @@ int usbip_export_device(struct usbip_exported_device 
*edev, int sockfd)
switch (edev->status) {
case SDEV_ST_ERROR:
dbg("status SDEV_ST_ERROR");
+   ret = ST_DEV_ERR;
break;
case SDEV_ST_USED:
dbg("status SDEV_ST_USED");
+   ret = ST_DEV_BUSY;
break;
default:
dbg("status unknown: 0x%x", edev->status);
+   ret = -1;
}
-   return -1;
+   return ret;
}
 
/* only the first interface is true */
-- 
2.14.1

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

[PATCH 1/3] usbip: tools: add more error codes for usbip request/reply messages

[Shuah Khan]

Currently ST_OK and ST_NA are the only values defined to communicate
status of a request from a client. Add more error codes to clearly
indicate what failed. For example, when client sends request to import
a device that isn't export-able, server can send a specific error code
to the client.

Existing defines are moved to a common header in libsrc to be included
in the libusbip_la-usbip_common.o to be used by all the usbip tools.
Supporting interface to print error strings is added to the common lib.

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/libsrc/usbip_common.c | 23 +++
 tools/usb/usbip/libsrc/usbip_common.h | 11 +++
 tools/usb/usbip/src/usbip_network.h   |  4 +---
 3 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index 001bb8e8f668..bb424638d75b 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -66,6 +66,29 @@ const char *usbip_speed_string(int num)
return "Unknown Speed";
 }
 
+struct op_common_status_string {
+   int num;
+   char *desc;
+};
+
+static struct op_common_status_string op_common_status_strings[] = {
+   { ST_OK,"Request Completed Successfully" },
+   { ST_NA,"Request Failed" },
+   { ST_DEV_BUSY,  "Device busy (exported)" },
+   { ST_DEV_ERR,   "Device in error state" },
+   { ST_NODEV, "Device not found" },
+   { ST_ERROR, "Unexpected response" },
+   { 0, NULL}
+};
+
+const char *usbip_op_common_status_string(int status)
+{
+   for (int i = 0; op_common_status_strings[i].desc != NULL; i++)
+   if (op_common_status_strings[i].num == status)
+   return op_common_status_strings[i].desc;
+
+   return "Unknown Op Common Status";
+}
 
 #define DBG_UDEV_INTEGER(name)\
dbg("%-20s = %x", to_string(name), (int) udev->name)
diff --git a/tools/usb/usbip/libsrc/usbip_common.h 
b/tools/usb/usbip/libsrc/usbip_common.h
index e45ec9d2fdbc..73a367a7fa10 100644
--- a/tools/usb/usbip/libsrc/usbip_common.h
+++ b/tools/usb/usbip/libsrc/usbip_common.h
@@ -43,6 +43,16 @@
 #define SYSFS_PATH_MAX 256
 #define SYSFS_BUS_ID_SIZE  32
 
+/* Defines for op_code status in server/client op_common PDUs */
+#define ST_OK  0x00
+#define ST_NA  0x01
+   /* Device requested for import is not available */
+#define ST_DEV_BUSY0x02
+   /* Device requested for import is in error state */
+#define ST_DEV_ERR 0x03
+#define ST_NODEV   0x04
+#define ST_ERROR   0x05
+
 extern int usbip_use_syslog;
 extern int usbip_use_stderr;
 extern int usbip_use_debug ;
@@ -130,6 +140,7 @@ int read_usb_interface(struct usbip_usb_device *udev, int i,
 
 const char *usbip_speed_string(int num);
 const char *usbip_status_string(int32_t status);
+const char *usbip_op_common_status_string(int status);
 
 int usbip_names_init(char *);
 void usbip_names_free(void);
diff --git a/tools/usb/usbip/src/usbip_network.h 
b/tools/usb/usbip/src/usbip_network.h
index 7032687621d3..b6a2f9be888c 100644
--- a/tools/usb/usbip/src/usbip_network.h
+++ b/tools/usb/usbip/src/usbip_network.h
@@ -27,9 +27,7 @@ struct op_common {
 #define OP_REPLY   (0x00 << 8)
uint16_t code;
 
-   /* add more error code */
-#define ST_OK  0x00
-#define ST_NA  0x01
+   /* status codes defined in usbip_common.h */
uint32_t status; /* op_code status (for reply) */
 
 } __attribute__((packed));
-- 
2.14.1

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

[PATCH 3/3] usbip: tools: change to use new error codes in server reply messages

[Shuah Khan]

Changed usbip_network, usbip_attach, usbip_list, and usbipd to use
and propagate the new error codes in server reply messages.

usbip_net_recv_op_common() is changed to take a pointer to status
return the status returned in the op_common.status to callers.

usbip_attach and usbip_list use the common interface to print error
messages to indicate why the request failed.

With this change the messages say why a request failed:

- when a client requests a device that is already exported:

usbip attach -r server_name -b 3-10.2
usbip: error: Attach Request for 3-10.2 failed - Device busy (exported)

- when a client requests a device that isn't exportable,

usbip attach -r server_name -b 3-10.4
usbip: error: Attach Request for 3-10.4 failed - Device not found

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/src/usbip_attach.c  | 11 +--
 tools/usb/usbip/src/usbip_list.c|  6 --
 tools/usb/usbip/src/usbip_network.c |  6 +-
 tools/usb/usbip/src/usbip_network.h |  2 +-
 tools/usb/usbip/src/usbipd.c| 18 +-
 5 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/tools/usb/usbip/src/usbip_attach.c 
b/tools/usb/usbip/src/usbip_attach.c
index f60738735398..ba88728483ff 100644
--- a/tools/usb/usbip/src/usbip_attach.c
+++ b/tools/usb/usbip/src/usbip_attach.c
@@ -135,6 +135,7 @@ static int query_import_device(int sockfd, char *busid)
struct op_import_request request;
struct op_import_reply   reply;
uint16_t code = OP_REP_IMPORT;
+   int status;
 
memset(, 0, sizeof(request));
memset(, 0, sizeof(reply));
@@ -157,9 +158,10 @@ static int query_import_device(int sockfd, char *busid)
}
 
/* receive a reply */
-   rc = usbip_net_recv_op_common(sockfd, );
+   rc = usbip_net_recv_op_common(sockfd, , );
if (rc < 0) {
-   err("recv op_common");
+   err("Attach Request for %s failed - %s\n",
+   busid, usbip_op_common_status_string(status));
return -1;
}
 
@@ -194,11 +196,8 @@ static int attach_device(char *host, char *busid)
}
 
rhport = query_import_device(sockfd, busid);
-   if (rhport < 0) {
-   err("Attach request for Device %s. Is this device exported?",
-   busid);
+   if (rhport < 0)
return -1;
-   }
 
close(sockfd);
 
diff --git a/tools/usb/usbip/src/usbip_list.c b/tools/usb/usbip/src/usbip_list.c
index d65a9f444174..8d4ccf4b9480 100644
--- a/tools/usb/usbip/src/usbip_list.c
+++ b/tools/usb/usbip/src/usbip_list.c
@@ -62,6 +62,7 @@ static int get_exported_devices(char *host, int sockfd)
struct usbip_usb_interface uintf;
unsigned int i;
int rc, j;
+   int status;
 
rc = usbip_net_send_op_common(sockfd, OP_REQ_DEVLIST, 0);
if (rc < 0) {
@@ -69,9 +70,10 @@ static int get_exported_devices(char *host, int sockfd)
return -1;
}
 
-   rc = usbip_net_recv_op_common(sockfd, );
+   rc = usbip_net_recv_op_common(sockfd, , );
if (rc < 0) {
-   dbg("usbip_net_recv_op_common failed");
+   err("Exported Device List Request failed - %s\n",
+   usbip_op_common_status_string(status));
return -1;
}
 
diff --git a/tools/usb/usbip/src/usbip_network.c 
b/tools/usb/usbip/src/usbip_network.c
index 90325fa8bc38..8ffcd47d9638 100644
--- a/tools/usb/usbip/src/usbip_network.c
+++ b/tools/usb/usbip/src/usbip_network.c
@@ -163,7 +163,7 @@ int usbip_net_send_op_common(int sockfd, uint32_t code, 
uint32_t status)
return 0;
 }
 
-int usbip_net_recv_op_common(int sockfd, uint16_t *code)
+int usbip_net_recv_op_common(int sockfd, uint16_t *code, int *status)
 {
struct op_common op_common;
int rc;
@@ -191,10 +191,14 @@ int usbip_net_recv_op_common(int sockfd, uint16_t *code)
if (op_common.code != *code) {
dbg("unexpected pdu %#0x for %#0x", op_common.code,
*code);
+   /* return error status */
+   *status = ST_ERROR;
goto err;
}
}
 
+   *status = op_common.status;
+
if (op_common.status != ST_OK) {
dbg("request failed at peer: %d", op_common.status);
goto err;
diff --git a/tools/usb/usbip/src/usbip_network.h 
b/tools/usb/usbip/src/usbip_network.h
index b6a2f9be888c..555215eae43e 100644
--- a/tools/usb/usbip/src/usbip_network.h
+++ b/tools/usb/usbip/src/usbip_network.h
@@ -174,7 +174,7 @@ void usbip_net_pack_usb_interface(int pack, struct 
usbip_usb_interface *uinf);
 ssize_t usbip_net_recv(int sockfd, void *buff, size_t bufflen);
 ssize_t usbip_net_send(int sockfd, void *buff, size_t bufflen);
 int usbip_net_send_op_common(int sockfd, uint32_t code, uint32_t status);
-int usbip_net_recv_op_common(int 

[PATCH 0/3] More error codes for usbip request/reply messages

[Shuah Khan]

Currently ST_OK and ST_NA are the only values defined to communicate
status of a request from a client. Client doesn't know what failed
and prints a cryptic error message that something failed.

This patch series adds more error codes to clearly indicate what failed.
For example, when client sends request to import a device that isn't
export-able, server can send a specific error code to the client.

The first patch moves existing error codes to a common library header
and adds more codes. It also adds an interface to map the code to a
string to print messages from tools.

The second patch changes the server/host to return the right codes
in reply messages when client request fails.

The third patch changes the clinet tools to recognize the new error
codes and print messages.

With this change the messages say why a request failed:

- when a client requests a device that is already exported:

usbip attach -r server_name -b 3-10.2
usbip: error: Attach Request for 3-10.2 failed - Device busy (exported)

- when a client requests a device that isn't exportable,

usbip attach -r server_name -b 3-10.4
usbip: error: Attach Request for 3-10.4 failed - Device not found

Shuah Khan (3):
  usbip: tools: add more error codes for usbip request/reply messages
  usbip: usbip_host_common: Use new error codes to return request status
  usbip: tools: change to use new error codes in server reply messages

 tools/usb/usbip/libsrc/usbip_common.c  | 23 +++
 tools/usb/usbip/libsrc/usbip_common.h  | 11 +++
 tools/usb/usbip/libsrc/usbip_host_common.c |  5 -
 tools/usb/usbip/src/usbip_attach.c | 11 +--
 tools/usb/usbip/src/usbip_list.c   |  6 --
 tools/usb/usbip/src/usbip_network.c|  6 +-
 tools/usb/usbip/src/usbip_network.h|  6 ++
 tools/usb/usbip/src/usbipd.c   | 18 +-
 8 files changed, 63 insertions(+), 23 deletions(-)

-- 
2.14.1

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

Re: [PATCH net-next 1/2] net: kalmia: clean up bind error path

[David Miller]

From: Johan Hovold 
Date: Wed,  7 Mar 2018 10:46:57 +0100

> Drop bogus call to usb_driver_release_interface() from an error path in
> the usbnet bind() callback, which is called during interface probe. At
> this point the interface is not bound and usb_driver_release_interface()
> returns early.
> 
> Also remove the bogus call to clear the interface data, which is owned
> by the usbnet driver and would not even have been set by the time bind()
> is called.
> 
> Signed-off-by: Johan Hovold 

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

Re: [PATCH net-next 2/2] net: cdc_eem: clean up bind error path

[David Miller]

From: Johan Hovold 
Date: Wed,  7 Mar 2018 10:46:58 +0100

> Drop bogus call to usb_driver_release_interface() from an error path in
> the usbnet bind() callback, which is called during interface probe. At
> this point the interface is not bound and usb_driver_release_interface()
> returns early.
> 
> Also remove the bogus call to clear the interface data, which is owned
> by the usbnet driver and would not even have been set by the time bind()
> is called.
> 
> Signed-off-by: Johan Hovold 

Applied.
--
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 v1 1/1] USB: serial: Add boundry check for read_urbs array access

[sathyanarayanan . kuppuswamy]

From: Kuppuswamy Sathyanarayanan 

In usb_serial_generic_submit_read_urb() function we are accessing the
port->read_urbs array without any boundry checks. This might lead to
kernel panic when index value goes above array length.

One posible call path for this issue is,

usb_serial_generic_read_bulk_callback()
{
 ...
 if (!port->throttled) {
usb_serial_generic_submit_read_urb(port, i, GFP_ATOMIC);
 ...
}

This patch fixes this issue.

Signed-off-by: Kuppuswamy Sathyanarayanan 

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

diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 2274d96..72ebdde 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -306,6 +306,9 @@ static int usb_serial_generic_submit_read_urb(struct 
usb_serial_port *port,
 {
int res;
 
+   if (index >= ARRAY_SIZE(port->read_urbs))
+   return -EINVAL;
+
if (!test_and_clear_bit(index, >read_urbs_free))
return 0;
 
-- 
2.7.4

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

Re: [PATCH] USB: serial: option: reimplement interface masking

[Greg Kroah-Hartman]

On Wed, Mar 07, 2018 at 05:40:48PM +0100, Johan Hovold wrote:
> Reimplement interface masking using device flags stored directly in the
> device-id table. This will make it easier to add and maintain device-id
> entries by using a more compact and readable notation compared to the
> current implementation (which manages pairs of masks in separate
> blacklist structs).
> 
> Two convenience macros are used to flag an interface as either reserved
> or as not supporting modem-control requests:
> 
>   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
> .driver_info = NCTRL(0) | RSVD(3) },
> 
> For now, we limit the highest maskable interface number to seven, which
> allows for (up to 16) additional device flags to be added later should
> need arise.
> 
> Note that this will likely need to be backported to stable in order to
> make future device-id backports more manageable.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
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] usb: isp1760: Use kasprintf

[Kees Cook]

On Wed, Mar 7, 2018 at 10:38 AM, Himanshu Jha
 wrote:
> Use kasprintf instead of combination of kmalloc and sprintf and
> therefore avoid unnecessary computation of string length.
> Also, remove the useless local variable.
>
> Signed-off-by: Himanshu Jha 

Reviewed-by: Kees Cook 

-Kees

> ---
>  drivers/usb/isp1760/isp1760-udc.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> v2:
>-removed the useless local variable devname.
>
> diff --git a/drivers/usb/isp1760/isp1760-udc.c 
> b/drivers/usb/isp1760/isp1760-udc.c
> index bac4ef5..1714b22 100644
> --- a/drivers/usb/isp1760/isp1760-udc.c
> +++ b/drivers/usb/isp1760/isp1760-udc.c
> @@ -1441,7 +1441,6 @@ int isp1760_udc_register(struct isp1760_device *isp, 
> int irq,
>  unsigned long irqflags)
>  {
> struct isp1760_udc *udc = >udc;
> -   const char *devname;
> int ret;
>
> udc->irq = -1;
> @@ -1455,13 +1454,10 @@ int isp1760_udc_register(struct isp1760_device *isp, 
> int irq,
> if (ret < 0)
> return ret;
>
> -   devname = dev_name(isp->dev);
> -   udc->irqname = kmalloc(strlen(devname) + 7, GFP_KERNEL);
> +   udc->irqname = kasprintf(GFP_KERNEL, "%s (udc)", dev_name(isp->dev));
> if (!udc->irqname)
> return -ENOMEM;
>
> -   sprintf(udc->irqname, "%s (udc)", devname);
> -
> ret = request_irq(irq, isp1760_udc_irq, IRQF_SHARED | irqflags,
>   udc->irqname, udc);
> if (ret < 0)
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security
--
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: isp1760: Use kasprintf

[Himanshu Jha]

Use kasprintf instead of combination of kmalloc and sprintf and
therefore avoid unnecessary computation of string length.
Also, remove the useless local variable.

Signed-off-by: Himanshu Jha 
---
 drivers/usb/isp1760/isp1760-udc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

v2:
   -removed the useless local variable devname.

diff --git a/drivers/usb/isp1760/isp1760-udc.c 
b/drivers/usb/isp1760/isp1760-udc.c
index bac4ef5..1714b22 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -1441,7 +1441,6 @@ int isp1760_udc_register(struct isp1760_device *isp, int 
irq,
 unsigned long irqflags)
 {
struct isp1760_udc *udc = >udc;
-   const char *devname;
int ret;
 
udc->irq = -1;
@@ -1455,13 +1454,10 @@ int isp1760_udc_register(struct isp1760_device *isp, 
int irq,
if (ret < 0)
return ret;
 
-   devname = dev_name(isp->dev);
-   udc->irqname = kmalloc(strlen(devname) + 7, GFP_KERNEL);
+   udc->irqname = kasprintf(GFP_KERNEL, "%s (udc)", dev_name(isp->dev));
if (!udc->irqname)
return -ENOMEM;
 
-   sprintf(udc->irqname, "%s (udc)", devname);
-
ret = request_irq(irq, isp1760_udc_irq, IRQF_SHARED | irqflags,
  udc->irqname, udc);
if (ret < 0)
-- 
2.7.4

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

Re: [PATCH] usb: isp1760: Use kasprintf

[Himanshu Jha]

On Wed, Mar 07, 2018 at 08:20:54PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 7, 2018 at 8:08 PM, Himanshu Jha
>  wrote:
> > Use kasprintf instead of combination of kmalloc and sprintf and
> > therefore avoid unnecessary computation of string length.
> 
> > devname = dev_name(isp->dev);
> 
> Do you still need this temporary variable?

No.

> > -   udc->irqname = kmalloc(strlen(devname) + 7, GFP_KERNEL);
> > +   udc->irqname = kasprintf(GFP_KERNEL, "%s (udc)", devname);
> 
> Perhaps
> 
> devname -> dev_name(isp->dev)
> 
> ?

Oh, yes!
Thanks for pointing that out.
I will send v2 with the update!

-- 
Thanks
Himanshu Jha
--
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: isp1760: Use kasprintf

[Andy Shevchenko]

On Wed, Mar 7, 2018 at 8:08 PM, Himanshu Jha
 wrote:
> Use kasprintf instead of combination of kmalloc and sprintf and
> therefore avoid unnecessary computation of string length.

> devname = dev_name(isp->dev);

Do you still need this temporary variable?

> -   udc->irqname = kmalloc(strlen(devname) + 7, GFP_KERNEL);
> +   udc->irqname = kasprintf(GFP_KERNEL, "%s (udc)", devname);

Perhaps

devname -> dev_name(isp->dev)

?


-- 
With Best Regards,
Andy Shevchenko
--
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: isp1760: Use kasprintf

[Himanshu Jha]

Use kasprintf instead of combination of kmalloc and sprintf and
therefore avoid unnecessary computation of string length.

Signed-off-by: Himanshu Jha 
---
 drivers/usb/isp1760/isp1760-udc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/isp1760/isp1760-udc.c 
b/drivers/usb/isp1760/isp1760-udc.c
index bac4ef5..c35b153 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -1456,12 +1456,10 @@ int isp1760_udc_register(struct isp1760_device *isp, 
int irq,
return ret;
 
devname = dev_name(isp->dev);
-   udc->irqname = kmalloc(strlen(devname) + 7, GFP_KERNEL);
+   udc->irqname = kasprintf(GFP_KERNEL, "%s (udc)", devname);
if (!udc->irqname)
return -ENOMEM;
 
-   sprintf(udc->irqname, "%s (udc)", devname);
-
ret = request_irq(irq, isp1760_udc_irq, IRQF_SHARED | irqflags,
  udc->irqname, udc);
if (ret < 0)
-- 
2.7.4

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

Re: [PATCH net] net: usbnet: fix potential deadlock on 32bit hosts

[David Miller]

From: Eric Dumazet 
Date: Mon, 05 Mar 2018 11:41:13 -0800

> From: Eric Dumazet 
> 
> Marek reported a LOCKDEP issue occurring on 32bit host,
> that we tracked down to the fact that usbnet could either
> run from soft or hard irqs.
> 
> This patch adds u64_stats_update_begin_irqsave() and
> u64_stats_update_end_irqrestore() helpers to solve this case.
 ...
> Fixes: c8b5d129ee29 ("net: usbnet: support 64bit stats")
> Signed-off-by: Eric Dumazet 
> Reported-by: Marek Szyprowski 
> Cc: Greg Ungerer 

Applied and queued up for -stable, thanks Eric.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: serial: option: reimplement interface masking

[Johan Hovold]

Reimplement interface masking using device flags stored directly in the
device-id table. This will make it easier to add and maintain device-id
entries by using a more compact and readable notation compared to the
current implementation (which manages pairs of masks in separate
blacklist structs).

Two convenience macros are used to flag an interface as either reserved
or as not supporting modem-control requests:

{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
  .driver_info = NCTRL(0) | RSVD(3) },

For now, we limit the highest maskable interface number to seven, which
allows for (up to 16) additional device flags to be added later should
need arise.

Note that this will likely need to be backported to stable in order to
make future device-id backports more manageable.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/option.c | 446 +++-
 1 file changed, 152 insertions(+), 294 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 2d8d9150da0c..b331baec3a0b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -548,151 +548,15 @@ static void option_instat_callback(struct urb *urb);
 #define WETELECOM_PRODUCT_6802 0x6802
 #define WETELECOM_PRODUCT_WMD300   0x6803
 
-struct option_blacklist_info {
-   /* bitmask of interface numbers blacklisted for send_setup */
-   const unsigned long sendsetup;
-   /* bitmask of interface numbers that are reserved */
-   const unsigned long reserved;
-};
 
-static const struct option_blacklist_info four_g_w14_blacklist = {
-   .sendsetup = BIT(0) | BIT(1),
-};
+/* Device flags */
 
-static const struct option_blacklist_info four_g_w100_blacklist = {
-   .sendsetup = BIT(1) | BIT(2),
-   .reserved = BIT(3),
-};
+/* Interface does not support modem-control requests */
+#define NCTRL(ifnum)   ((BIT(ifnum) & 0xff) << 8)
 
-static const struct option_blacklist_info alcatel_x200_blacklist = {
-   .sendsetup = BIT(0) | BIT(1),
-   .reserved = BIT(4),
-};
+/* Interface is reserved */
+#define RSVD(ifnum)((BIT(ifnum) & 0xff) << 0)
 
-static const struct option_blacklist_info zte_0037_blacklist = {
-   .sendsetup = BIT(0) | BIT(1),
-};
-
-static const struct option_blacklist_info zte_k3765_z_blacklist = {
-   .sendsetup = BIT(0) | BIT(1) | BIT(2),
-   .reserved = BIT(4),
-};
-
-static const struct option_blacklist_info zte_ad3812_z_blacklist = {
-   .sendsetup = BIT(0) | BIT(1) | BIT(2),
-};
-
-static const struct option_blacklist_info zte_mc2718_z_blacklist = {
-   .sendsetup = BIT(1) | BIT(2) | BIT(3) | BIT(4),
-};
-
-static const struct option_blacklist_info zte_mc2716_z_blacklist = {
-   .sendsetup = BIT(1) | BIT(2) | BIT(3),
-};
-
-static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
-   .reserved = BIT(2) | BIT(3) | BIT(4),
-};
-
-static const struct option_blacklist_info zte_me3620_xl_blacklist = {
-   .reserved = BIT(3) | BIT(4) | BIT(5),
-};
-
-static const struct option_blacklist_info zte_zm8620_x_blacklist = {
-   .reserved = BIT(3) | BIT(4) | BIT(5),
-};
-
-static const struct option_blacklist_info huawei_cdc12_blacklist = {
-   .reserved = BIT(1) | BIT(2),
-};
-
-static const struct option_blacklist_info net_intf0_blacklist = {
-   .reserved = BIT(0),
-};
-
-static const struct option_blacklist_info net_intf1_blacklist = {
-   .reserved = BIT(1),
-};
-
-static const struct option_blacklist_info net_intf2_blacklist = {
-   .reserved = BIT(2),
-};
-
-static const struct option_blacklist_info net_intf3_blacklist = {
-   .reserved = BIT(3),
-};
-
-static const struct option_blacklist_info net_intf4_blacklist = {
-   .reserved = BIT(4),
-};
-
-static const struct option_blacklist_info net_intf5_blacklist = {
-   .reserved = BIT(5),
-};
-
-static const struct option_blacklist_info net_intf6_blacklist = {
-   .reserved = BIT(6),
-};
-
-static const struct option_blacklist_info zte_mf626_blacklist = {
-   .sendsetup = BIT(0) | BIT(1),
-   .reserved = BIT(4),
-};
-
-static const struct option_blacklist_info zte_1255_blacklist = {
-   .reserved = BIT(3) | BIT(4),
-};
-
-static const struct option_blacklist_info simcom_sim7100e_blacklist = {
-   .reserved = BIT(5) | BIT(6),
-};
-
-static const struct option_blacklist_info telit_me910_blacklist = {
-   .sendsetup = BIT(0),
-   .reserved = BIT(1) | BIT(3),
-};
-
-static const struct option_blacklist_info telit_me910_dual_modem_blacklist = {
-   .sendsetup = BIT(0),
-   .reserved = BIT(3),
-};
-
-static const struct option_blacklist_info telit_le910_blacklist = {
-   .sendsetup = BIT(0),
-   .reserved = BIT(1) | BIT(2),
-};
-
-static const struct option_blacklist_info telit_le920_blacklist = {
-   .sendsetup = BIT(0),
-   .reserved = BIT(1) | BIT(5),
-};
-
-static const struct 

Re: [Regression] xhci: some hard drives cannot be seen using a JMicron JMS56x enclosure

[Mathias Nyman]

On 06.03.2018 04:24, Cyril Roelandt wrote:

Hi,

On 02/28/18 15:55, Mathias Nyman wrote:


I have a series of even more custom debugging patches.
attached patches apply on 4.13, but seris for both 4.13 and 4.15 can be found 
in the
streams-debug-4.13 and streams-debug-4.15 branches at

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git

Can I ask you to do take logs with these?
no need for the previous diff, it's included


I applied your three patches on top of v4.13 and got the followings logs:

dmesg:


...
151.747272: xhci_get_hw_deq: ep_index 6 stream_id 1 deq 0001bd377133
...
151.747288: xhci_queue_trb: CMD: Set TR Dequeue Pointer Command: deq 
0001bd377143 stream 1 slot 2 ep 7 flags C
...
151.747351: xhci_get_hw_deq: ep_index 6 stream_id 2 deq 0001bd377143




I hope this helps,
Cyril Roelandt.



Thanks, It does
To me it looks like there is a issue with setting the dequeue pointer of a 
stream if
another stream was active while the endpoint stopped.

Basically if we want to cancel a URB on Stream 1, meaning stop entire endpoint 
with all its streams,
and then move stream 1 dequeue pointer forward, we end up setting the dequeue 
pointer of stream 2
as well. Probably because stream 2 was the active stream when the endpoint was 
stopped.

I can try to write a workaround that sets dequeue pointers for both the stream 
we want, and
the current active stream for each URB canceling.

Thanks
Mathias  
--

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] [media] cpia2_usb: drop bogus interface-release call

[Greg KH]

On Wed, Mar 07, 2018 at 10:49:36AM +0100, Johan Hovold wrote:
> Drop bogus call to usb_driver_release_interface() from the disconnect()
> callback. As the interface is already being unbound at this point,
> usb_driver_release_interface() simply returns early.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
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

[PATCHv3] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.

The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
device it seems. We know this as we get L3 errors from omap-usb-host if
trying to use the PHY before MDM6600 is configured.

The GPIOs controlling MDM6600 are used to power device on and off, to
configure the USB start-up mode (normal mode versus USB flashing), and
they also tell the state of the MDM6600 device.

The two start-up mode GPIOs are dual-purposed and used for out of band
(OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
the USB start-up mode first to get MDM6600 booted in the right mode to
be usable in the first place.

Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
driver for modems. But it really does not control the radio at all, it
just controls the modem power and start-up mode for USB. So I came to
the conclusion that we're better off having this done in the USB PHY
driver. For adding support for USB flashing mode, we can later on add
a kernel module option for flash_mode=1 or something similar.

Also note that currently there is no PM runtime support for the OHCI
on omap variant SoCs. So for low(er) power idle states, currenty both
ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.

For reference here is what I measured for total power consumption on
an idle Droid 4 with and without USB related MDM6600 modules:

idle lcd offphy-mapphone-mdm6600ohci-platform
153mW   284mW   344mW

So it seems that MDM6600 is currently not yet idling even with it's
radio turned off, but that's something that is beyond the control of
this USB PHY driver. This patch does get us to the point where modem
data and GPS are usable with libqmi and ModemManager for example.
Voice calls need more audio driver work.

Cc: devicet...@vger.kernel.org
Cc: Mark Rutland 
Cc: Marcel Partap 
Cc: Michael Scott 
Cc: Rob Herring 
Reviewed-by: Rob Herring 
Signed-off-by: Tony Lindgren 
---

Changes since v2:
- Dropped OTG as suggested by Kishon
- Added Rob's Reviewed-by

Changes since v1:
- Fixed up issues noticed by Rob and Sebastian
- Implemented wake irq handler (for debug use only for now)
- Improved error handling based on more testing

---
 .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
 drivers/phy/motorola/Kconfig   |   9 +
 drivers/phy/motorola/Makefile  |   1 +
 drivers/phy/motorola/phy-mapphone-mdm6600.c| 549 +
 4 files changed, 589 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
 create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c

diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
@@ -0,0 +1,30 @@
+Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
+
+Required properties:
+- compatible   Must be "motorola,mapphone-mdm6600"
+- enable-gpios GPIO to enable the USB PHY
+- power-gpios  GPIO to power on the device
+- reset-gpios  GPIO to reset the device
+- motorola,mode-gpios  Two GPIOs to configure MDM6600 USB start-up mode for
+   normal mode versus USB flashing mode
+- motorola,cmd-gpios   Three GPIOs to control the power state of the MDM6600
+- motorola,status-gpiosThree GPIOs to read the power state of the 
MDM6600
+
+Example:
+
+usb-phy {
+   compatible = "motorola,mapphone-mdm6600";
+   enable-gpios = < 31 GPIO_ACTIVE_LOW>;
+   power-gpios = < 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
+   motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
+ < 21 GPIO_ACTIVE_HIGH>;
+   motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
+< 8 GPIO_ACTIVE_HIGH>,
+< 14 GPIO_ACTIVE_HIGH>;
+   motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
+   < 21 GPIO_ACTIVE_HIGH>,
+   < 23 GPIO_ACTIVE_HIGH>;
+   #phy-cells = <0>;
+};
+
diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
--- a/drivers/phy/motorola/Kconfig
+++ b/drivers/phy/motorola/Kconfig
@@ -10,3 +10,12 @@ config PHY_CPCAP_USB
help
  Enable this for USB to work on Motorola phones and tablets
  such as Droid 4.
+
+config PHY_MAPPHONE_MDM6600
+   tristate "Motorola Mapphone MDM6600 modem USB PHY driver"
+   depends on OF && USB_SUPPORT

Re: [PATCH 2/2] USB: serial: option: use mass-storage class define

[Greg KH]

On Wed, Mar 07, 2018 at 11:49:56AM +0100, Johan Hovold wrote:
> Use the USB class define rather than a magic number when refusing to
> bind to mass-storage interfaces.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
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] USB: serial: option: drop redundant interface-class test

[Greg KH]

On Wed, Mar 07, 2018 at 11:49:55AM +0100, Johan Hovold wrote:
> Drop redundant interface-class test for Samsung GT-B3730 modems for
> which we only match and probe the CDC data interface.
> 
> Signed-off-by: Johan Hovold 

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

Re: [PATCH net-next 2/2] net: cdc_eem: clean up bind error path

[Greg KH]

On Wed, Mar 07, 2018 at 10:46:58AM +0100, Johan Hovold wrote:
> Drop bogus call to usb_driver_release_interface() from an error path in
> the usbnet bind() callback, which is called during interface probe. At
> this point the interface is not bound and usb_driver_release_interface()
> returns early.
> 
> Also remove the bogus call to clear the interface data, which is owned
> by the usbnet driver and would not even have been set by the time bind()
> is called.
> 
> Signed-off-by: Johan Hovold 

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

Re: [PATCH net-next 1/2] net: kalmia: clean up bind error path

[Greg KH]

On Wed, Mar 07, 2018 at 10:46:57AM +0100, Johan Hovold wrote:
> Drop bogus call to usb_driver_release_interface() from an error path in
> the usbnet bind() callback, which is called during interface probe. At
> this point the interface is not bound and usb_driver_release_interface()
> returns early.
> 
> Also remove the bogus call to clear the interface data, which is owned
> by the usbnet driver and would not even have been set by the time bind()
> is called.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
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-next v2 0/3] DWC3 support for Amlogic Meson AXG and GXL SoCs

[Neil Armstrong]

On 11/02/2018 22:15, Martin Blumenstingl wrote:
> Amlogic Meson AXG and GXL SoCs can use the dwc3-of-simple with little
> modifications. These SoCs use:
> - a gate clock for the USB components (DWC3, USB PHYs)
> - a reset line which is shared across all USB components (DWC3, USB2 and
>   USB3 PHYs, OTG detection logic inside the USB3 PHY registers)
> - a reset pulse to trigger the reset
> - depending on the SoC two or more PHYs (AXG: 1x USB2 and 1x USB3 PHY,
>   GXL: 2x USB2 and 1x USB3 PHY)
> 
> This extends the dwc3-of-simple so it supports (depending on the
> platform) shared and level resets. Additionally it adds new bindings
> for the Amlogic Meson AXG and GXL SoCs, along with the documentation
> (dt-bindings).
> 
> NOTE: for full support on Amlogic Meson GXL SoCs my other series called
> "initialize (multiple) PHYs for a HCD" (see [0] for v8 of that series)
> is required. However, there is no direct dependency on that series.
> Especially since Meson AXG doesn't need it (since it only has one USB2
> and one USB3 PHY, which is already supported by the current dwc3 driver,
> unlike the 2x USB2 and 1x USB3 PHYs on Meson GXL).
> So I believe that this series can still be merged, even if the other
> patchset is not ready yet.
> 
> 
> changes since v1 at [1]:
> - use of_device_is_compatible() instead of struct dwc3_of_simple_params
>   as requested by Felipe Balbi (affects PATCH #2 and #3)
> - added Rob's Acked-by to the dt-bindings patch
> - added Yixun Lan's Tested-by to the whole series as he tested this
>   successfully (along with other patches) on the Amlogic Meson AXG SoC
> 
> 
> [0] 
> http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006274.html
> [1] 
> http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006286.html
> 
> Martin Blumenstingl (3):
>   dt-bindings: usb: add support for dwc3 controller on Amlogic Meson GX
>   usb: dwc3: of-simple: add support for shared and pulsed reset lines
>   usb: dwc3: of-simple: add support for the Amlogic Meson GXL and AXG
> SoCs
> 
>  .../devicetree/bindings/usb/amlogic,dwc3.txt   | 42 
> ++
>  drivers/usb/dwc3/dwc3-of-simple.c  | 31 
>  2 files changed, 67 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/amlogic,dwc3.txt
> 

Hi Martin,

Successfully tested on Amlogic Q200 Reference Design board with a Meson GXM 
S912 SoC.

Other patchsets included :
- improvements and fixes for the phy-meson-gxl-usb2 driver 
https://lkml.kernel.org/r/20180128202245.25021-1-martin.blumensti...@googlemail.com
- initialize (multiple) PHYs for a HCD V11 
https://lkml.kernel.org/r/20180303214309.25643-1-martin.blumensti...@googlemail.com
- Meson GXL USB3 PHY driver V4 
https://lkml.kernel.org/r/20180303184700.21480-1-martin.blumensti...@googlemail.com

Tested-by: Neil Armstrong 

Thanks,
Neil
--
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-next PATCH v11 0/8] initialize (multiple) PHYs for a HCD

[Neil Armstrong]

On 03/03/2018 22:43, Martin Blumenstingl wrote:
> The goal of this series is to initialize multiple PHYs on a USB host
> controller, which is needed on Amlogic Meson GXL and GXM SoCs.
> - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
>   or three USB2 ports enabled on the internal root-hub. The SoCs also
>   provide separate USB2 PHYs, one per port. All USB2 PHYs (which are
>   internally "connected" to the dwc3 roothub) need to be powered on,
>   otherwise USB devices cannot be enumerated (even if just one PHY is
>   disabled and if the device is plugged into another, enabled port)
> - dwc3 already takes one USB2 and one USB3 PHY and initializes these
>   correctly
> - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
>   ohci-platform.c) do not have a limitation on the number of PHYs - they
>   support any number of USB PHYs (typically one PHY per actual port)
> 
> This series adds a new "PHY wrapper". This can be configured through
> devicetree by passing a "phys" property (with any number of PHY handles)
> to the USB controller.
> Additionally it this integrates this new PHY wrapper into hcd.c which
> automatically enables it for all USB controller drivers (tested on an
> Amlogic Meson GXL SoC which uses a dwc3 controller). Since this leaves
> some duplicate code (which now becomes obsolete!) in various drivers
> this is being cleaned up as well.
> 
> 
> Changes since v10 at [13]:
> - added Peter Chen's Acked-by to patch #2 (thank you!)
> - rebased to usb-next (134d1fd44221614 "Merge 4.16-rc3 into usb-next")
> 
> Changes since v9 at [12]:
> - changed "skip_phy_initialization" from PATCH #2 into a bitfield and
>   moved it below the "remove_phy" bitfield as suggested by Alan Stern
>   (thanks!)
> - rebased against usb-next (which is currently identical to v4.16-rc1)
> 
> Changes since v8 at [10]:
> - add new patch #2 which allows disabling "USB PHY management" in the
>   USB HCD core driver. this also affects patch #4 which now checks the
>   skip_phy_initialization flag before calling
>   usb_phy_roothub_{init,power_on} (other functions don't need to be
>   guarded since they are null-safe - see patch #3)
> - integrated my other series 'remove driver-specific "multiple PHY"
>   handling' from [11] into this one so the result of this "generic"
>   code (= removing duplicate code in various drivers) can be seen
>   directly. affects patches #5-8. (note: patch #1 "usb: mtu3: remove
>   custom USB PHY handling" from that series was dropped, because it
>   broke device mode support - Chunfeng Yun will come up with a
>   separate patch later. patch #5 "usb: chipidea: do not set the "phy"
>   field in struct usb_hcd" from that series was rewritten and is now
>   integrated into the new patch #2 from this series)
> - collected all {Reviewed,Tested,Acked}-by
> - dropped RfC prefix since this v8 was out for review for two weeks
>   and it only got Reviewed-by's and Tested-by's since then
> 
> Changes since v7 at [8]:
> - updated the description in the cover-letter
> - wrapped the only call usb_phy_roothub_power_{on,off} in
>   hcd_bus_{resume,suspend} during system-suspend (excluding it from
>   being called during runtime/auto suspend). this also fixes a problem
>   on Meson GXL which does not detect that a new device has been
>   connected if the PHYs are powered off. Thanks to Manu Gautam for
>   suggesting this! (affects patch #3)
> - after a discussion about the dt-bindings of this patch I went back to
>   simply specifying a "phys" property (without a corresponding phy-names
>   property) to pass all PHYs directly in the node of the USB controller.
>   From my understanding the root hub node was "artificial" and we should
>   describe it's properties as part of the controller, rather than
>   introducing a sub-node. see also the discussion with Arnd in [9]
>   (this affects patch #1 and #2)
> - dropped patch #4 ("dt-bindings: usb: xhci: include the roothub and a
>   device in the example") because we're back to just specifying a "phys"
>   property directly within the controller.
>   NOTE: some HCI platform drivers are using the "phys" property as well.
>   With this series phy_{init,power_on,power_off,exit} will be called
>   twice for each PHY when using a ehci-platform.c or xhci-mtk.c USB
>   controller (because the controller driver and our new, generic code
>   now manage the PHYs). the PHY framework handles this gracefully (by
>   ref-counting all operations). a follow-up series will be sent which
>   removes the custom handling from the affected drivers (so only the
>   new PHY wrapper will manage the PHYs state after that follow-up
>   series).
> - fixed an unnecessary whitespace change spotted by Alan Stern (thanks!)
>   in patch #3
> - removed all Tested-by's since we're changing code again
> 
> Changes since v6 at [6]:
> - fixed unnecessary whitespace change (noticed by Alan Stern - thanks)
> - added PATCH #4 to clarify (with an example) how I 

Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK

[Dennis Wassenberg]

Hi all,

are there any news regarding this issue?

I have a similar issue using a Lenovo ThinkPad T480s with Lenovo UltraDock 
CS18. If I undock the CS18 dock I will get the following messages (kernel 
4.14.24):

[   64.127294] usb usb4-port1: Cannot enable. Maybe the USB cable is bad?
[   64.127306] xhci_hcd :3a:00.0: Cannot set link state.
[   64.127521] usb usb4-port1: cannot disable (err = -32)
[   64.127527] usb 4-1: USB disconnect, device number 2
[   64.127532] usb 4-1.2: USB disconnect, device number 3
[   64.137118] usb 4-1.4: USB disconnect, device number 4

After redocking no usb3 devices which are connected to the dock will be 
detected any more.

Background:
The CS18 ultra dock uses the integrated xhci controller of Intel thunderbolt3. 
So there is a second xhci controller inside the system.
The port1 of the usb root hub (usb4) is physically inside the ThinkPad itself. 
That why it should always be possible to enable this hub port, even if the dock 
is not connected.
For example a lsusb after booting (without undock and redock) looks like this:

Bus 004 Device 003: ID 17ef:3070 Lenovo 
Bus 004 Device 002: ID 17ef:3070 Lenovo 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 17ef:3075 Lenovo 
Bus 003 Device 005: ID 17ef:306f Lenovo 
Bus 003 Device 003: ID 17ef:3071 Lenovo 
Bus 003 Device 002: ID 17ef:3071 Lenovo 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0bda:0316 Realtek Semiconductor Corp. 
Bus 002 Device 005: ID 0781:5588 SanDisk Corp. 
Bus 002 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 002 Device 002: ID 1058:083a Western Digital Technologies, Inc. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 011: ID 06cb:009a Synaptics, Inc. 
Bus 001 Device 010: ID 5986:2113 Acer, Inc 
Bus 001 Device 009: ID 8087:0a2b Intel Corp. 
Bus 001 Device 007: ID 2cb7:0210  
Bus 001 Device 005: ID 17ef:3074 Lenovo 
Bus 001 Device 003: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader
Bus 001 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

There are 2 USB Hubs inside the dock connected to the usb 3 root hub (usb4).
After undock and redock there is only the root hub available at the bus 4 (all 
other devices connected to bus 4 are gone even the 2 hubs).

I made some debugging and found that

[   64.127294] usb usb4-port1: Cannot enable. Maybe the USB cable is bad?

is because the rh port enable failed with EBUSY in hub.c hub_port_wait_reset.

I increased the HUB_RESET_TIMEOUT from 800ms to 1600ms and it seems to work 
fine. I didn't get this message again and after redock the usb3 devices are 
available.

But doing this more often (undock/redock) the hub enable still success but 
there are anyhow no usb3 devices available at the dock.

A bit more debugging shows that after redock there is a usb4 port status change 
event missing at the xhci controller (xhci-ring.c handle_port_status).


Working case:
[  127.632374] xhci_hcd :3c:00.0: Port Status Change Event for port 1
[  127.632384] xhci_hcd :3c:00.0: handle_port_status: starting port polling.
[  127.632434] hub 3-0:1.0: state 7 ports 2 chg  evt 0002
[  127.632447] xhci_hcd :3c:00.0: get port status, actual port 0 status  = 
0x206e1
[  127.632451] xhci_hcd :3c:00.0: Get port status returned 0x10101
[  127.632478] xhci_hcd :3c:00.0: clear port connect change, actual port 0 
status  = 0x6e1
[  127.632491] usb usb3-port1: status 0101, change 0001, 12 Mb/s
[  127.632499] xhci_hcd :3c:00.0: get port status, actual port 0 status  = 
0x6e1
[  127.632502] xhci_hcd :3c:00.0: Get port status returned 0x101
[  127.652047] xhci_hcd :3c:00.0: Port Status Change Event for port 3
[  127.652049] xhci_hcd :3c:00.0: handle_port_status: starting port polling.
[  127.652133] hub 4-0:1.0: state 7 ports 2 chg  evt 0002
[  127.652138] xhci_hcd :3c:00.0: get port status, actual port 0 status  = 
0x21603
[  127.652138] xhci_hcd :3c:00.0: Get port status returned 0x10203
[  127.652146] xhci_hcd :3c:00.0: clear port connect change, actual port 0 
status  = 0x1603
[  127.652149] usb usb4-port1: status 0203, change 0001, 10.0 Gb/s

Not working case:
[  160.922848] xhci_hcd :3c:00.0: Port Status Change Event for port 1
[  160.922860] xhci_hcd :3c:00.0: handle_port_status: starting port polling.
[  160.922956] hub 3-0:1.0: state 7 ports 2 chg  evt 0002
[  160.922972] xhci_hcd :3c:00.0: get port status, actual port 0 status  = 
0x206e1
[  160.922976] xhci_hcd :3c:00.0: Get port status returned 0x10101
[  160.923025] xhci_hcd :3c:00.0: clear port connect change, actual port 0 
status  = 0x6e1
[  160.923046] usb usb3-port1: status 0101, change 0001, 12 Mb/s
[  160.923061] xhci_hcd :3c:00.0: get port status, actual port 0 status  = 
0x6e1
[  160.923065] xhci_hcd :3c:00.0: Get port status returned 0x101
[  160.950040] 

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 07.03.2018 12:22, Krzysztof Kozlowski wrote:
> On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda  wrote:
>> Hi Chanwoo, Archit,
>>
>> On 07.03.2018 05:48, Chanwoo Choi wrote:
>>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
 Hi Rob and Andrzej,

 On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
> Hi Rob, Chanwoo, Krzysztof,
>
>
> On 27.02.2018 08:11, Andrzej Hajda wrote:
>> Hi,
>>
>> Thanks for reviews of previous iterations.
>>
>> This patchset introduces USB physical connector bindings, together with
>> working example.
>> I have removed RFC prefix - the patchset seems to be heading
>> to a happy end :)
>>
>> v5: fixed extra parenthesis in dts, renamed extcon function.
>> v4: improved binding descriptions, added missing reg in dts.
>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>> example.
>> v2: I have addressed comments by Rob and Laurent, thanks
>>
>> Changes in datail are described in the patches.
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (5):
>>   dt-bindings: add bindings for USB physical connector
>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>   extcon: add possibility to get extcon device by OF node
>>
>> Maciej Purski (1):
>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
> It looks like all patches received R-B or acks (I forgot add Krzysztof's
> acks for dts part).
> Now I have a question how to merge them.
> The only functional dependency is between bridge and extcon, and from
> the formal PoV bindings should be merged 1st.
> I can merge it:
> 1. All patches via drm-misc tree.
> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
> samsung-soc tree.
>
> Is it OK, for all? Better ideas?
 Krzysztof picked the dts patches. I'll make the immutable branch based on 
 v4.16-rc1
 and apply them except for dts patchs. And I'll send the immutable branch 
 to Rob and Andrzej.


>>> I made the immutable branch[1] as following: If you agree, I'll send pull 
>>> request.
>>> [1] 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>>>
>>> Or you can make the immutable branch and send pull request to Rob and me.
>>>
>> It seems you took v5 instead of v6 version of extcon patch.
> I also took v5:
> https://patchwork.kernel.org/patch/10244407/
> https://patchwork.kernel.org/patch/10244431/
>
> There was no v6 in samsung-soc patchwork. Is it a problem for DTS?

No, v6 was only typo fix in comment, and only extcon patch has v6.

Regards
Andrzej

>
> BR,
> Krzysztof
>
>
>

--
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 v5 0/6] dt-bindings: add bindings for USB physical connector

[Krzysztof Kozlowski]

On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda  wrote:
> Hi Chanwoo, Archit,
>
> On 07.03.2018 05:48, Chanwoo Choi wrote:
>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>>> Hi Rob and Andrzej,
>>>
>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
 Hi Rob, Chanwoo, Krzysztof,


 On 27.02.2018 08:11, Andrzej Hajda wrote:
> Hi,
>
> Thanks for reviews of previous iterations.
>
> This patchset introduces USB physical connector bindings, together with
> working example.
> I have removed RFC prefix - the patchset seems to be heading
> to a happy end :)
>
> v5: fixed extra parenthesis in dts, renamed extcon function.
> v4: improved binding descriptions, added missing reg in dts.
> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
> example.
> v2: I have addressed comments by Rob and Laurent, thanks
>
> Changes in datail are described in the patches.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (5):
>   dt-bindings: add bindings for USB physical connector
>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>   arm64: dts: exynos: add OF graph between MHL and USB connector
>   extcon: add possibility to get extcon device by OF node
>
> Maciej Purski (1):
>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
 It looks like all patches received R-B or acks (I forgot add Krzysztof's
 acks for dts part).
 Now I have a question how to merge them.
 The only functional dependency is between bridge and extcon, and from
 the formal PoV bindings should be merged 1st.
 I can merge it:
 1. All patches via drm-misc tree.
 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
 samsung-soc tree.

 Is it OK, for all? Better ideas?
>>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>>> v4.16-rc1
>>> and apply them except for dts patchs. And I'll send the immutable branch to 
>>> Rob and Andrzej.
>>>
>>>
>> I made the immutable branch[1] as following: If you agree, I'll send pull 
>> request.
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>>
>> Or you can make the immutable branch and send pull request to Rob and me.
>>
>
> It seems you took v5 instead of v6 version of extcon patch.

I also took v5:
https://patchwork.kernel.org/patch/10244407/
https://patchwork.kernel.org/patch/10244431/

There was no v6 in samsung-soc patchwork. Is it a problem for DTS?

BR,
Krzysztof
--
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 v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Chanwoo, Archit,

On 07.03.2018 05:48, Chanwoo Choi wrote:
> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>> Hi Rob and Andrzej,
>>
>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>>> Hi Rob, Chanwoo, Krzysztof,
>>>
>>>
>>> On 27.02.2018 08:11, Andrzej Hajda wrote:
 Hi,

 Thanks for reviews of previous iterations.

 This patchset introduces USB physical connector bindings, together with
 working example.
 I have removed RFC prefix - the patchset seems to be heading
 to a happy end :)

 v5: fixed extra parenthesis in dts, renamed extcon function.
 v4: improved binding descriptions, added missing reg in dts.
 v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
 example.
 v2: I have addressed comments by Rob and Laurent, thanks 

 Changes in datail are described in the patches.

 Regards
 Andrzej


 Andrzej Hajda (5):
   dt-bindings: add bindings for USB physical connector
   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
   arm64: dts: exynos: add OF graph between MHL and USB connector
   extcon: add possibility to get extcon device by OF node

 Maciej Purski (1):
   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>>> acks for dts part).
>>> Now I have a question how to merge them.
>>> The only functional dependency is between bridge and extcon, and from
>>> the formal PoV bindings should be merged 1st.
>>> I can merge it:
>>> 1. All patches via drm-misc tree.
>>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>>> samsung-soc tree.
>>>
>>> Is it OK, for all? Better ideas?
>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>> v4.16-rc1
>> and apply them except for dts patchs. And I'll send the immutable branch to 
>> Rob and Andrzej.
>>
>>
> I made the immutable branch[1] as following: If you agree, I'll send pull 
> request.
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>
> Or you can make the immutable branch and send pull request to Rob and me.
>

It seems you took v5 instead of v6 version of extcon patch.

Beside it I am OK with your immutable branch, Archit is it OK to do it
this way in drm-misc?


Regards

Andrzej



--
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 2/2] USB: serial: option: use mass-storage class define

[Johan Hovold]

Use the USB class define rather than a magic number when refusing to
bind to mass-storage interfaces.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/option.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 96b6a5c6913d..ede0145b8ec9 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2117,7 +2117,7 @@ static int option_probe(struct usb_serial *serial,
const struct option_blacklist_info *blacklist;
 
/* Never bind to the CD-Rom emulation interface */
-   if (iface_desc->bInterfaceClass == 0x08)
+   if (iface_desc->bInterfaceClass == USB_CLASS_MASS_STORAGE)
return -ENODEV;
 
/*
-- 
2.16.2

--
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/2] USB: serial: option: drop redundant interface-class test

[Johan Hovold]

Drop redundant interface-class test for Samsung GT-B3730 modems for
which we only match and probe the CDC data interface.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/option.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 2d8d9150da0c..96b6a5c6913d 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2114,7 +2114,6 @@ static int option_probe(struct usb_serial *serial,
 {
struct usb_interface_descriptor *iface_desc =
>interface->cur_altsetting->desc;
-   struct usb_device_descriptor *dev_desc = >dev->descriptor;
const struct option_blacklist_info *blacklist;
 
/* Never bind to the CD-Rom emulation interface */
@@ -2130,14 +2129,6 @@ static int option_probe(struct usb_serial *serial,
if (blacklist && test_bit(iface_desc->bInterfaceNumber,
>reserved))
return -ENODEV;
-   /*
-* Don't bind network interface on Samsung GT-B3730, it is handled by
-* a separate module.
-*/
-   if (dev_desc->idVendor == cpu_to_le16(SAMSUNG_VENDOR_ID) &&
-   dev_desc->idProduct == cpu_to_le16(SAMSUNG_PRODUCT_GT_B3730) &&
-   iface_desc->bInterfaceClass != USB_CLASS_CDC_DATA)
-   return -ENODEV;
 
/* Store the blacklist info so we can use it during attach. */
usb_set_serial_data(serial, (void *)blacklist);
-- 
2.16.2

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

Re: [PATCH net-next 2/2] net: cdc_eem: clean up bind error path

[Oliver Neukum]

Am Mittwoch, den 07.03.2018, 10:46 +0100 schrieb Johan Hovold:
> Drop bogus call to usb_driver_release_interface() from an error path in
> the usbnet bind() callback, which is called during interface probe. At
> this point the interface is not bound and usb_driver_release_interface()
> returns early.
> 
> Also remove the bogus call to clear the interface data, which is owned
> by the usbnet driver and would not even have been set by the time bind()
> is called.
> 
> Signed-off-by: Johan Hovold 
Acked-by: Oliver Neukum 
> ---
>  drivers/net/usb/cdc_eem.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
> index f7180f8db39e..61ea4eaace5d 100644
> --- a/drivers/net/usb/cdc_eem.c
> +++ b/drivers/net/usb/cdc_eem.c
> @@ -83,11 +83,8 @@ static int eem_bind(struct usbnet *dev, struct 
> usb_interface *intf)
>   int status = 0;
>  
>   status = usbnet_get_endpoints(dev, intf);
> - if (status < 0) {
> - usb_set_intfdata(intf, NULL);
> - usb_driver_release_interface(driver_of(intf), intf);
> + if (status < 0)
>   return status;
> - }
>  
>   /* no jumbogram (16K) support for now */
>  

--
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] [media] cpia2_usb: drop bogus interface-release call

[Johan Hovold]

Drop bogus call to usb_driver_release_interface() from the disconnect()
callback. As the interface is already being unbound at this point,
usb_driver_release_interface() simply returns early.

Signed-off-by: Johan Hovold 
---
 drivers/media/usb/cpia2/cpia2_usb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/usb/cpia2/cpia2_usb.c 
b/drivers/media/usb/cpia2/cpia2_usb.c
index f3a1e5b1e57c..b51fc372ca25 100644
--- a/drivers/media/usb/cpia2/cpia2_usb.c
+++ b/drivers/media/usb/cpia2/cpia2_usb.c
@@ -910,9 +910,6 @@ static void cpia2_usb_disconnect(struct usb_interface *intf)
wake_up_interruptible(>wq_stream);
}
 
-   DBG("Releasing interface\n");
-   usb_driver_release_interface(_driver, intf);
-
LOG("CPiA2 camera disconnected.\n");
 }
 
-- 
2.16.2

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

[PATCH net-next 2/2] net: cdc_eem: clean up bind error path

[Johan Hovold]

Drop bogus call to usb_driver_release_interface() from an error path in
the usbnet bind() callback, which is called during interface probe. At
this point the interface is not bound and usb_driver_release_interface()
returns early.

Also remove the bogus call to clear the interface data, which is owned
by the usbnet driver and would not even have been set by the time bind()
is called.

Signed-off-by: Johan Hovold 
---
 drivers/net/usb/cdc_eem.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/usb/cdc_eem.c b/drivers/net/usb/cdc_eem.c
index f7180f8db39e..61ea4eaace5d 100644
--- a/drivers/net/usb/cdc_eem.c
+++ b/drivers/net/usb/cdc_eem.c
@@ -83,11 +83,8 @@ static int eem_bind(struct usbnet *dev, struct usb_interface 
*intf)
int status = 0;
 
status = usbnet_get_endpoints(dev, intf);
-   if (status < 0) {
-   usb_set_intfdata(intf, NULL);
-   usb_driver_release_interface(driver_of(intf), intf);
+   if (status < 0)
return status;
-   }
 
/* no jumbogram (16K) support for now */
 
-- 
2.16.2

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

[PATCH net-next 1/2] net: kalmia: clean up bind error path

[Johan Hovold]

Drop bogus call to usb_driver_release_interface() from an error path in
the usbnet bind() callback, which is called during interface probe. At
this point the interface is not bound and usb_driver_release_interface()
returns early.

Also remove the bogus call to clear the interface data, which is owned
by the usbnet driver and would not even have been set by the time bind()
is called.

Signed-off-by: Johan Hovold 
---
 drivers/net/usb/kalmia.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
index 1ec523b0e932..bd2ba3659028 100644
--- a/drivers/net/usb/kalmia.c
+++ b/drivers/net/usb/kalmia.c
@@ -150,12 +150,8 @@ kalmia_bind(struct usbnet *dev, struct usb_interface *intf)
dev->rx_urb_size = dev->hard_mtu * 10; // Found as optimal after testing
 
status = kalmia_init_and_get_ethernet_addr(dev, ethernet_addr);
-
-   if (status) {
-   usb_set_intfdata(intf, NULL);
-   usb_driver_release_interface(driver_of(intf), intf);
+   if (status)
return status;
-   }
 
memcpy(dev->net->dev_addr, ethernet_addr, ETH_ALEN);
 
-- 
2.16.2

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