Re: [PATCH v3] usb: dwc2: Fix kernel doc's warnings.

[Minas Harutyunyan]

On 5/16/2018 12:04 PM, Grigor Tovmasyan wrote:
> Added descriptions for all not described parameters.
> Fix all kernel doc's warnings.
> 
> Signed-off-by: Grigor Tovmasyan 
> ---

Acked-by: Minas Harutyunyan 

>   drivers/usb/dwc2/core.c  |   7 ++
>   drivers/usb/dwc2/core.h  | 170 
> ++-
>   drivers/usb/dwc2/debug.h |   2 +-
>   drivers/usb/dwc2/debugfs.c   |  19 ++---
>   drivers/usb/dwc2/gadget.c|  29 +---
>   drivers/usb/dwc2/hcd.c   |   3 +-
>   drivers/usb/dwc2/hcd.h   |  14 ++--
>   drivers/usb/dwc2/hcd_ddma.c  |   1 +
>   drivers/usb/dwc2/hcd_intr.c  |  12 +++
>   drivers/usb/dwc2/hcd_queue.c |   5 +-
>   drivers/usb/dwc2/params.c|   8 ++
>   drivers/usb/dwc2/pci.c   |   6 ++
>   12 files changed, 215 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 18a0a1771289..1c36a6a9dd63 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -419,6 +419,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
>   /**
>* dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
>* filter is enabled.
> + *
> + * @hsotg: Programming view of DWC_otg controller
>*/
>   static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
>   {
> @@ -564,6 +566,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool 
> skip_wait)
>* If a force is done, it requires a IDDIG debounce filter delay if
>* the filter is configured and enabled. We poll the current mode of
>* the controller to account for this delay.
> + *
> + * @hsotg: Programming view of DWC_otg controller
> + * @host: Host mode flag
>*/
>   void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>   {
> @@ -610,6 +615,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>* or not because the value of the connector ID status is affected by
>* the force mode. We only need to call this once during probe if
>* dr_mode == OTG.
> + *
> + * @hsotg: Programming view of DWC_otg controller
>*/
>   static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>   {
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 2438480e4496..6d304e91c20e 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
>*   and has yet to be completed (maybe due to data move, or simply
>*   awaiting an ack from the core all the data has been completed).
>* @debugfs: File entry for debugfs file for this endpoint.
> - * @lock: State lock to protect contents of endpoint.
>* @dir_in: Set to true if this endpoint is of the IN direction, which
>*  means that it is sending data to the Host.
>* @index: The index for the endpoint registers.
>* @mc: Multi Count - number of transactions per microframe
> - * @interval - Interval for periodic endpoints, in frames or microframes.
> + * @interval: Interval for periodic endpoints, in frames or microframes.
>* @name: The name array passed to the USB core.
>* @halted: Set if the endpoint has been halted.
>* @periodic: Set if this is a periodic ep, such as Interrupt
> @@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
>* @compl_desc: index of next descriptor to be completed by xFerComplete
>* @total_data: The total number of data bytes done.
>* @fifo_size: The size of the FIFO (for periodic IN endpoints)
> + * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for EP0.
>* @fifo_load: The amount of data loaded into the FIFO (periodic IN)
>* @last_load: The offset of data for the last start of request.
>* @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
> @@ -380,9 +380,12 @@ enum dwc2_ep0_state {
>*  is FS.
>*   0 - No (default)
>*   1 - Yes
> - * @ipg_isoc_en Indicates the IPG supports is enabled or disabled.
> + * @ipg_isoc_en:Indicates the IPG supports is enabled or disabled.
>*   0 - Disable (default)
>*   1 - Enable
> + * @acg_enable:  For enabling Active Clock Gating in the 
> controller
> + *   0 - No
> + *   1 - Yes
>* @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
>*   0 - No (default)
>*   1 - Yes
> @@ -552,7 +555,7 @@ struct dwc2_core_params {
>*
>* The values that are not in dwc2_core_params are documented below.
>*
> - * @op_mode Mode of Operation
> + * @op_mode: Mode of Operation
>*   0 - HNP- and SRP-Capable OTG (Host & Device)
>*   1 - SRP-Capable OTG (Host & Device)
>*   2 - Non-HNP and Non-SRP Capable OTG (Host & Device)
> @@ -560,49 +563,102 @@ 

Re: [PATCH] usbserial: pl2303 tx xon/xoff flow control

[Florian Zumbiehl]

Hi,

> > Note that the patch has only been fully tested with kernel 4.9.28, and
> > test-compiled against 4.16.8. Tested only with the pl2303 adapters I have
> > available (which seem to be type 0 if I interpret the code correctly), I
> > don't have a clue whether this works with other versions of the chip.
> 
> What's the usb-devices (or lsusb -v) output for your device?

| T:  Bus=06 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
| D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
| P:  Vendor=067b ProdID=2303 Rev=03.00
| S:  Manufacturer=Prolific Technology Inc.
| S:  Product=USB-Serial Controller
| C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
| I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=pl2303

> > --- linux-4.16.8/drivers/usb/serial/pl2303.c.orig   2018-05-09 
> > 09:53:14.0 +0200
> > +++ linux-4.16.8/drivers/usb/serial/pl2303.c2018-05-14 
> > 04:32:27.860780856 +0200
> > @@ -544,8 +544,12 @@ static void pl2303_set_termios(struct tt
> > int ret;
> > u8 control;
> >  
> > -   if (old_termios && !tty_termios_hw_change(>termios, old_termios))
> > -   return;
> > +   if (old_termios &&
> > +   !(tty_termios_hw_change(>termios, old_termios) ||
> > + ((tty->termios.c_iflag ^ old_termios->c_iflag) & (IXON | 
> > IXANY)) ||
> > + tty->termios.c_cc[VSTOP] != old_termios->c_cc[VSTOP] ||
> > + tty->termios.c_cc[VSTART] != old_termios->c_cc[VSTART]))
> 
> Use a helper function for this (if everything is indeed needed, see
> below).
> 
> > +   return;
> 
> Odd indentation (which checkpatch would have caught).

Well, it did, but it didn't exactly offer a suggestion as to how to
reformat things that would still be readable, nor does the style guide,
AFAICS, so I kept it as it is. (Also, I doubt that had I encountered this
condition moved out of line into a separate function that would have made
it easier for me to follow what's going on.)

> > buf = kzalloc(7, GFP_KERNEL);
> > if (!buf) {
> > @@ -662,6 +666,9 @@ static void pl2303_set_termios(struct tt
> > pl2303_vendor_write(serial, 0x0, 0x41);
> > else
> > pl2303_vendor_write(serial, 0x0, 0x61);
> > +   } else if (I_IXON(tty) && !I_IXANY(tty) &&
> > +  START_CHAR(tty) == 0x11 && STOP_CHAR(tty) == 0x13) {
> 
> If the device does not support IXANY, I think you should just clear that
> bit to indicate lack of support.
> 
> And the start and stop characters cannot be modified (as far as you
> know)? Then we should probably set these in the termios whenever IXON is
> set as well since usbserial does not support falling back to the
> line-discipline IXON implementation.

I don't know how to enable IXANY or change the control characters, so I am
working with what I do know (also, I guess the screenshot of the "ROM
programming tool" in the "datasheet" suggests that none of that is
supported).

Now, I agree that signaling lack of support would be better in general, but
it does change what the code does for (still) unsupported cases. After all,
usbserial in general does not signal that it doesn't support IXON/IXANY,
but just pretends that it does. So, if there is a good reason why usbserial
ignores POSIX on this point, I would think that would still apply for the
remaining unsupported cases after partial support is implemented?!

However, in any case, the part of setting particular control characters
only when IXON is set seems like a very bad idea, in that it potentially
changes settings where no change was requested, so userspace code cannot
really be expected to check for that (and certainly not based on POSIX,
which explicitly states that other fields have to stay unchanged). So, if
we want to go with indicating lack of support, I think the correct strategy
would be to always force the control characters to what the hardware
supports.

> > +   pl2303_vendor_write(serial, 0x0, 0xc0);
> 
> Odd indentation again.

See above.

Regards, Florian
--
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] usbip: vhci_sysfs: fix potential Spectre v1

[Gustavo A. R. Silva]

pdev_nr and rhport can be controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:
drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential
spectre issue 'vhcis'
drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential
spectre issue 'vhcis'
drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential
spectre issue 'vhci->vhci_hcd_ss->vdev'
drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential
spectre issue 'vhci->vhci_hcd_hs->vdev'

Fix this by sanitizing pdev_nr and rhport before using them to index
vhcis and vhci->vhci_hcd_ss->vdev respectively.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel=152449131114778=2

Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/usbip/vhci_sysfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index 4880838..9045888 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include 
+
 #include "usbip_common.h"
 #include "vhci.h"
 
@@ -235,6 +237,8 @@ static ssize_t detach_store(struct device *dev, struct 
device_attribute *attr,
if (!valid_port(pdev_nr, rhport))
return -EINVAL;
 
+   pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers);
+   rhport = array_index_nospec(rhport, VHCI_HC_PORTS);
hcd = platform_get_drvdata(vhcis[pdev_nr].pdev);
if (hcd == NULL) {
dev_err(dev, "port is not ready %u\n", port);
@@ -325,6 +329,8 @@ static ssize_t attach_store(struct device *dev, struct 
device_attribute *attr,
if (!valid_args(pdev_nr, rhport, speed))
return -EINVAL;
 
+   pdev_nr = array_index_nospec(pdev_nr, vhci_num_controllers);
+   rhport = array_index_nospec(rhport, VHCI_HC_PORTS);
hcd = platform_get_drvdata(vhcis[pdev_nr].pdev);
if (hcd == NULL) {
dev_err(dev, "port %d is not ready\n", port);
-- 
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: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Mats Karrman]

On 05/16/2018 01:43 PM, Heikki Krogerus wrote:

> On Tue, May 15, 2018 at 11:24:07PM +0200, Mats Karrman wrote:
>> Hi Heikki,
>>
>> On 05/15/2018 09:30 AM, Heikki Krogerus wrote:
>>
>>> Hi Mats,
>>>
>>> On Fri, May 11, 2018 at 09:28:04PM +0200, Mats Karrman wrote:
 On 2018-05-11 13:14, Heikki Krogerus wrote:

> On Fri, May 11, 2018 at 11:05:55AM +0200, Mats Karrman wrote:
>> On 2018-05-10 19:49, Heikki Krogerus wrote:
>>
>>> On Thu, May 10, 2018 at 10:04:21AM +0200, Mats Karrman wrote:
 Hi,

 On 05/09/2018 02:49 PM, Heikki Krogerus wrote:

> On Tue, May 08, 2018 at 09:10:13PM +0200, Mats Karrman wrote:
>> Hi,
>>
>> On 05/08/2018 04:25 PM, Heikki Krogerus wrote:
>>
>>> Hi,
>>>
>>> On Mon, May 07, 2018 at 11:19:40PM +0200, Mats Karrman wrote:
>> Even so, when the mux driver "set" function is called, it will 
>> just get the
>> mode argument but since the mode (TYPEC_STATE_...) is 
>> overlapping for different
>> AMs if I understand your proposal correctly, the mux also needs 
>> to know what AM
>> is active.
>> Does this imply that the mux set function signature need to 
>> change?
> My plan was actually to propose we get rid of the current mux 
> handling
> (just leave the orientation switch) in favour of the 
> notifications I'm
> introducing with the type-c bus for the alternate modes. The 
> current
> mux handling is definitely not enough, and does not work in every
> scenario, like also you pointed out.
 So, the mux need to subscribe to each svid:mode pair it is 
 interested in using
 typec_altmode_register_notifier() and then use those callbacks to 
 switch the correct
 signals to the connector. And a driver for an off-the-shelf mux 
 device could have
 the translation between svid:mode pairs and mux device specific 
 control specified by
 of/acpi properties. Right?
>>> Yes. That is the plan. Would it work for you?
>> I think so. I'll give it a go. When about do you think you'll post 
>> the next version
>> of your RFC? Or do you have an updated series available somewhere 
>> public?
> I'll try to put together and post the next version tomorrow.
>
> My original plan was actually to use just the notifications with the
> muxes, but one thing to consider with the notifications is that in
> practice we have to increment the ref count for the alt mode devices
> when ever something registers a notifier.
>
> To me that does not feel ideal. The dependency should go the other way
> around in case of the muxes. That is why I liked the separate API and
> handling for the muxes felt better, as it will do just that. The mux
> is then a "service" that the port driver can as for, and if it gets a
> handle to a mux, the mux will have its ref count incremented.
>
> So I think fixing the mux API would perhaps be better after all.
> Thoughts?
 So, we're back to a mux API similar to the current one, where:
 - the port driver and the mux driver are connected through "graph"
 - alt mode driver finds its port mux using the typec class mux api
 - the mux mode setting function arguments now include both svid and 
 mode

 I like that.

 One thought that popped up again is if we, somewhere down the line,
 will see some super device that support many different alternate modes
 on the same port and therefore will need to have multiple mux devices?
 However I think the mux api could be extended (later on) to support 
 some
 aggregate mux device that manages multiple physical devices.
>>> If we simply had always a mux for every alternate mode, that would not
>>> be a problem. So the port would have its own mux, and every supported
>>> alternate mode also had its own. I think that removes the need to deal
>>> with the svid:mode when using the muxes, as they are already tied to a
>>> specific alternate modes, right? With a single mux device, for example
>>> pi3usb30532, the driver just needs to register a mux for the port and
>>> separate mux for DP, but I don't think that's a huge problem.
>> Hmm... As an hypothetical example I have written a driver for another mux
>> from TI and according to its data sheet:
>>
>> """
>> The HD3SS460 is a generic analog differential
>> passive switch that can work for any high speed
>> interface applications as long as it is biased at a
>> common 

Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

[Mats Karrman]

Hi,

On 05/16/2018 02:25 PM, Heikki Krogerus wrote:

> Hi guys,
>
> On Tue, May 15, 2018 at 10:52:57PM +0200, Mats Karrman wrote:
>> Hi,
>>
>> On 05/14/2018 11:36 AM, Jun Li wrote:
>>
>>> Hi
 -Original Message-
 From: Mats Karrman [mailto:mats.dev.l...@gmail.com]
 Sent: 2018???5???12??? 3:56
 To: Jun Li ; robh...@kernel.org; 
 gre...@linuxfoundation.org;
 heikki.kroge...@linux.intel.com; li...@roeck-us.net
 Cc: a.ha...@samsung.com; cw00.c...@samsung.com;
 shufan_...@richtek.com; Peter Chen ;
 gso...@gmail.com; devicet...@vger.kernel.org; linux-usb@vger.kernel.org;
 dl-linux-imx 
 Subject: Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port 
 power
 and data config

 Hi Li Jun,

 On 2018-05-03 02:24, Li Jun wrote:

> This patch adds 3 APIs to get the typec port power and data type, and
> preferred power role by its name string.
>
> Signed-off-by: Li Jun 
> ---
>   drivers/usb/typec/class.c | 52
 +++
>   include/linux/usb/typec.h |  3 +++
>   2 files changed, 55 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 53df10d..5981e18 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -9,6 +9,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
> I don't think you need that anymore.
>
>   #include 
>   #include 
>   #include 
> @@ -802,6 +803,12 @@ static const char * const typec_port_types[] = {
>   [TYPEC_PORT_DRP] = "dual",
>   };
>
> +static const char * const typec_data_types[] = {
> + [TYPEC_PORT_DFP] = "host",
> + [TYPEC_PORT_UFP] = "device",
> + [TYPEC_PORT_DRD] = "dual",
> +};
> +
>   static const char * const typec_port_types_drp[] = {
>   [TYPEC_PORT_SRC] = "dual [source] sink",
>   [TYPEC_PORT_SNK] = "dual source [sink]", @@ -1252,6 +1259,51
 @@
> void typec_set_pwr_opmode(struct typec_port *port,
>   }
>   EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
>
> +/**
> + * typec_find_power_type - Get the typec port power type
 Why is this function called typec_find_power_type() and not
 typec_find_port_type()?
 It's called port_type in sysfs, having different names just adds confusion.
 (Otherwise I agree power_type is a better name but...)
>>> We have "port type" before the power and data role separation,
>>> this API name's intention is to reflect the power cap, anyway I
>>> leave this to be decided by Heikki then.
> I really hate the "*_type" naming. It was understandable when there
> was no separate power and data roles defined in the specification, but
> now that there are, it's just confusing. IMO we should not use it
> anywhere.
>
> So to me typec_find_type() is just as bad as typec_find_power_type()
> because it has the "type" in it. I wonder if this function is
> necessary at all? If it is, then perhaps we can think of some better
> name for it, name that gives a better hint what it is used for.

I reread this patch and tried to see it more in the context of the other
patches and the existing code. The naming of the existing string tables
doesn't help in getting this right, however I have a proposal:

typec_find_port_power_role() to get to TYPEC_PORT_SRC/SNK/DRP
typec_find_port_data_role() to get to TYPEC_PORT_DFP/UFP/DRD
typec_find_power_role() to get to TYPEC_SINK/SOURCE

and sometime, if the use should arise 

typec_find_data_role() to get to TYPEC_DEVICE/HOST

I think it is fairly comprehensible, *_port_* concerns a capability and
without *_port_* it is an actual state. Plus it matches the names of the
constants.

BR // Mats

> + * @name: port type string
> + *
> + * This routine is used to find the typec_port_type by its string name.
> + *
> + * Returns typec_port_type if success, otherwise negative error code.
> + */
> +int typec_find_power_type(const char *name) {
> + return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> + name);
> +}
> +EXPORT_SYMBOL_GPL(typec_find_power_type);
> +
> +/**
> + * typec_find_preferred_role - Find the typec drp port preferred
> +power role
 Why typec_find_preferred_role()? Could be used for any power_role so why 
 not
 typec_find_power_role()?
>>> I am not sure if I catch your point of this comment.
>>> For preferred role(if support try.sink or try.src) the only allowed power 
>>> roles are 
>>> "sink"
>>> "source"
>>> But for power role, the allowed type are 
>>> "sink"
>>> "source"
>>> "dual"
>> Uhm, typing too fast again, I am. A better name would be just 
>> typec_find_role().
>> What I mean is that the function could be used for any situation when
>> someone wants to map 

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

[Alan Stern]

On Wed, 16 May 2018, Alexander Kappner wrote:

> The "G-Drive" (sold by G-Technology) external USB 3.0 drive
>  hangs on write access under UAS:
> 
> [  136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK 
> driverbyte=DRIVER_SENSE
> [  136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
> [  136.079152] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
> [  136.079176] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 
> 00 00 00 00 00 00 08 00 00
> [  136.079180] print_req_error: critical target error, dev sdi, sector 0
> [  136.079183] Buffer I/O error on dev sdi, logical block 0, lost sync page 
> write
> [  136.173148] EXT4-fs (sdi): mounted filesystem with ordered data mode. 
> Opts: (null)
> [  140.583998] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK 
> driverbyte=DRIVER_SENSE
> [  140.584010] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
> [  140.584016] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
> [  140.584022] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 
> c4 00 18 00 00 00 08 00 00
> [  140.584025] print_req_error: critical target error, dev sdi, sector 
> 3905159192
> [  140.584044] print_req_error: critical target error, dev sdi, sector 
> 3905159192
> [  140.584052] Aborting journal on device sdi-8.

That's kind of weird.  Does the drive work under Windows in UAS mode?  
If so, why are the WRITE(16) commands failing under Linux?

> The proposed patch adds compatibility quirks. Because the drive requires two
> quirks (one to disable UAS, and another to work with usb-storage), adding this
> under unusual_devs.h and not unusual_uas.h so kernels compiled without UAS
> receive the quirk.

That doesn't quite make sense.  Since you prevent the uas driver from 
binding to this device, it will end up using usb-storage no matter how 
the kernel was built.  Therefore the second quirk flag has to go into 
unusual_devs.h no matter what.

>  With the patch, the drive works reliably
> (tested on NEC Corporation uPD720200 USB 3.0 host controller).

You don't describe the second quirk flag at all.  Are you sure it is 
needed?

> Signed-off-by: Alexander Kappner 
> ---
>  drivers/usb/storage/unusual_devs.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/storage/unusual_devs.h 
> b/drivers/usb/storage/unusual_devs.h
> index 747d3a9..b8661a1 100644
> --- a/drivers/usb/storage/unusual_devs.h
> +++ b/drivers/usb/storage/unusual_devs.h
> @@ -2321,6 +2321,15 @@ UNUSUAL_DEV(  0x4146, 0xba01, 0x0100, 0x0100,
>   "Micro Mini 1GB",
>   USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NOT_LOCKABLE ),
>  
> +/* "G-DRIVE" external HDD hangs on write without these.
> + * Reported-by: Alexander Kappner 
> + */
> +UNUSUAL_DEV(0x4971, 0x8024, 0x, 0x,
> + "SimpleTech",
> + "External HDD",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_IGNORE_UAS | US_FL_NO_WP_DETECT),
> +
>  /*
>   * Nick Bowler 
>   * SCSI stack spams (otherwise harmless) error messages.
> 

--
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 v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Sergei Shtylyov]

Hello!

On 05/16/2018 02:56 AM, Florian Fainelli wrote:

> A number of drivers have the following pattern:
> 
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
> 
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
> 
> Signed-off-by: Florian Fainelli 
[...]

> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index ac621f44237a..02e8982519ce 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
>   priv->slave_mii_bus->parent = ds->dev->parent;
>   priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
>  
> - if (dn)
> - err = of_mdiobus_register(priv->slave_mii_bus, dn);
> - else
> - err = mdiobus_register(priv->slave_mii_bus);
> -
> - if (err)
> + err = of_mdiobus_register(priv->slave_mii_bus, dn);
> + if (err && dn)

   of_node_put() checks for NULL.

>   of_node_put(dn);
>  
>   return err;
[...]
> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc8eb5b..f3e43db0d6cb 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
> *pdev)
>   fep->mii_bus->parent = >dev;
>  
>   node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> - if (node) {
> - err = of_mdiobus_register(fep->mii_bus, node);
> + err = of_mdiobus_register(fep->mii_bus, node);
> + if (node)
>   of_node_put(node);

   Same comment here.

[...]
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
> b/drivers/net/ethernet/renesas/sh_eth.c
> index 5970d9e5ddf1..8dd41e08a6c6 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
>pdev->name, pdev->id);
>  
>   /* register MDIO bus */
> - if (dev->of_node) {
> - ret = of_mdiobus_register(mdp->mii_bus, dev->of_node);
> - } else {
> - if (pd->phy_irq > 0)
> - mdp->mii_bus->irq[pd->phy] = pd->phy_irq;
> -
> - ret = mdiobus_register(mdp->mii_bus);
> - }
> + if (pd->phy_irq > 0)
> + mdp->mii_bus->irq[pd->phy] = pd->phy_irq;
>  
> + ret = of_mdiobus_register(mdp->mii_bus, dev->of_node);
>   if (ret)
>   goto out_free_bus;
>  

   This part is:

Acked-by: Sergei Shtylyov 

[...]
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index 91761436709a..8dff87ec6d99 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -1843,12 +1843,9 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
>   }
>  
>   node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
> - if (node) {
> - ret = of_mdiobus_register(dev->mdiobus, node);
> + ret = of_mdiobus_register(dev->mdiobus, node);
> + if (node)
>   of_node_put(node);

   of_node_put() checks for NULL, again...

MBR, Sergei
--
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-storage: Add quirks to make G-Technology "G-Drive" work

[Alexander Kappner]

The "G-Drive" (sold by G-Technology) external USB 3.0 drive
 hangs on write access under UAS:

[  136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[  136.079144] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[  136.079152] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
[  136.079176] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 00 00 
00 00 00 00 00 08 00 00
[  136.079180] print_req_error: critical target error, dev sdi, sector 0
[  136.079183] Buffer I/O error on dev sdi, logical block 0, lost sync page 
write
[  136.173148] EXT4-fs (sdi): mounted filesystem with ordered data mode. Opts: 
(null)
[  140.583998] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[  140.584010] sd 15:0:0:0: [sdi] tag#0 Sense Key : Illegal Request [current]
[  140.584016] sd 15:0:0:0: [sdi] tag#0 Add. Sense: Invalid field in cdb
[  140.584022] sd 15:0:0:0: [sdi] tag#0 CDB: Write(16) 8a 08 00 00 00 00 e8 c4 
00 18 00 00 00 08 00 00
[  140.584025] print_req_error: critical target error, dev sdi, sector 
3905159192
[  140.584044] print_req_error: critical target error, dev sdi, sector 
3905159192
[  140.584052] Aborting journal on device sdi-8.

The proposed patch adds compatibility quirks. Because the drive requires two
quirks (one to disable UAS, and another to work with usb-storage), adding this
under unusual_devs.h and not unusual_uas.h so kernels compiled without UAS
receive the quirk. With the patch, the drive works reliably
(tested on NEC Corporation uPD720200 USB 3.0 host controller).

Signed-off-by: Alexander Kappner 
---
 drivers/usb/storage/unusual_devs.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index 747d3a9..b8661a1 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2321,6 +2321,15 @@ UNUSUAL_DEV(  0x4146, 0xba01, 0x0100, 0x0100,
"Micro Mini 1GB",
USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NOT_LOCKABLE ),
 
+/* "G-DRIVE" external HDD hangs on write without these.
+ * Reported-by: Alexander Kappner 
+ */
+UNUSUAL_DEV(0x4971, 0x8024, 0x, 0x,
+   "SimpleTech",
+   "External HDD",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_IGNORE_UAS | US_FL_NO_WP_DETECT),
+
 /*
  * Nick Bowler 
  * SCSI stack spams (otherwise harmless) error messages.
-- 
2.1.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-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Geert Uytterhoeven]

Hi David,

On Wed, May 16, 2018 at 8:21 PM, David Miller  wrote:
> From: Florian Fainelli 
> Date: Tue, 15 May 2018 16:56:17 -0700
>
>> This patch series updates of_mdiobus_register() such that when the 
>> device_node
>> argument is NULL, it calls mdiobus_register() directly. This is consistent 
>> with
>> the behavior of of_mdiobus_register() when CONFIG_OF=n.
>>
>> I only converted the most obvious drivers, there are others that have a much
>> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
>>
>> Changes in v2:
>>
>> - fixed build error in davincin_mdio.c (Grygorii)
>> - reworked first patch a bit: commit message, subject and removed useless
>>   code comment
>
> Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks, his feedback made perfect sense.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[David Miller]

From: Florian Fainelli 
Date: Tue, 15 May 2018 16:56:17 -0700

> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent 
> with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.
> 
> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
> 
> Changes in v2:
> 
> - fixed build error in davincin_mdio.c (Grygorii)
> - reworked first patch a bit: commit message, subject and removed useless
>   code comment

Based upon Andrew's response to Geert's feedback, I'm applying this series.

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

Re: Renesas uPD720202 USB 3.0

[Christian Brauns]

I'm running 4.16.8-1-ARCH and that controller does not work, whereas I remember 
it was working sometime before.

Now I'm travelling, don't have the controller with me, especially because it 
does not work anymore.

This is what a part of dmesg looked like in 4.16.8-1-ARCH:


[  103.911001] e1000e :00:19.0: Some CPU C-states have been disabled in 
order to enable jumbo frames
[  124.510436] pci :05:00.0: [1912:0015] type 00 class 0x0c0330
[  124.510548] pci :05:00.0: reg 0x10: [mem 0x-0x1fff 64bit]
[  124.510949] pci :05:00.0: PME# supported from D0 D3hot D3cold
[  124.520156] pci :05:00.0: BAR 0: assigned [mem 0xf1c0-0xf1c01fff 
64bit]
[  124.520220] pci :05:00.0: enabling device ( -> 0002)
[  124.536237] xhci_hcd :05:00.0: Resetting
[  125.968432] xhci_hcd :05:00.0: xHCI Host Controller
[  125.968439] xhci_hcd :05:00.0: new USB bus registered, assigned bus 
number 3
[  125.973722] xhci_hcd :05:00.0: hcc params 0x014051cf hci version 0x100 
quirks 0x0090
[  125.974199] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[  125.974201] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[  125.974202] usb usb3: Product: xHCI Host Controller
[  125.974204] usb usb3: Manufacturer: Linux 4.16.8-1-ARCH xhci-hcd
[  125.974205] usb usb3: SerialNumber: :05:00.0
[  125.974357] hub 3-0:1.0: USB hub found
[  125.974420] hub 3-0:1.0: 2 ports detected
[  125.974569] xhci_hcd :05:00.0: xHCI Host Controller
[  125.974573] xhci_hcd :05:00.0: new USB bus registered, assigned bus 
number 4
[  125.977237] usb usb4: We don't know the algorithms for LPM for this host, 
disabling LPM.
[  125.977272] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[  125.977274] usb usb4: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[  125.977276] usb usb4: Product: xHCI Host Controller
[  125.977277] usb usb4: Manufacturer: Linux 4.16.8-1-ARCH xhci-hcd
[  125.977279] usb usb4: SerialNumber: :05:00.0
[  125.977416] hub 4-0:1.0: USB hub found
[  125.977479] hub 4-0:1.0: 2 ports detected
[  126.566269] xhci_hcd :05:00.0: xHCI host controller not responding, 
assume dead
[  126.566322] xhci_hcd :05:00.0: HC died; cleaning up
[  126.914313] usb usb3-port1: couldn't allocate usb_device
[  126.914362] usb usb4-port1: couldn't allocate usb_device
[  127.414926] xhci_hcd :05:00.0: remove, state 1
[  127.414933] usb usb4: USB disconnect, device number 1
[  127.415106] xhci_hcd :05:00.0: USB bus 4 deregistered
[  127.415110] xhci_hcd :05:00.0: remove, state 1
[  127.415114] usb usb3: USB disconnect, device number 1
[  127.415282] xhci_hcd :05:00.0: Host halt failed, -19
[  127.415288] xhci_hcd :05:00.0: Host not accessible, reset failed.
[  127.415525] xhci_hcd :05:00.0: USB bus 3 deregistered
[  127.520610] pci :05:00.0: [1912:0015] type 00 class 0x0c0330
[  127.520740] pci :05:00.0: reg 0x10: [mem 0x-0x1fff 64bit]
[  127.521183] pci :05:00.0: PME# supported from D0 D3hot D3cold
[  127.530190] pci :05:00.0: BAR 0: assigned [mem 0xf1c0-0xf1c01fff 
64bit]
[  127.530261] pci :05:00.0: enabling device ( -> 0002)
[  127.530733] xhci_hcd :05:00.0: Resetting
[  128.955196] xhci_hcd :05:00.0: xHCI Host Controller
[  128.955202] xhci_hcd :05:00.0: new USB bus registered, assigned bus 
number 3
[  128.960487] xhci_hcd :05:00.0: hcc params 0x014051cf hci version 0x100 
quirks 0x0090
[  128.960931] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[  128.960933] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[  128.960934] usb usb3: Product: xHCI Host Controller
[  128.960935] usb usb3: Manufacturer: Linux 4.16.8-1-ARCH xhci-hcd
[  128.960936] usb usb3: SerialNumber: :05:00.0
[  128.961054] hub 3-0:1.0: USB hub found
[  128.96] hub 3-0:1.0: 2 ports detected
[  128.961208] xhci_hcd :05:00.0: xHCI Host Controller
[  128.961211] xhci_hcd :05:00.0: new USB bus registered, assigned bus 
number 4
[  128.964011] usb usb4: We don't know the algorithms for LPM for this host, 
disabling LPM.
[  128.964043] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[  128.964046] usb usb4: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[  128.964048] usb usb4: Product: xHCI Host Controller
[  128.964049] usb usb4: Manufacturer: Linux 4.16.8-1-ARCH xhci-hcd
[  128.964051] usb usb4: SerialNumber: :05:00.0
[  128.964213] hub 4-0:1.0: USB hub found
[  128.964276] hub 4-0:1.0: 2 ports detected
[  129.554923] xhci_hcd :05:00.0: xHCI host controller not responding, 
assume dead
[  129.554979] xhci_hcd :05:00.0: HC died; cleaning up
[  129.900959] usb usb3-port1: couldn't allocate usb_device
[  129.901008] usb usb4-port1: couldn't allocate usb_device

For kernel 4.13.1-1-ARCH I have a similar output here, saved from the testing I 
did.

>From the archlinux forum I got 

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[kbuild test robot]

Hi Florian,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/of-mdio-Fall-back-to-mdiobus_register-with-np-is-NULL/20180516-203317
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/net//ethernet/ti/davinci_mdio.c: In function 'davinci_mdio_probe':
>> drivers/net//ethernet/ti/davinci_mdio.c:457:12: error: invalid storage class 
>> for function 'davinci_mdio_remove'
static int davinci_mdio_remove(struct platform_device *pdev)
   ^~~
>> drivers/net//ethernet/ti/davinci_mdio.c:457:1: warning: ISO C90 forbids 
>> mixed declarations and code [-Wdeclaration-after-statement]
static int davinci_mdio_remove(struct platform_device *pdev)
^~
>> drivers/net//ethernet/ti/davinci_mdio.c:471:12: error: invalid storage class 
>> for function 'davinci_mdio_runtime_suspend'
static int davinci_mdio_runtime_suspend(struct device *dev)
   ^~~~
>> drivers/net//ethernet/ti/davinci_mdio.c:485:12: error: invalid storage class 
>> for function 'davinci_mdio_runtime_resume'
static int davinci_mdio_runtime_resume(struct device *dev)
   ^~~
>> drivers/net//ethernet/ti/davinci_mdio.c:495:12: error: invalid storage class 
>> for function 'davinci_mdio_suspend'
static int davinci_mdio_suspend(struct device *dev)
   ^~~~
>> drivers/net//ethernet/ti/davinci_mdio.c:512:12: error: invalid storage class 
>> for function 'davinci_mdio_resume'
static int davinci_mdio_resume(struct device *dev)
   ^~~
   In file included from include/linux/device.h:23:0,
from include/linux/platform_device.h:14,
from drivers/net//ethernet/ti/davinci_mdio.c:29:
>> drivers/net//ethernet/ti/davinci_mdio.c:527:21: error: initializer element 
>> is not constant
 SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
   include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_suspend = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:527:21: note: (near initialization 
for 'davinci_mdio_pm_ops.runtime_suspend')
 SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
   include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_suspend = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:528:7: error: initializer element is 
not constant
  davinci_mdio_runtime_resume, NULL)
  ^
   include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_resume = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:528:7: note: (near initialization 
for 'davinci_mdio_pm_ops.runtime_resume')
  davinci_mdio_runtime_resume, NULL)
  ^
   include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_resume = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:330:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .suspend_late = suspend_fn, \
 ^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization 
for 'davinci_mdio_pm_ops.suspend_late')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:330:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .suspend_late = suspend_fn, \
 ^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
   include/linux/pm.h:331:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .resume_early = resume_fn, \
 ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization 
for 'davinci_mdio_pm_ops.resume_early')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Greg KH]

On Wed, May 16, 2018 at 04:13:31PM +, mario.limoncie...@dell.com wrote:
> > > [1] When the power supply for the docking station is bigger than the
> > > laptop's power supply, you begin to wonder what is in that thing and
> > > stop using it after a while...
> 
> Mostly to satisfy letting the docking station work with beefier machines and
> still deliver power up to what USB PD will negotiate.
> I think they can actually run with smaller power supplies but you will need
> something "a little" bigger than regular system power supply to power the
> dock and system both.

Given the date of my docking station (2+ years old), I would be _amazed_
if it could do USB PD.  But I should go try it, my existing Dell laptop
doesn't support that, but I have an Acer here, along with some
chromebooks that do.

I guess I need to go get the latest Dell laptop, "just to test" with :)

thanks,

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

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[kbuild test robot]

Hi Florian,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/of-mdio-Fall-back-to-mdiobus_register-with-np-is-NULL/20180516-203317
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

 .runtime_suspend = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:527:21: note: (near initialization 
for 'davinci_mdio_pm_ops.runtime_suspend')
 SET_RUNTIME_PM_OPS(davinci_mdio_runtime_suspend,
^
   include/linux/pm.h:354:21: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_suspend = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:528:7: error: initializer element is 
not constant
  davinci_mdio_runtime_resume, NULL)
  ^
   include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_resume = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:528:7: note: (near initialization 
for 'davinci_mdio_pm_ops.runtime_resume')
  davinci_mdio_runtime_resume, NULL)
  ^
   include/linux/pm.h:355:20: note: in definition of macro 'SET_RUNTIME_PM_OPS'
 .runtime_resume = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:330:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .suspend_late = suspend_fn, \
 ^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization 
for 'davinci_mdio_pm_ops.suspend_late')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:330:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .suspend_late = suspend_fn, \
 ^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
   include/linux/pm.h:331:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .resume_early = resume_fn, \
 ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization 
for 'davinci_mdio_pm_ops.resume_early')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
   include/linux/pm.h:331:18: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .resume_early = resume_fn, \
 ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:332:17: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .freeze_late = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: note: (near initialization 
for 'davinci_mdio_pm_ops.freeze_late')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include/linux/pm.h:332:17: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .freeze_late = suspend_fn, \
^~
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
   include/linux/pm.h:333:16: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .thaw_early = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:53: note: (near initialization 
for 'davinci_mdio_pm_ops.thaw_early')
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
^
   include/linux/pm.h:333:16: note: in definition of macro 
'SET_LATE_SYSTEM_SLEEP_PM_OPS'
 .thaw_early = resume_fn, \
   ^
   drivers/net//ethernet/ti/davinci_mdio.c:529:31: error: initializer element 
is not constant
 SET_LATE_SYSTEM_SLEEP_PM_OPS(davinci_mdio_suspend, davinci_mdio_resume)
  ^
   include

RE: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Mario.Limonciello]

> -Original Message-
> From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
> Sent: Wednesday, May 16, 2018 6:58 AM
> To: Greg KH; Paul Menzel
> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Limonciello, 
> Mario
> Subject: Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell 
> XPS 13
> 9370
> 
> Hi,
> 
> On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote:
> > On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote:
> > > Dear Greg,
> > >
> > >
> > > As always, thank you for the prompt response.
> > >
> > >
> > > On 05/15/18 18:00, Greg KH wrote:
> > > > On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:
> > >
> > > > > Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with 
> > > > > Debian
> > > > > Sid/unstable.
> > > > >
> > > > > ```
> > > > > [???]
> > > > > [0.440240] usb: port power management may be unreliable
> > > > > [0.441358] usbcore: registered new interface driver usb-storage
> > > > > [0.441367] usbcore: registered new interface driver 
> > > > > usbserial_generic
> > > > > [0.441369] usbserial: USB Serial support registered for generic
> > > > > [0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 
> > > > > 0x2, got
> > > > > 0x0
> > > > > [0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
> > > > > [???]
> > > > > ```
> > > > >
> > > > > 1.  Are the ioremap and ucsi_acpi error related or is a separate 
> > > > > report
> > > > > needed?
> > > >
> > > > The ioremap error is what causes ucsi_acpi to fail the probe call (-12
> > > > is "out of memory".)
> > > >
> > > > > 2.  Do you know the reason for the ucsi_acpi error?
> > > >
> > > > the call to ioremap failed.
> > > >
> > > > Does this device really have a working typec connector?
> > >
> > > Just to avoid misunderstandings, no device was connected to the laptop
> > > during my test.
> > >
> > > But, from other boots, the Dell docking station TB16 kind of works with 
> > > it,
> > > so I???d say the USB Type-C connector is working.
> >
> > Ok, good, this might just be the acpi tables not set up properly for
> > this type of connection.  Odd that the tables show it should work,
> > Heikki should know more about this.
> 
> The firmware probable has not implemented UCSI on this board. I think
> Dell always supplies the ACPI device node for UCSI in their acpi
> tables. The _STA method in that device node is then used to inform the
> OS if the interface exists or not. The return value for _STA comes
> probable from BIOS, so this is most likely a BIOS problem.

Heikki,

I confirmed with internal team that UCSI is implemented on XPS 9370
and was confirmed to be working properly with Windows 10 RS2+.

The reason that _STA is responding on this device node now but wasn't
previously is it wasn't exposed in Linux until 4.16 when the Win 10 RS2
OSI string started to respond.

Intel should internally have some XPS 9370 you can remotely access if
you would like to poke around ACPI tables some.

> 
> Please note that UCSI will only supply status information to the
> operating system, so the USB Type-C ports will function normally even
> without it. The ports are handled in firmware on these platforms.
> 
> Paul, do you have the latest BIOS?
> 
> 
> > > > Does normal USB devices work with it?
> > >
> > > Sorry for being ignorant, but could you please tell me what normal USB
> > > devices are?
> >
> > If you plug a USB typeC device into this port, does it work?  A docking
> > station is a little bit "different" in that it usually uses the PCIe
> > connection, not the USB connectors.  Or at least that's how my Dell
> > docking station works last time I tried it[1]

I think the best description here is "Non-Thunderbolt" USB type C device.
Some examples:
There are Dell docking stations with Thunderbolt (TB16) or without (WD15).

You can also pick up little dongles for ethernet or combo dongles for
ethernet/VGA/HDMI/etc.

Anything non-Thunderbolt would satisfy what Greg was looking for.

> >
> > thanks,
> >
> > greg k-h
> >
> > [1] When the power supply for the docking station is bigger than the
> > laptop's power supply, you begin to wonder what is in that thing and
> > stop using it after a while...

Mostly to satisfy letting the docking station work with beefier machines and
still deliver power up to what USB PD will negotiate.
I think they can actually run with smaller power supplies but you will need
something "a little" bigger than regular system power supply to power the
dock and system both.

--
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] typec: tcpm: Provide of_node pointer as part of psy_cfg

[Adam Thomson]

For supply registration, provide of_node pointer of the port device,
via the power_supply_config structure, to allow other psy drivers
to add us as a supplier using the 'power-supplies' DT property.

Signed-off-by: Adam Thomson 
---
 drivers/usb/typec/tcpm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 72996cc..e7c0b95 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -4500,6 +4500,7 @@ static int devm_tcpm_psy_register(struct tcpm_port *port)
char *psy_name;
 
psy_cfg.drv_data = port;
+   psy_cfg.of_node = port->dev->of_node;
psy_name = devm_kzalloc(port->dev, psy_name_len, GFP_KERNEL);
if (!psy_name)
return -ENOMEM;
-- 
1.9.1

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

Re: Pandaboard OMAP4 MUSB short packet hang on UVC gadget

[Bin Liu]

Hi,

On Tue, May 15, 2018 at 10:58:16PM +0100, Kieran Bingham wrote:
> Hi Bin, Felipe,
> 
> We have been trying to get a UVC gadget operational on the Pandaboard ES
> platform, and we believe we've hit an issue with short packets on the MUSB in
> DMA mode.
 
I don't have a Pandaboard. Does it use MUSB internal DMA engine?

> Using the g_webcam module, I can instantiate a UVC video node, and use the
> uvc-gadget helper application [0] to handle the frame generation.
> 
> With DMA disabled using CONFIG_MUSB_PIO_ONLY I am able to process frames on 
> the
> host using yavta [1]
> 
> However when DMA is enabled, only the first frame is transmitted to the host,
> and I get an error from the musb_log debug prints which indicate that the
> MUSB_TXCSR_TXPKTRDY is not cleared following a short packet.

The MUSB_TXCSR_TXPKTRDY bit should be clear by the MUSB controller after
the TX packet is transmitted, there is no sw involved.

> A capture of the musb_log trace-points [2] shows the following at the end of 
> the
> log:
> 
> The 'mode' has been set to '0' instead of '1', buffer length is 902 instead of
> 1024 (expected behaviour for the last packet):
>   "ep13-Tx pkt_sz 1024, dma_addr 0xadfbbc00 length 902, mode 0"
> 
> And then there is a fault reported:
>   "ep13 old packet still ready , txcsr 2003"

I just checked the same testcase on Beaglebone Black which uses CPPI41
DMA, this bit is cleared after sent the 902-bytes end-of-frame packet.

> The host (linux, running the uvc driver with extra debug prints) reports:
> 
> [24517.711147] uvcvideo: decode_data: len: 1022, maxlen 460800
> [24517.759117] uvcvideo: decode_data: len: 1022, maxlen 459778
>  ...
> [24529.375018] uvcvideo: decode_data: len: 1022, maxlen 2944
> [24529.399073] uvcvideo: decode_data: len: 1022, maxlen 1922
> [24529.427014] uvcvideo: decode_data: len: 900, maxlen 900
> 
> And receives no further data following the end of the first frame.
> 
> 
> Are there any known issues on the musb-gadget with short-packet handling - or
> any other tests I can perform to check this ?

Nothing that I am aware of.
 
> Should I be looking to try to get the txstate() call to re-execute after a 
> delay
> (using musb_queue_resume_work() perhaps?) or does this indicate that the

I am not sure how that will make the controller to clear the TXPKTRDY
bit.

> hardware has jammed ? Stopping the pipeline (the yavta capture) and 
> restarting,

Likely that is the case.

> will successfully transfer (only) the first frame again.
> 
> Any other hints and tips appreciated!

Does the usecase ever worked on Pandaboard with older kernels? If so,
you can try to bisect the commit which causes the regression.

Regards,
-Bin.
--
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: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Mario.Limonciello]

> -Original Message-
> From: Paul Menzel [mailto:pmenzel+linux-...@molgen.mpg.de]
> Sent: Wednesday, May 16, 2018 7:36 AM
> To: Heikki Krogerus
> Cc: Greg KH; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; 
> Limonciello,
> Mario
> Subject: Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell 
> XPS 13
> 9370
> 
> Dear Heikki,
> 
> 
> On 05/16/18 13:58, Heikki Krogerus wrote:
> 
> > On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote:
> >> On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote:
> 
> >>> On 05/15/18 18:00, Greg KH wrote:
>  On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:
> >>>
> > Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian
> > Sid/unstable.
> >
> > ```
> > [???]
> > [0.440240] usb: port power management may be unreliable
> > [0.441358] usbcore: registered new interface driver usb-storage
> > [0.441367] usbcore: registered new interface driver 
> > usbserial_generic
> > [0.441369] usbserial: USB Serial support registered for generic
> > [0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, 
> > got
> > 0x0
> > [0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
> > [???]
> > ```
> >
> > 1.  Are the ioremap and ucsi_acpi error related or is a separate report
> > needed?
> 
>  The ioremap error is what causes ucsi_acpi to fail the probe call (-12
>  is "out of memory".)
> 
> > 2.  Do you know the reason for the ucsi_acpi error?
> 
>  the call to ioremap failed.
> 
>  Does this device really have a working typec connector?
> >>>
> >>> Just to avoid misunderstandings, no device was connected to the laptop
> >>> during my test.
> >>>
> >>> But, from other boots, the Dell docking station TB16 kind of works with 
> >>> it,
> >>> so I???d say the USB Type-C connector is working.
> >>
> >> Ok, good, this might just be the acpi tables not set up properly for
> >> this type of connection.  Odd that the tables show it should work,
> >> Heikki should know more about this.
> >
> > The firmware probable has not implemented UCSI on this board. I think
> > Dell always supplies the ACPI device node for UCSI in their acpi
> > tables. The _STA method in that device node is then used to inform the
> > OS if the interface exists or not. The return value for _STA comes
> > probable from BIOS, so this is most likely a BIOS problem.
> >
> > Please note that UCSI will only supply status information to the
> > operating system, so the USB Type-C ports will function normally even
> > without it. The ports are handled in firmware on these platforms.
> >
> > Paul, do you have the latest BIOS?
> 
> I had the latest firmware
> 
>  > DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.2.1 02/21/2018
> 
> until today, when 1.3.2 with the changes below was released [1].
> 
> Mario, it’d be great, if the Dell firmware team could start testing with
> Linux releases too to find such issues. 

Paul,

The team that sustains platforms does perform Linux testing, but it's not 
centered around latest upstream kernel and it's also functionally based (not
reviewing dmesg for new kernel errors) so there are changes in 
expectations (viewed as regressions) as you find from time to time.

> Mario, could you please also
> check internally if the Dell firmware team is aware of the issues and
> can incorporate a fix. 

Sure I'll inquire internally.

> > Fixes & Enhancements
> > Fixes:
> > - Battery can't charge over 55%
> > - Incorrect Ctrl+Alt+Del log on message with HID Event filter driver
> > - Platform can't boot to the PXE boot environment in Legacy mode via DA300
> > - Correct the flash utility string typo
> > - PCIE Card error shows in Support Assist Tool
> > - Fail 'PCR1 changed' msg prompt in CMD during running TPM PCR cycles in OS
> > - The PCI-to-PCI Bridge will lost while connecting to Dell Thunderbolt Dock 
> > TB18
> > - Adjust fan speed
> > - Skips keys when typing fast
> >
> > Enhancements:
> > - None
> 
> It’ll take me up to some days to get my hands on the device again. But
> the update should be easy enough thanks to Dell supporting fwupd with
> UEFI Capsule and uploading their updates to the Linux Vendor Firmware
> Service [2].
> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]
> http://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverId=VF23P
> [2] https://fwupd.org/

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

[PATCH V3 2/3] usb: xhci: tegra: Add runtime PM support

[Jon Hunter]

Add runtime PM support to the Tegra XHCI driver and move the function
calls to enable/disable the clocks, regulators and PHY into the runtime
PM callbacks.

Signed-off-by: Jon Hunter 
Acked-by: Thierry Reding 
---

Changes since V2:
- Remove extra unnecessary blank line
- Add Thierry's ACK

Changes since V1:
- None

 drivers/usb/host/xhci-tegra.c | 88 ++-
 1 file changed, 62 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 02b0b24faa58..437e08010587 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -761,6 +762,49 @@ static void tegra_xusb_phy_disable(struct tegra_xusb 
*tegra)
}
 }
 
+static int tegra_xusb_runtime_suspend(struct device *dev)
+{
+   struct tegra_xusb *tegra = dev_get_drvdata(dev);
+
+   tegra_xusb_phy_disable(tegra);
+   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+   tegra_xusb_clk_disable(tegra);
+
+   return 0;
+}
+
+static int tegra_xusb_runtime_resume(struct device *dev)
+{
+   struct tegra_xusb *tegra = dev_get_drvdata(dev);
+   int err;
+
+   err = tegra_xusb_clk_enable(tegra);
+   if (err) {
+   dev_err(dev, "failed to enable clocks: %d\n", err);
+   return err;
+   }
+
+   err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
+   if (err) {
+   dev_err(dev, "failed to enable regulators: %d\n", err);
+   goto disable_clk;
+   }
+
+   err = tegra_xusb_phy_enable(tegra);
+   if (err < 0) {
+   dev_err(dev, "failed to enable PHYs: %d\n", err);
+   goto disable_regulator;
+   }
+
+   return 0;
+
+disable_regulator:
+   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+disable_clk:
+   tegra_xusb_clk_disable(tegra);
+   return err;
+}
+
 static int tegra_xusb_load_firmware(struct tegra_xusb *tegra)
 {
unsigned int code_tag_blocks, code_size_blocks, code_blocks;
@@ -1067,22 +,15 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
 */
platform_set_drvdata(pdev, tegra);
 
-   err = tegra_xusb_clk_enable(tegra);
-   if (err) {
-   dev_err(>dev, "failed to enable clocks: %d\n", err);
-   goto put_usb2;
-   }
-
-   err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
-   if (err) {
-   dev_err(>dev, "failed to enable regulators: %d\n", err);
-   goto disable_clk;
-   }
+   pm_runtime_enable(>dev);
+   if (!pm_runtime_enabled(>dev))
+   err = pm_runtime_get_sync(>dev);
+   else
+   err = tegra_xusb_runtime_resume(>dev);
 
-   err = tegra_xusb_phy_enable(tegra);
if (err < 0) {
-   dev_err(>dev, "failed to enable PHYs: %d\n", err);
-   goto disable_regulator;
+   dev_err(>dev, "failed to enable device: %d\n", err);
+   goto disable_rpm;
}
 
tegra_xusb_ipfs_config(tegra, regs);
@@ -1090,7 +1127,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
err = tegra_xusb_load_firmware(tegra);
if (err < 0) {
dev_err(>dev, "failed to load firmware: %d\n", err);
-   goto disable_phy;
+   goto put_rpm;
}
 
tegra->hcd->regs = tegra->regs;
@@ -1100,7 +1137,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
err = usb_add_hcd(tegra->hcd, tegra->xhci_irq, IRQF_SHARED);
if (err < 0) {
dev_err(>dev, "failed to add USB HCD: %d\n", err);
-   goto disable_phy;
+   goto put_rpm;
}
 
device_wakeup_enable(tegra->hcd->self.controller);
@@ -1155,13 +1192,11 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
usb_put_hcd(xhci->shared_hcd);
 remove_usb2:
usb_remove_hcd(tegra->hcd);
-disable_phy:
-   tegra_xusb_phy_disable(tegra);
-disable_regulator:
-   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
-disable_clk:
-   tegra_xusb_clk_disable(tegra);
-put_usb2:
+put_rpm:
+   if (!pm_runtime_status_suspended(>dev))
+   tegra_xusb_runtime_suspend(>dev);
+disable_rpm:
+   pm_runtime_disable(>dev);
usb_put_hcd(tegra->hcd);
 put_padctl:
tegra_xusb_padctl_put(tegra->padctl);
@@ -1181,9 +1216,8 @@ static int tegra_xusb_remove(struct platform_device *pdev)
dma_free_coherent(>dev, tegra->fw.size, tegra->fw.virt,
  tegra->fw.phys);
 
-   tegra_xusb_phy_disable(tegra);
-   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
-   tegra_xusb_clk_disable(tegra);
+   pm_runtime_put_sync(>dev);
+   

[PATCH V3 1/3] usb: xhci: tegra: Prepare for adding runtime PM support

[Jon Hunter]

When adding runtime PM support to the Tegra XHCI driver, it is desirable
to move the function calls to enable the clocks, regulators and PHY from
the tegra_xusb_probe into the runtime PM handlers. Currently, the
clocks, regulators and PHY are all enabled before we call
usb_create_hcd() in tegra_xusb_probe(), however, we cannot call
pm_runtime_get_sync() at this point because the platform device data is
not yet initialised. Fortunately, the function usb_create_hcd() can be
called before we enable the clocks, regulators and PHY and so prepare
for adding runtime PM support, by moving the call to usb_create_hcd()
before we enable the hardware.

Signed-off-by: Jon Hunter 
Acked-by: Thierry Reding 
---

Changes since V2:
- Add Thierry's ACK

Changes since V1:
- None

 drivers/usb/host/xhci-tegra.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 2c076ea80522..02b0b24faa58 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -1054,10 +1054,23 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
}
}
 
+   tegra->hcd = usb_create_hcd(_xhci_hc_driver, >dev,
+   dev_name(>dev));
+   if (!tegra->hcd) {
+   err = -ENOMEM;
+   goto put_padctl;
+   }
+
+   /*
+* This must happen after usb_create_hcd(), because usb_create_hcd()
+* will overwrite the drvdata of the device with the hcd it creates.
+*/
+   platform_set_drvdata(pdev, tegra);
+
err = tegra_xusb_clk_enable(tegra);
if (err) {
dev_err(>dev, "failed to enable clocks: %d\n", err);
-   goto put_padctl;
+   goto put_usb2;
}
 
err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
@@ -1080,19 +1093,6 @@ static int tegra_xusb_probe(struct platform_device *pdev)
goto disable_phy;
}
 
-   tegra->hcd = usb_create_hcd(_xhci_hc_driver, >dev,
-   dev_name(>dev));
-   if (!tegra->hcd) {
-   err = -ENOMEM;
-   goto disable_phy;
-   }
-
-   /*
-* This must happen after usb_create_hcd(), because usb_create_hcd()
-* will overwrite the drvdata of the device with the hcd it creates.
-*/
-   platform_set_drvdata(pdev, tegra);
-
tegra->hcd->regs = tegra->regs;
tegra->hcd->rsrc_start = regs->start;
tegra->hcd->rsrc_len = resource_size(regs);
@@ -1100,7 +1100,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
err = usb_add_hcd(tegra->hcd, tegra->xhci_irq, IRQF_SHARED);
if (err < 0) {
dev_err(>dev, "failed to add USB HCD: %d\n", err);
-   goto put_usb2;
+   goto disable_phy;
}
 
device_wakeup_enable(tegra->hcd->self.controller);
@@ -1155,14 +1155,14 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
usb_put_hcd(xhci->shared_hcd);
 remove_usb2:
usb_remove_hcd(tegra->hcd);
-put_usb2:
-   usb_put_hcd(tegra->hcd);
 disable_phy:
tegra_xusb_phy_disable(tegra);
 disable_regulator:
regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
 disable_clk:
tegra_xusb_clk_disable(tegra);
+put_usb2:
+   usb_put_hcd(tegra->hcd);
 put_padctl:
tegra_xusb_padctl_put(tegra->padctl);
return err;
-- 
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

[PATCH V3 3/3] usb: xhci: tegra: Add support for managing powergates

[Jon Hunter]

The Tegra XHCI controller requires that the XUSBA (for superspeed) and
XUSBC (for host) power-domains are enabled. Commit 8df127456f29
("soc/tegra: pmc: Enable XUSB partitions on boot") was added to force
on these power-domains if the XHCI driver is enabled while proper
power-domain support is added, to ensure the device did not hang on
boot. However, rather than forcing on these power-domains in the PMC
driver we can use the legacy Tegra powergate APIs to turn on these
power-domains during the probe of the Tegra XHCI driver.

In the near future we plan to move the Tegra XHCI driver to use the
generic PM domain framework for power-domains and so to prepare for
this only use the legacy Tegra powergate API if there is not PM
domain associated with device (ie. dev.pm_domain is NULL). Please
note that in the future the superspeed and host resets will be handled
by the generic PM domain provider and so these are only these are only
needed in the case where there is no generic PM domain.

Signed-off-by: Jon Hunter 
Acked-by: Thierry Reding 
---

Changes since V2:
- Add Thierry's ACK

Changes since V1:
- None

 drivers/usb/host/xhci-tegra.c | 68 +++
 1 file changed, 49 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 437e08010587..c78fc2942bca 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 
@@ -974,20 +975,6 @@ static int tegra_xusb_probe(struct platform_device *pdev)
if (IS_ERR(tegra->padctl))
return PTR_ERR(tegra->padctl);
 
-   tegra->host_rst = devm_reset_control_get(>dev, "xusb_host");
-   if (IS_ERR(tegra->host_rst)) {
-   err = PTR_ERR(tegra->host_rst);
-   dev_err(>dev, "failed to get xusb_host reset: %d\n", err);
-   goto put_padctl;
-   }
-
-   tegra->ss_rst = devm_reset_control_get(>dev, "xusb_ss");
-   if (IS_ERR(tegra->ss_rst)) {
-   err = PTR_ERR(tegra->ss_rst);
-   dev_err(>dev, "failed to get xusb_ss reset: %d\n", err);
-   goto put_padctl;
-   }
-
tegra->host_clk = devm_clk_get(>dev, "xusb_host");
if (IS_ERR(tegra->host_clk)) {
err = PTR_ERR(tegra->host_clk);
@@ -1051,11 +1038,48 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
goto put_padctl;
}
 
+   if (!pdev->dev.pm_domain) {
+   tegra->host_rst = devm_reset_control_get(>dev,
+"xusb_host");
+   if (IS_ERR(tegra->host_rst)) {
+   err = PTR_ERR(tegra->host_rst);
+   dev_err(>dev,
+   "failed to get xusb_host reset: %d\n", err);
+   goto put_padctl;
+   }
+
+   tegra->ss_rst = devm_reset_control_get(>dev, "xusb_ss");
+   if (IS_ERR(tegra->ss_rst)) {
+   err = PTR_ERR(tegra->ss_rst);
+   dev_err(>dev, "failed to get xusb_ss reset: %d\n",
+   err);
+   goto put_padctl;
+   }
+
+   err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_XUSBA,
+   tegra->ss_clk,
+   tegra->ss_rst);
+   if (err) {
+   dev_err(>dev,
+   "failed to enable XUSBA domain: %d\n", err);
+   goto put_padctl;
+   }
+
+   err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_XUSBC,
+   tegra->host_clk,
+   tegra->host_rst);
+   if (err) {
+   dev_err(>dev,
+   "failed to enable XUSBC domain: %d\n", err);
+   goto disable_xusba;
+   }
+   }
+
tegra->supplies = devm_kcalloc(>dev, tegra->soc->num_supplies,
   sizeof(*tegra->supplies), GFP_KERNEL);
if (!tegra->supplies) {
err = -ENOMEM;
-   goto put_padctl;
+   goto disable_xusbc;
}
 
for (i = 0; i < tegra->soc->num_supplies; i++)
@@ -1065,7 +1089,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
  tegra->supplies);
if (err) {
dev_err(>dev, "failed to get regulators: %d\n", err);
-   goto put_padctl;
+   goto disable_xusbc;
}
 
for (i = 0; i < tegra->soc->num_types; i++)
@@ -1075,7 +1099,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
 

Re: [PATCH v3 0/2] add support for HiSilicon STB xHCI host controller

[Mathias Nyman]

On 14.05.2018 09:20, sunj...@163.com wrote:

From: Jianguo Sun 

This patch set adds bindings doc and xhci driver for xHCI host controller
on HiSilicon STB SoCs.



Looks good to me, adding to queue

-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] usbserial: pl2303 tx xon/xoff flow control

[Johan Hovold]

On Mon, May 14, 2018 at 05:15:11AM +0200, Florian Zumbiehl wrote:
> Support hardware-level Xon/Xoff flow control in transmit direction with
> pl2303.
> 
> Signed-off-by: Florian Zumbiehl 
> ---
> Note that the patch has only been fully tested with kernel 4.9.28, and
> test-compiled against 4.16.8. Tested only with the pl2303 adapters I have
> available (which seem to be type 0 if I interpret the code correctly), I
> don't have a clue whether this works with other versions of the chip.

What's the usb-devices (or lsusb -v) output for your device?

> --- linux-4.16.8/drivers/usb/serial/pl2303.c.orig 2018-05-09 
> 09:53:14.0 +0200
> +++ linux-4.16.8/drivers/usb/serial/pl2303.c  2018-05-14 04:32:27.860780856 
> +0200
> @@ -544,8 +544,12 @@ static void pl2303_set_termios(struct tt
>   int ret;
>   u8 control;
>  
> - if (old_termios && !tty_termios_hw_change(>termios, old_termios))
> - return;
> + if (old_termios &&
> + !(tty_termios_hw_change(>termios, old_termios) ||
> +   ((tty->termios.c_iflag ^ old_termios->c_iflag) & (IXON | 
> IXANY)) ||
> +   tty->termios.c_cc[VSTOP] != old_termios->c_cc[VSTOP] ||
> +   tty->termios.c_cc[VSTART] != old_termios->c_cc[VSTART]))

Use a helper function for this (if everything is indeed needed, see
below).

> + return;

Odd indentation (which checkpatch would have caught).

>  
>   buf = kzalloc(7, GFP_KERNEL);
>   if (!buf) {
> @@ -662,6 +666,9 @@ static void pl2303_set_termios(struct tt
>   pl2303_vendor_write(serial, 0x0, 0x41);
>   else
>   pl2303_vendor_write(serial, 0x0, 0x61);
> + } else if (I_IXON(tty) && !I_IXANY(tty) &&
> +START_CHAR(tty) == 0x11 && STOP_CHAR(tty) == 0x13) {

If the device does not support IXANY, I think you should just clear that
bit to indicate lack of support.

And the start and stop characters cannot be modified (as far as you
know)? Then we should probably set these in the termios whenever IXON is
set as well since usbserial does not support falling back to the
line-discipline IXON implementation.

> + pl2303_vendor_write(serial, 0x0, 0xc0);

Odd indentation again.

>   } else {
>   pl2303_vendor_write(serial, 0x0, 0x0);
>   }

Thanks,
Johan
--
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: dwc2: Regression on 96Boards Hikey due to enabling power down

[Manivannan Sadhasivam]

Hello,

Commit 03ea6d6e9e1ff1b0222eb723eee5990d3511cc4d introduced the powerdown
feature in USB DWC2 driver which stops USB from working on 96Boards HiKey board.

During bootup, USB host controller goes into hibernation state and when any
USB device is plugged onto the port, the host finishes executing the
GPWRDN interrupt handler but still it didn't wake up.

Below is the dmesg log after plugging a device onto USB port:

[   30.763414] dwc2 f72c.usb: dwc2_handle_gpwrdn_intr: 
dwc2_handle_gpwrdwn_intr called gpwrdn= 081411bb
[   30.763458] dwc2 f72c.usb: dwc2_handle_gpwrdn_intr: GPWRDN_LNSTSCHG
[   30.763492] dwc2 f72c.usb: dwc2_host_exit_hibernation: called with 
rem_wakeup = 1 reset = 0
[   30.763623] dwc2 f72c.usb: dwc2_restore_essential_regs: restoring 
essential regs
[   30.763671] dwc2 f72c.usb: restore done  generated here
[   30.976707] dwc2 f72c.usb: dwc2_restore_global_registers
[   30.976723] dwc2 f72c.usb: dwc2_restore_host_registers
[   30.976741] dwc2 f72c.usb: Host hibernation restore complete

I tried to manually reset the HUB and PHY after plugging in the device but that
didn't help.

This issue has been detected in kernel 4.17-rc1.

Can anyone shed some light here? Any help would be greatly appreciated!

Note: On this board, the USB controller's DP/DM out is connected to a switch
which switches between a USB type C port and a HUB (USB2513B).

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

[RFC PATCH] iscsit_wait_for_tag() can be static

[kbuild test robot]

Fixes: 5aff7a710f13 ("Convert target drivers to use sbitmap")
Signed-off-by: Fengguang Wu 
---
 iscsi_target_util.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/iscsi/iscsi_target_util.c 
b/drivers/target/iscsi/iscsi_target_util.c
index 28bcffa..e147aef 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -147,7 +147,7 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
spin_unlock_bh(>r2t_lock);
 }
 
-int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
+static int iscsit_wait_for_tag(struct se_session *se_sess, int state, int 
*cpup)
 {
int tag = -1;
DEFINE_WAIT(wait);
--
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] Convert target drivers to use sbitmap

[kbuild test robot]

Hi Matthew,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc5 next-20180516]
[cannot apply to target/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matthew-Wilcox/Use-sbitmap-instead-of-percpu_ida/20180516-143658
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/target/iscsi/iscsi_target_util.c:150:5: sparse: symbol 
>> 'iscsit_wait_for_tag' was not declared. Should it be static?
   drivers/target/iscsi/iscsi_target_util.c:1174:31: sparse: expression using 
sizeof(void)
   drivers/target/iscsi/iscsi_target_util.c:1174:31: sparse: expression using 
sizeof(void)

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Paul Menzel]

Dear Heikki,


On 05/16/18 13:58, Heikki Krogerus wrote:


On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote:

On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote:



On 05/15/18 18:00, Greg KH wrote:

On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:



Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian
Sid/unstable.

```
[???]
[0.440240] usb: port power management may be unreliable
[0.441358] usbcore: registered new interface driver usb-storage
[0.441367] usbcore: registered new interface driver usbserial_generic
[0.441369] usbserial: USB Serial support registered for generic
[0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got
0x0
[0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
[???]
```

1.  Are the ioremap and ucsi_acpi error related or is a separate report
needed?


The ioremap error is what causes ucsi_acpi to fail the probe call (-12
is "out of memory".)


2.  Do you know the reason for the ucsi_acpi error?


the call to ioremap failed.

Does this device really have a working typec connector?


Just to avoid misunderstandings, no device was connected to the laptop
during my test.

But, from other boots, the Dell docking station TB16 kind of works with it,
so I???d say the USB Type-C connector is working.


Ok, good, this might just be the acpi tables not set up properly for
this type of connection.  Odd that the tables show it should work,
Heikki should know more about this.


The firmware probable has not implemented UCSI on this board. I think
Dell always supplies the ACPI device node for UCSI in their acpi
tables. The _STA method in that device node is then used to inform the
OS if the interface exists or not. The return value for _STA comes
probable from BIOS, so this is most likely a BIOS problem.

Please note that UCSI will only supply status information to the
operating system, so the USB Type-C ports will function normally even
without it. The ports are handled in firmware on these platforms.

Paul, do you have the latest BIOS?


I had the latest firmware

> DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.2.1 02/21/2018

until today, when 1.3.2 with the changes below was released [1].

Mario, it’d be great, if the Dell firmware team could start testing with 
Linux releases too to find such issues. Mario, could you please also 
check internally if the Dell firmware team is aware of the issues and 
can incorporate a fix. (I really wish the firmware would be free 
software, so that these issues could be fixed ourselves.)



Fixes & Enhancements
Fixes:
- Battery can't charge over 55%
- Incorrect Ctrl+Alt+Del log on message with HID Event filter driver
- Platform can't boot to the PXE boot environment in Legacy mode via DA300
- Correct the flash utility string typo
- PCIE Card error shows in Support Assist Tool
- Fail 'PCR1 changed' msg prompt in CMD during running TPM PCR cycles in OS
- The PCI-to-PCI Bridge will lost while connecting to Dell Thunderbolt Dock TB18
- Adjust fan speed
- Skips keys when typing fast

Enhancements:
- None


It’ll take me up to some days to get my hands on the device again. But 
the update should be easy enough thanks to Dell supporting fwupd with 
UEFI Capsule and uploading their updates to the Linux Vendor Firmware 
Service [2].



Kind regards,

Paul


[1] 
http://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverId=VF23P

[2] https://fwupd.org/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Andrew Lunn]

On Wed, May 16, 2018 at 10:54:12AM +0200, Geert Uytterhoeven wrote:
> Hi Florian,
> 
> Thanks for your series!
> I like the effect on simplifying drivers.
> 
> On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli  
> wrote:
> > This patch series updates of_mdiobus_register() such that when the 
> > device_node
> > argument is NULL, it calls mdiobus_register() directly. This is consistent 
> > with
> > the behavior of of_mdiobus_register() when CONFIG_OF=n.
> 
> IMHO the CONFIG_OF=n behavior of of_mdiobus_register() (which I wasn't
> aware of) is inconsistent with the behavior of other of_*() functions,
> which are just empty stubs.
> 
> So I'm wondering if you should do it the other way around, and let
> mdiobus_register() call of_mdiobus_register() if dev->of_node exists?

Hi Geert

dev->of_node is often not the correct OF node. The mdio properties are
often embedded inside a MAC driver, and use an 'mdio' container
node. This container node is needed, not the device node.

> I haven't looked at the ACPI handling, but perhaps this can be moved
> inside mdiobus_register() as well?

The ACPI binding for MDIO and PHYs has not been defined yet.

Andrew
--
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 05/14] usb: typec: add API to get typec basic port power and data config

[Heikki Krogerus]

Hi guys,

On Tue, May 15, 2018 at 10:52:57PM +0200, Mats Karrman wrote:
> Hi,
> 
> On 05/14/2018 11:36 AM, Jun Li wrote:
> 
> > Hi
> >> -Original Message-
> >> From: Mats Karrman [mailto:mats.dev.l...@gmail.com]
> >> Sent: 2018???5???12??? 3:56
> >> To: Jun Li ; robh...@kernel.org; 
> >> gre...@linuxfoundation.org;
> >> heikki.kroge...@linux.intel.com; li...@roeck-us.net
> >> Cc: a.ha...@samsung.com; cw00.c...@samsung.com;
> >> shufan_...@richtek.com; Peter Chen ;
> >> gso...@gmail.com; devicet...@vger.kernel.org; linux-usb@vger.kernel.org;
> >> dl-linux-imx 
> >> Subject: Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port 
> >> power
> >> and data config
> >>
> >> Hi Li Jun,
> >>
> >> On 2018-05-03 02:24, Li Jun wrote:
> >>
> >>> This patch adds 3 APIs to get the typec port power and data type, and
> >>> preferred power role by its name string.
> >>>
> >>> Signed-off-by: Li Jun 
> >>> ---
> >>>   drivers/usb/typec/class.c | 52
> >> +++
> >>>   include/linux/usb/typec.h |  3 +++
> >>>   2 files changed, 55 insertions(+)
> >>>
> >>> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> >>> index 53df10d..5981e18 100644
> >>> --- a/drivers/usb/typec/class.c
> >>> +++ b/drivers/usb/typec/class.c
> >>> @@ -9,6 +9,7 @@
> >>>   #include 
> >>>   #include 
> >>>   #include 
> >>> +#include 

I don't think you need that anymore.

> >>>   #include 
> >>>   #include 
> >>>   #include 
> >>> @@ -802,6 +803,12 @@ static const char * const typec_port_types[] = {
> >>>   [TYPEC_PORT_DRP] = "dual",
> >>>   };
> >>>
> >>> +static const char * const typec_data_types[] = {
> >>> + [TYPEC_PORT_DFP] = "host",
> >>> + [TYPEC_PORT_UFP] = "device",
> >>> + [TYPEC_PORT_DRD] = "dual",
> >>> +};
> >>> +
> >>>   static const char * const typec_port_types_drp[] = {
> >>>   [TYPEC_PORT_SRC] = "dual [source] sink",
> >>>   [TYPEC_PORT_SNK] = "dual source [sink]", @@ -1252,6 +1259,51
> >> @@
> >>> void typec_set_pwr_opmode(struct typec_port *port,
> >>>   }
> >>>   EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
> >>>
> >>> +/**
> >>> + * typec_find_power_type - Get the typec port power type
> >> Why is this function called typec_find_power_type() and not
> >> typec_find_port_type()?
> >> It's called port_type in sysfs, having different names just adds confusion.
> >> (Otherwise I agree power_type is a better name but...)
> > We have "port type" before the power and data role separation,
> > this API name's intention is to reflect the power cap, anyway I
> > leave this to be decided by Heikki then.

I really hate the "*_type" naming. It was understandable when there
was no separate power and data roles defined in the specification, but
now that there are, it's just confusing. IMO we should not use it
anywhere.

So to me typec_find_type() is just as bad as typec_find_power_type()
because it has the "type" in it. I wonder if this function is
necessary at all? If it is, then perhaps we can think of some better
name for it, name that gives a better hint what it is used for.

> >>> + * @name: port type string
> >>> + *
> >>> + * This routine is used to find the typec_port_type by its string name.
> >>> + *
> >>> + * Returns typec_port_type if success, otherwise negative error code.
> >>> + */
> >>> +int typec_find_power_type(const char *name) {
> >>> + return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> >>> + name);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(typec_find_power_type);
> >>> +
> >>> +/**
> >>> + * typec_find_preferred_role - Find the typec drp port preferred
> >>> +power role
> >> Why typec_find_preferred_role()? Could be used for any power_role so why 
> >> not
> >> typec_find_power_role()?
> > I am not sure if I catch your point of this comment.
> > For preferred role(if support try.sink or try.src) the only allowed power 
> > roles are 
> > "sink"
> > "source"
> > But for power role, the allowed type are 
> > "sink"
> > "source"
> > "dual"
> 
> Uhm, typing too fast again, I am. A better name would be just 
> typec_find_role().
> What I mean is that the function could be used for any situation when
> someone wants to map a string to a TYPEC_{SOURCE,SINK} constant so it
> is unnecessary to limit its usage to just preferred role.

That sounds reasonable to me.


Thanks,

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

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Heikki Krogerus]

Hi,

On Wed, May 16, 2018 at 10:02:26AM +0200, Greg KH wrote:
> On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote:
> > Dear Greg,
> > 
> > 
> > As always, thank you for the prompt response.
> > 
> > 
> > On 05/15/18 18:00, Greg KH wrote:
> > > On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:
> > 
> > > > Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian
> > > > Sid/unstable.
> > > > 
> > > > ```
> > > > [???]
> > > > [0.440240] usb: port power management may be unreliable
> > > > [0.441358] usbcore: registered new interface driver usb-storage
> > > > [0.441367] usbcore: registered new interface driver 
> > > > usbserial_generic
> > > > [0.441369] usbserial: USB Serial support registered for generic
> > > > [0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, 
> > > > got
> > > > 0x0
> > > > [0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
> > > > [???]
> > > > ```
> > > > 
> > > > 1.  Are the ioremap and ucsi_acpi error related or is a separate report
> > > > needed?
> > > 
> > > The ioremap error is what causes ucsi_acpi to fail the probe call (-12
> > > is "out of memory".)
> > > 
> > > > 2.  Do you know the reason for the ucsi_acpi error?
> > > 
> > > the call to ioremap failed.
> > > 
> > > Does this device really have a working typec connector?
> > 
> > Just to avoid misunderstandings, no device was connected to the laptop
> > during my test.
> > 
> > But, from other boots, the Dell docking station TB16 kind of works with it,
> > so I???d say the USB Type-C connector is working.
> 
> Ok, good, this might just be the acpi tables not set up properly for
> this type of connection.  Odd that the tables show it should work,
> Heikki should know more about this.

The firmware probable has not implemented UCSI on this board. I think
Dell always supplies the ACPI device node for UCSI in their acpi
tables. The _STA method in that device node is then used to inform the
OS if the interface exists or not. The return value for _STA comes
probable from BIOS, so this is most likely a BIOS problem.

Please note that UCSI will only supply status information to the
operating system, so the USB Type-C ports will function normally even
without it. The ports are handled in firmware on these platforms.

Paul, do you have the latest BIOS?


> > > Does normal USB devices work with it?
> > 
> > Sorry for being ignorant, but could you please tell me what normal USB
> > devices are?
> 
> If you plug a USB typeC device into this port, does it work?  A docking
> station is a little bit "different" in that it usually uses the PCIe
> connection, not the USB connectors.  Or at least that's how my Dell
> docking station works last time I tried it[1]
> 
> thanks,
> 
> greg k-h
> 
> [1] When the power supply for the docking station is bigger than the
> laptop's power supply, you begin to wonder what is in that thing and
> stop using it after a while...

Br,

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

Re: Not enough bandwidth with Magewell XI100DUSB-HDMI

[Mathias Nyman]

On 15.05.2018 12:22, Michael Tretter wrote:

Hi Mathias,

On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote:

On 09.04.2018 11:21, Michael Tretter wrote:

On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote:

On 16.02.2018 15:28, Michael Tretter wrote:

On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote:

On 19.01.2018 22:12, Philipp Zabel wrote:

On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter
 wrote:

I found the old thread and it sounds exactly like my issue. Different
camera, but same xHCI controller.


I have exactly the same issue with the xHCI controller of my laptop and
"Oculus Sensor" USB3 isochronous mostly-UVC cameras:

00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI
Controller (rev 03) (prog-if 30 [XHCI])
Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller
Flags: bus master, medium devsel, latency 0, IRQ 44
Memory at f222 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
P:  Vendor=2833 ProdID=0211 Rev= 0.00
S:  Manufacturer=Oculus VR
S:  Product=Rift Sensor
S:  SerialNumber=WMTD3034300BCT
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA
A:  FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo
E:  Ad=83(I) Atr=03(Int.) MxPS=  32 Ivl=128ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
I:  If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
E:  Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us
I:  If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
E:  Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us

Any USB2 or USB3 device that I plug in while the first camera is streaming in
altsetting 1 or 2 causes the bandwidth error. The same happens when I try to
change the altsetting on an isochronous endpoint of an already plugged device.
While the camera is in altsetting 0, other devices can be probed and work.
 

For some tests, I changed the xhci_change_max_exit_latency() function
to ignore the requested MEL and set the MEL to 0. Now the USB devices
are detected correctly.


Exactly the same thing helps here, as well. With this hack, streaming from two
of those cameras at the same time works without any apparent problem:

--8<--
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 297536c9fd00..3cb4a60d8822 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4025,7 +4025,7 @@ static int __maybe_unused
xhci_change_max_exit_latency(struct xhci_hcd *xhci,
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx);
slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT));
-   slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency);
+   slot_ctx->dev_info2 |= cpu_to_le32(0);
slot_ctx->dev_state = 0;

xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
-->8--
 


Ok, back after a week on sickleave.
I'm getting the magewell capture device and try to reproduce this myself.


I don't think that the issue is specific to the magewell capture
device, but rather should be reproducible with any USB3 device with
isochronous endpoints.

Anyway, please tell me, if I can somehow help you to get this properly
fixed.


I'm currently looking at device reset issues after suspend, but this is on the
todo list.

I got a magewell device, (haven't unboxed it yet)
Maybe step by step instructions to reproduce it could speed things up.


Did you have time to unbox and test the Magewell device?
   


This seems to always get postponed due to other work,

I just tried it out once today on a nearby laptop, gst-launch seems to work
but couldn't reproduce the bandwidth issue when connecting a second usb device.

But I haven't really tested it out properly yet.


I just tested with 4.17-rc5 and the behavior remains the same. Is there
anything else I could do to get this fixed?



Briefed Zhengjun about this issue, one more brain on it.
Adding him to the thread.

-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: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Heikki Krogerus]

On Tue, May 15, 2018 at 11:24:07PM +0200, Mats Karrman wrote:
> Hi Heikki,
> 
> On 05/15/2018 09:30 AM, Heikki Krogerus wrote:
> 
> > Hi Mats,
> >
> > On Fri, May 11, 2018 at 09:28:04PM +0200, Mats Karrman wrote:
> >> On 2018-05-11 13:14, Heikki Krogerus wrote:
> >>
> >>> On Fri, May 11, 2018 at 11:05:55AM +0200, Mats Karrman wrote:
>  On 2018-05-10 19:49, Heikki Krogerus wrote:
> 
> > On Thu, May 10, 2018 at 10:04:21AM +0200, Mats Karrman wrote:
> >> Hi,
> >>
> >> On 05/09/2018 02:49 PM, Heikki Krogerus wrote:
> >>
> >>> On Tue, May 08, 2018 at 09:10:13PM +0200, Mats Karrman wrote:
>  Hi,
> 
>  On 05/08/2018 04:25 PM, Heikki Krogerus wrote:
> 
> > Hi,
> >
> > On Mon, May 07, 2018 at 11:19:40PM +0200, Mats Karrman wrote:
>  Even so, when the mux driver "set" function is called, it will 
>  just get the
>  mode argument but since the mode (TYPEC_STATE_...) is 
>  overlapping for different
>  AMs if I understand your proposal correctly, the mux also needs 
>  to know what AM
>  is active.
>  Does this imply that the mux set function signature need to 
>  change?
> >>> My plan was actually to propose we get rid of the current mux 
> >>> handling
> >>> (just leave the orientation switch) in favour of the 
> >>> notifications I'm
> >>> introducing with the type-c bus for the alternate modes. The 
> >>> current
> >>> mux handling is definitely not enough, and does not work in every
> >>> scenario, like also you pointed out.
> >> So, the mux need to subscribe to each svid:mode pair it is 
> >> interested in using
> >> typec_altmode_register_notifier() and then use those callbacks to 
> >> switch the correct
> >> signals to the connector. And a driver for an off-the-shelf mux 
> >> device could have
> >> the translation between svid:mode pairs and mux device specific 
> >> control specified by
> >> of/acpi properties. Right?
> > Yes. That is the plan. Would it work for you?
>  I think so. I'll give it a go. When about do you think you'll post 
>  the next version
>  of your RFC? Or do you have an updated series available somewhere 
>  public?
> >>> I'll try to put together and post the next version tomorrow.
> >>>
> >>> My original plan was actually to use just the notifications with the
> >>> muxes, but one thing to consider with the notifications is that in
> >>> practice we have to increment the ref count for the alt mode devices
> >>> when ever something registers a notifier.
> >>>
> >>> To me that does not feel ideal. The dependency should go the other way
> >>> around in case of the muxes. That is why I liked the separate API and
> >>> handling for the muxes felt better, as it will do just that. The mux
> >>> is then a "service" that the port driver can as for, and if it gets a
> >>> handle to a mux, the mux will have its ref count incremented.
> >>>
> >>> So I think fixing the mux API would perhaps be better after all.
> >>> Thoughts?
> >> So, we're back to a mux API similar to the current one, where:
> >> - the port driver and the mux driver are connected through "graph"
> >> - alt mode driver finds its port mux using the typec class mux api
> >> - the mux mode setting function arguments now include both svid and 
> >> mode
> >>
> >> I like that.
> >>
> >> One thought that popped up again is if we, somewhere down the line,
> >> will see some super device that support many different alternate modes
> >> on the same port and therefore will need to have multiple mux devices?
> >> However I think the mux api could be extended (later on) to support 
> >> some
> >> aggregate mux device that manages multiple physical devices.
> > If we simply had always a mux for every alternate mode, that would not
> > be a problem. So the port would have its own mux, and every supported
> > alternate mode also had its own. I think that removes the need to deal
> > with the svid:mode when using the muxes, as they are already tied to a
> > specific alternate modes, right? With a single mux device, for example
> > pi3usb30532, the driver just needs to register a mux for the port and
> > separate mux for DP, but I don't think that's a huge problem.
>  Hmm... As an hypothetical example I have written a driver for another mux
>  from TI and according to its data sheet:
> 
>  """
>  The HD3SS460 is a generic analog differential
>  passive switch that can work for any high speed
>  interface applications as long as it is biased at a
>  common mode voltage range of 0-2V and has
>  differential 

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Jose Abreu]

On 16-05-2018 00:56, Florian Fainelli wrote:
> A number of drivers have the following pattern:
>
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
>
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
>
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/dsa/bcm_sf2.c |  8 ++--
>  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>  drivers/net/ethernet/marvell/mvmdio.c |  5 +
>  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +

For stmmac:

Reviewed-by: Jose Abreu 

Thanks and Best Regards,
Jose Miguel Abreu

>  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
>  drivers/net/phy/mdio-gpio.c   |  6 +-
>  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>  drivers/net/usb/lan78xx.c |  7 ++-
>  11 files changed, 20 insertions(+), 61 deletions(-)
>

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

[balbi-usb:next 49/82] drivers/usb/dwc3/gadget.c:2375:19: error: 'dwc' undeclared

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
head:   3196f73ff8444f6b8bfce3dce1900b4eae27c324
commit: 0cdab4c202ea0dd241ddaacf1d3a8a282590cb61 [49/82] usb: dwc3: gadget: 
remove unnecessary 'dwc' parameter
config: x86_64-randconfig-s2-05161806 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 0cdab4c202ea0dd241ddaacf1d3a8a282590cb61
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the balbi-usb/next HEAD 3196f73ff8444f6b8bfce3dce1900b4eae27c324 builds 
fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from drivers/usb/dwc3/gadget.c:13:
   drivers/usb/dwc3/gadget.c: In function 
'dwc3_gadget_ep_cleanup_completed_requests':
>> drivers/usb/dwc3/gadget.c:2375:19: error: 'dwc' undeclared (first use in 
>> this function)
dev_WARN_ONCE(dwc->dev,
  ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   include/asm-generic/bug.h:154:3: note: in expansion of macro 'WARN'
  WARN(1, format);\
  ^~~~
   include/linux/device.h:1506:2: note: in expansion of macro 'WARN_ONCE'
 WARN_ONCE(condition, "%s %s: " format, \
 ^
   drivers/usb/dwc3/gadget.c:2375:5: note: in expansion of macro 'dev_WARN_ONCE'
dev_WARN_ONCE(dwc->dev,
^
   drivers/usb/dwc3/gadget.c:2375:19: note: each undeclared identifier is 
reported only once for each function it appears in
dev_WARN_ONCE(dwc->dev,
  ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   include/asm-generic/bug.h:154:3: note: in expansion of macro 'WARN'
  WARN(1, format);\
  ^~~~
   include/linux/device.h:1506:2: note: in expansion of macro 'WARN_ONCE'
 WARN_ONCE(condition, "%s %s: " format, \
 ^
   drivers/usb/dwc3/gadget.c:2375:5: note: in expansion of macro 'dev_WARN_ONCE'
dev_WARN_ONCE(dwc->dev,
^

vim +/dwc +2375 drivers/usb/dwc3/gadget.c

e5ba5ec833 Pratyush Anand   2013-01-14  2316  
0cdab4c202 Felipe Balbi 2018-03-27  2317  static int 
dwc3_gadget_ep_cleanup_completed_requests(struct dwc3_ep *dep,
0cdab4c202 Felipe Balbi 2018-03-27  2318const struct 
dwc3_event_depevt *event, int status)
e5ba5ec833 Pratyush Anand   2013-01-14  2319  {
31162af447 Felipe Balbi 2016-08-11  2320struct dwc3_request 
*req, *n;
e5ba5ec833 Pratyush Anand   2013-01-14  2321struct dwc3_trb 
*trb;
d6e10bf2ba Arnd Bergmann2016-09-09  2322bool
ioc = false;
e62c5bc573 Felipe Balbi 2016-10-25  2323int 
ret = 0;
e5ba5ec833 Pratyush Anand   2013-01-14  2324  
31162af447 Felipe Balbi 2016-08-11  2325
list_for_each_entry_safe(req, n, >started_list, list) {
1f512119a0 Felipe Balbi 2016-08-12  2326unsigned length;
e5b36ae2f8 Felipe Balbi 2016-08-10  2327int chain;
e5b36ae2f8 Felipe Balbi 2016-08-10  2328  
1f512119a0 Felipe Balbi 2016-08-12  2329length = 
req->request.length;
1f512119a0 Felipe Balbi 2016-08-12  2330chain = 
req->num_pending_sgs > 0;
31162af447 Felipe Balbi 2016-08-11  2331if (chain) {
1f512119a0 Felipe Balbi 2016-08-12  2332struct 
scatterlist *sg = req->sg;
31162af447 Felipe Balbi 2016-08-11  2333struct 
scatterlist *s;
1f512119a0 Felipe Balbi 2016-08-12  2334
unsigned int pending = req->num_pending_sgs;
31162af447 Felipe Balbi 2016-08-11  2335
unsigned int i;
ac7bdcc1b3 Felipe Balbi 2015-11-16  2336  
1f512119a0 Felipe Balbi 2016-08-12  2337
for_each_sg(sg, s, pending, i) {
737f1ae255 Felipe Balbi 2016-08-11  2338
trb = >trb_pool[dep->trb_dequeue];
c7de573471 Felipe Balbi 2016-07-29  2339  
7282c4ef0b Felipe Balbi 2016-10-25  2340
if (trb->ctrl & DWC3_TRB_CTRL_HWO)
7282c4ef0b Felipe Balbi 2016-10-25  2341
break;
7282c4ef0b Felipe Balbi 2016-10-25  2342  
1f512119a0 Felipe 

Re: [PATCH] USB: serial: use tty_port_register_device()

[Greg Kroah-Hartman]

On Wed, May 16, 2018 at 11:42:07AM +0200, Johan Hovold wrote:
> We already have the tty port when probing a usb-serial port so use
> tty_port_register_device() directly instead of tty_port_install() later
> to set up the port link.
> 
> This is a step towards enabling serdev for usb-serial (but we need to
> determine how to handle hotplugging first).
> 
> 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

[PATCH] USB: serial: use tty_port_register_device()

[Johan Hovold]

We already have the tty port when probing a usb-serial port so use
tty_port_register_device() directly instead of tty_port_install() later
to set up the port link.

This is a step towards enabling serdev for usb-serial (but we need to
determine how to handle hotplugging first).

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/bus.c| 3 ++-
 drivers/usb/serial/usb-serial.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
index 9e265eb92611..eb0195cf37dd 100644
--- a/drivers/usb/serial/bus.c
+++ b/drivers/usb/serial/bus.c
@@ -60,7 +60,8 @@ static int usb_serial_device_probe(struct device *dev)
}
 
minor = port->minor;
-   tty_dev = tty_register_device(usb_serial_tty_driver, minor, dev);
+   tty_dev = tty_port_register_device(>port, usb_serial_tty_driver,
+  minor, dev);
if (IS_ERR(tty_dev)) {
retval = PTR_ERR(tty_dev);
goto err_port_remove;
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 790e0cbe3da9..44ecf0e2be9d 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -192,7 +192,7 @@ static int serial_install(struct tty_driver *driver, struct 
tty_struct *tty)
if (retval)
goto error_get_interface;
 
-   retval = tty_port_install(>port, driver, tty);
+   retval = tty_standard_install(driver, tty);
if (retval)
goto error_init_termios;
 
-- 
2.17.0

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

Re: [hid:for-4.18/multitouch 7/7] drivers/hid/hid-multitouch.c:1209:9-10: WARNING: return of 0/1 in function 'mt_need_to_apply_feature' with return type bool

[Jiri Kosina]

On Fri, 27 Apr 2018, kbuild test robot wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git 
> for-4.18/multitouch
> head:   02946f4b43b11026b1a76857a33b09078b900939
> commit: 02946f4b43b11026b1a76857a33b09078b900939 [7/7] HID: multitouch: 
> implement precision touchpad latency and switches
> 
> 
> coccinelle warnings: (new ones prefixed by >>)
> 
> >> drivers/hid/hid-multitouch.c:1209:9-10: WARNING: return of 0/1 in function 
> >> 'mt_need_to_apply_feature' with return type bool
> 
> vim +/mt_need_to_apply_feature +1209 drivers/hid/hid-multitouch.c

Thanks, I've fixed that up in the branch.

-- 
Jiri Kosina
SUSE Labs

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

[balbi-usb:next 49/82] drivers/usb/dwc3/gadget.c:2375:19: error: 'dwc' undeclared; did you mean 'dwc3'?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
head:   3196f73ff8444f6b8bfce3dce1900b4eae27c324
commit: 0cdab4c202ea0dd241ddaacf1d3a8a282590cb61 [49/82] usb: dwc3: gadget: 
remove unnecessary 'dwc' parameter
config: x86_64-randconfig-i0-201819 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 0cdab4c202ea0dd241ddaacf1d3a8a282590cb61
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the balbi-usb/next HEAD 3196f73ff8444f6b8bfce3dce1900b4eae27c324 builds 
fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/bug.h:83:0,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from drivers/usb/dwc3/gadget.c:13:
   drivers/usb/dwc3/gadget.c: In function 
'dwc3_gadget_ep_cleanup_completed_requests':
>> drivers/usb/dwc3/gadget.c:2375:19: error: 'dwc' undeclared (first use in 
>> this function); did you mean 'dwc3'?
dev_WARN_ONCE(dwc->dev,
  ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   include/asm-generic/bug.h:154:3: note: in expansion of macro 'WARN'
  WARN(1, format);\
  ^~~~
   include/linux/device.h:1506:2: note: in expansion of macro 'WARN_ONCE'
 WARN_ONCE(condition, "%s %s: " format, \
 ^
   drivers/usb/dwc3/gadget.c:2375:5: note: in expansion of macro 'dev_WARN_ONCE'
dev_WARN_ONCE(dwc->dev,
^
   drivers/usb/dwc3/gadget.c:2375:19: note: each undeclared identifier is 
reported only once for each function it appears in
dev_WARN_ONCE(dwc->dev,
  ^
   include/asm-generic/bug.h:98:50: note: in definition of macro '__WARN_printf'
#define __WARN_printf(arg...) do { __warn_printk(arg); __WARN(); } while (0)
 ^~~
   include/asm-generic/bug.h:154:3: note: in expansion of macro 'WARN'
  WARN(1, format);\
  ^~~~
   include/linux/device.h:1506:2: note: in expansion of macro 'WARN_ONCE'
 WARN_ONCE(condition, "%s %s: " format, \
 ^
   drivers/usb/dwc3/gadget.c:2375:5: note: in expansion of macro 'dev_WARN_ONCE'
dev_WARN_ONCE(dwc->dev,
^

vim +2375 drivers/usb/dwc3/gadget.c

e5ba5ec833 Pratyush Anand   2013-01-14  2316  
0cdab4c202 Felipe Balbi 2018-03-27  2317  static int 
dwc3_gadget_ep_cleanup_completed_requests(struct dwc3_ep *dep,
0cdab4c202 Felipe Balbi 2018-03-27  2318const struct 
dwc3_event_depevt *event, int status)
e5ba5ec833 Pratyush Anand   2013-01-14  2319  {
31162af447 Felipe Balbi 2016-08-11  2320struct dwc3_request 
*req, *n;
e5ba5ec833 Pratyush Anand   2013-01-14  2321struct dwc3_trb 
*trb;
d6e10bf2ba Arnd Bergmann2016-09-09  2322bool
ioc = false;
e62c5bc573 Felipe Balbi 2016-10-25  2323int 
ret = 0;
e5ba5ec833 Pratyush Anand   2013-01-14  2324  
31162af447 Felipe Balbi 2016-08-11  2325
list_for_each_entry_safe(req, n, >started_list, list) {
1f512119a0 Felipe Balbi 2016-08-12  2326unsigned length;
e5b36ae2f8 Felipe Balbi 2016-08-10  2327int chain;
e5b36ae2f8 Felipe Balbi 2016-08-10  2328  
1f512119a0 Felipe Balbi 2016-08-12  2329length = 
req->request.length;
1f512119a0 Felipe Balbi 2016-08-12  2330chain = 
req->num_pending_sgs > 0;
31162af447 Felipe Balbi 2016-08-11  2331if (chain) {
1f512119a0 Felipe Balbi 2016-08-12  2332struct 
scatterlist *sg = req->sg;
31162af447 Felipe Balbi 2016-08-11  2333struct 
scatterlist *s;
1f512119a0 Felipe Balbi 2016-08-12  2334
unsigned int pending = req->num_pending_sgs;
31162af447 Felipe Balbi 2016-08-11  2335
unsigned int i;
ac7bdcc1b3 Felipe Balbi 2015-11-16  2336  
1f512119a0 Felipe Balbi 2016-08-12  2337
for_each_sg(sg, s, pending, i) {
737f1ae255 Felipe Balbi 2016-08-11  2338
trb = >trb_pool[dep->trb_dequeue];
c7de573471 Felipe Balbi 2016-07-29  2339  
7282c4ef0b Felipe Balbi 2016-10-25  2340
if (trb->ctrl & DWC3_TRB_CTRL_HWO)
7282c4ef0b Felipe Balbi 2016-10-25  2341
break;
7282c4ef0b Felipe Balbi 2016-10-25  2342  
1f512119a0 

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Geert Uytterhoeven]

Hi Florian,

Thanks for your series!
I like the effect on simplifying drivers.

On Wed, May 16, 2018 at 1:56 AM, Florian Fainelli  wrote:
> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent 
> with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.

IMHO the CONFIG_OF=n behavior of of_mdiobus_register() (which I wasn't
aware of) is inconsistent with the behavior of other of_*() functions,
which are just empty stubs.

So I'm wondering if you should do it the other way around, and let
mdiobus_register() call of_mdiobus_register() if dev->of_node exists?

This does mean mdiobus_register() should gain a struct device * parameter,
and thus changes to many more drivers are needed.

> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.

I haven't looked at the ACPI handling, but perhaps this can be moved
inside mdiobus_register() as well?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 12/14] staging: typec: tcpci: keep the not connecting cc line open

[Peter Chen]

 
> 
> While set polarity, we should keep the not connecting cc line to be open.
> 

keep the disconnected cc line open?

Peter

> Signed-off-by: Li Jun 
> ---
>  drivers/staging/typec/tcpci.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c 
> index
> 5c48810..5c0c5e3 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -185,15 +185,25 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
> enum typec_cc_polarity polarity)  {
>   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> + unsigned int reg;
>   int ret;
> 
> - ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
> -(polarity == TYPEC_POLARITY_CC2) ?
> -TCPC_TCPC_CTRL_ORIENTATION : 0);
> + /* Keep the disconnect cc line open */
> + ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, );
>   if (ret < 0)
>   return ret;
> 
> - return 0;
> + if (polarity == TYPEC_POLARITY_CC2)
> + reg |= TCPC_ROLE_CTRL_CC_OPEN <<
> TCPC_ROLE_CTRL_CC1_SHIFT;
> + else
> + reg |= TCPC_ROLE_CTRL_CC_OPEN <<
> TCPC_ROLE_CTRL_CC2_SHIFT;
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> +
> + return regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
> +(polarity == TYPEC_POLARITY_CC2) ?
> +TCPC_TCPC_CTRL_ORIENTATION : 0);
>  }
> 
>  static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
> --
> 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 v3] usb: dwc2: Fix kernel doc's warnings.

[Grigor Tovmasyan]

Hi Felipe,

I rebase this patch to your current testing/next (3196f73ff844)

BR,
Grigor.

On 5/16/2018 12:04 PM, Grigor Tovmasyan wrote:
> Added descriptions for all not described parameters.
> Fix all kernel doc's warnings.
> 
> Signed-off-by: Grigor Tovmasyan 
> ---
>   drivers/usb/dwc2/core.c  |   7 ++
>   drivers/usb/dwc2/core.h  | 170 
> ++-
>   drivers/usb/dwc2/debug.h |   2 +-
>   drivers/usb/dwc2/debugfs.c   |  19 ++---
>   drivers/usb/dwc2/gadget.c|  29 +---
>   drivers/usb/dwc2/hcd.c   |   3 +-
>   drivers/usb/dwc2/hcd.h   |  14 ++--
>   drivers/usb/dwc2/hcd_ddma.c  |   1 +
>   drivers/usb/dwc2/hcd_intr.c  |  12 +++
>   drivers/usb/dwc2/hcd_queue.c |   5 +-
>   drivers/usb/dwc2/params.c|   8 ++
>   drivers/usb/dwc2/pci.c   |   6 ++
>   12 files changed, 215 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 18a0a1771289..1c36a6a9dd63 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -419,6 +419,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
>   /**
>* dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
>* filter is enabled.
> + *
> + * @hsotg: Programming view of DWC_otg controller
>*/
>   static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
>   {
> @@ -564,6 +566,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool 
> skip_wait)
>* If a force is done, it requires a IDDIG debounce filter delay if
>* the filter is configured and enabled. We poll the current mode of
>* the controller to account for this delay.
> + *
> + * @hsotg: Programming view of DWC_otg controller
> + * @host: Host mode flag
>*/
>   void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>   {
> @@ -610,6 +615,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>* or not because the value of the connector ID status is affected by
>* the force mode. We only need to call this once during probe if
>* dr_mode == OTG.
> + *
> + * @hsotg: Programming view of DWC_otg controller
>*/
>   static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>   {
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 2438480e4496..6d304e91c20e 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
>*   and has yet to be completed (maybe due to data move, or simply
>*   awaiting an ack from the core all the data has been completed).
>* @debugfs: File entry for debugfs file for this endpoint.
> - * @lock: State lock to protect contents of endpoint.
>* @dir_in: Set to true if this endpoint is of the IN direction, which
>*  means that it is sending data to the Host.
>* @index: The index for the endpoint registers.
>* @mc: Multi Count - number of transactions per microframe
> - * @interval - Interval for periodic endpoints, in frames or microframes.
> + * @interval: Interval for periodic endpoints, in frames or microframes.
>* @name: The name array passed to the USB core.
>* @halted: Set if the endpoint has been halted.
>* @periodic: Set if this is a periodic ep, such as Interrupt
> @@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
>* @compl_desc: index of next descriptor to be completed by xFerComplete
>* @total_data: The total number of data bytes done.
>* @fifo_size: The size of the FIFO (for periodic IN endpoints)
> + * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for EP0.
>* @fifo_load: The amount of data loaded into the FIFO (periodic IN)
>* @last_load: The offset of data for the last start of request.
>* @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
> @@ -380,9 +380,12 @@ enum dwc2_ep0_state {
>*  is FS.
>*   0 - No (default)
>*   1 - Yes
> - * @ipg_isoc_en Indicates the IPG supports is enabled or disabled.
> + * @ipg_isoc_en:Indicates the IPG supports is enabled or disabled.
>*   0 - Disable (default)
>*   1 - Enable
> + * @acg_enable:  For enabling Active Clock Gating in the 
> controller
> + *   0 - No
> + *   1 - Yes
>* @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
>*   0 - No (default)
>*   1 - Yes
> @@ -552,7 +555,7 @@ struct dwc2_core_params {
>*
>* The values that are not in dwc2_core_params are documented below.
>*
> - * @op_mode Mode of Operation
> + * @op_mode: Mode of Operation
>*   0 - HNP- and SRP-Capable OTG (Host & Device)
>*   1 - SRP-Capable OTG (Host & Device)
>*   2 - Non-HNP and Non-SRP Capable OTG 

[PATCH v3] usb: dwc2: Fix kernel doc's warnings.

[Grigor Tovmasyan]

Added descriptions for all not described parameters.
Fix all kernel doc's warnings.

Signed-off-by: Grigor Tovmasyan 
---
 drivers/usb/dwc2/core.c  |   7 ++
 drivers/usb/dwc2/core.h  | 170 ++-
 drivers/usb/dwc2/debug.h |   2 +-
 drivers/usb/dwc2/debugfs.c   |  19 ++---
 drivers/usb/dwc2/gadget.c|  29 +---
 drivers/usb/dwc2/hcd.c   |   3 +-
 drivers/usb/dwc2/hcd.h   |  14 ++--
 drivers/usb/dwc2/hcd_ddma.c  |   1 +
 drivers/usb/dwc2/hcd_intr.c  |  12 +++
 drivers/usb/dwc2/hcd_queue.c |   5 +-
 drivers/usb/dwc2/params.c|   8 ++
 drivers/usb/dwc2/pci.c   |   6 ++
 12 files changed, 215 insertions(+), 61 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 18a0a1771289..1c36a6a9dd63 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -419,6 +419,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
 /**
  * dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
  * filter is enabled.
+ *
+ * @hsotg: Programming view of DWC_otg controller
  */
 static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
 {
@@ -564,6 +566,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool 
skip_wait)
  * If a force is done, it requires a IDDIG debounce filter delay if
  * the filter is configured and enabled. We poll the current mode of
  * the controller to account for this delay.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ * @host: Host mode flag
  */
 void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
 {
@@ -610,6 +615,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
  * or not because the value of the connector ID status is affected by
  * the force mode. We only need to call this once during probe if
  * dr_mode == OTG.
+ *
+ * @hsotg: Programming view of DWC_otg controller
  */
 static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
 {
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 2438480e4496..6d304e91c20e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
  *   and has yet to be completed (maybe due to data move, or simply
  *   awaiting an ack from the core all the data has been completed).
  * @debugfs: File entry for debugfs file for this endpoint.
- * @lock: State lock to protect contents of endpoint.
  * @dir_in: Set to true if this endpoint is of the IN direction, which
  *  means that it is sending data to the Host.
  * @index: The index for the endpoint registers.
  * @mc: Multi Count - number of transactions per microframe
- * @interval - Interval for periodic endpoints, in frames or microframes.
+ * @interval: Interval for periodic endpoints, in frames or microframes.
  * @name: The name array passed to the USB core.
  * @halted: Set if the endpoint has been halted.
  * @periodic: Set if this is a periodic ep, such as Interrupt
@@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
  * @compl_desc: index of next descriptor to be completed by xFerComplete
  * @total_data: The total number of data bytes done.
  * @fifo_size: The size of the FIFO (for periodic IN endpoints)
+ * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for EP0.
  * @fifo_load: The amount of data loaded into the FIFO (periodic IN)
  * @last_load: The offset of data for the last start of request.
  * @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
@@ -380,9 +380,12 @@ enum dwc2_ep0_state {
  *  is FS.
  *   0 - No (default)
  *   1 - Yes
- * @ipg_isoc_en Indicates the IPG supports is enabled or disabled.
+ * @ipg_isoc_en:Indicates the IPG supports is enabled or disabled.
  *   0 - Disable (default)
  *   1 - Enable
+ * @acg_enable:For enabling Active Clock Gating in the 
controller
+ *   0 - No
+ *   1 - Yes
  * @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
  *   0 - No (default)
  *   1 - Yes
@@ -552,7 +555,7 @@ struct dwc2_core_params {
  *
  * The values that are not in dwc2_core_params are documented below.
  *
- * @op_mode Mode of Operation
+ * @op_mode: Mode of Operation
  *   0 - HNP- and SRP-Capable OTG (Host & Device)
  *   1 - SRP-Capable OTG (Host & Device)
  *   2 - Non-HNP and Non-SRP Capable OTG (Host & Device)
@@ -560,49 +563,102 @@ struct dwc2_core_params {
  *   4 - Non-OTG Device
  *   5 - SRP-Capable Host
  *   6 - Non-OTG Host
- * @archArchitecture
+ * @arch:Architecture
  *   0 - Slave only
  *   1 - External DMA
  *   2 - Internal DMA
- 

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Greg KH]

On Tue, May 15, 2018 at 06:47:37PM +0200, Paul Menzel wrote:
> Dear Greg,
> 
> 
> As always, thank you for the prompt response.
> 
> 
> On 05/15/18 18:00, Greg KH wrote:
> > On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:
> 
> > > Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian
> > > Sid/unstable.
> > > 
> > > ```
> > > […]
> > > [0.440240] usb: port power management may be unreliable
> > > [0.441358] usbcore: registered new interface driver usb-storage
> > > [0.441367] usbcore: registered new interface driver usbserial_generic
> > > [0.441369] usbserial: USB Serial support registered for generic
> > > [0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got
> > > 0x0
> > > [0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
> > > […]
> > > ```
> > > 
> > > 1.  Are the ioremap and ucsi_acpi error related or is a separate report
> > > needed?
> > 
> > The ioremap error is what causes ucsi_acpi to fail the probe call (-12
> > is "out of memory".)
> > 
> > > 2.  Do you know the reason for the ucsi_acpi error?
> > 
> > the call to ioremap failed.
> > 
> > Does this device really have a working typec connector?
> 
> Just to avoid misunderstandings, no device was connected to the laptop
> during my test.
> 
> But, from other boots, the Dell docking station TB16 kind of works with it,
> so I’d say the USB Type-C connector is working.

Ok, good, this might just be the acpi tables not set up properly for
this type of connection.  Odd that the tables show it should work,
Heikki should know more about this.

> > Does normal USB devices work with it?
> 
> Sorry for being ignorant, but could you please tell me what normal USB
> devices are?

If you plug a USB typeC device into this port, does it work?  A docking
station is a little bit "different" in that it usually uses the PCIe
connection, not the USB connectors.  Or at least that's how my Dell
docking station works last time I tried it[1]

thanks,

greg k-h

[1] When the power supply for the docking station is bigger than the
laptop's power supply, you begin to wonder what is in that thing and
stop using it after a while...
--
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 01/14] dt-bindings: connector: add properties for typec

[Peter Chen]

  
> Add bingdings supported by current typec driver, so user can pass all those
> properties via dt.
> 

%s/bingdings/bindings

Peter
--
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 v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Antoine Tenart]

Hi Florian,

On Tue, May 15, 2018 at 04:56:19PM -0700, Florian Fainelli wrote:
> A number of drivers have the following pattern:
> 
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
> 
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/dsa/bcm_sf2.c |  8 ++--
>  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>  drivers/net/ethernet/marvell/mvmdio.c |  5 +

For mvmdio,
Reviewed-by: Antoine Tenart 

Thanks!
Antoine

>  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
>  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
>  drivers/net/phy/mdio-gpio.c   |  6 +-
>  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>  drivers/net/usb/lan78xx.c |  7 ++-
>  11 files changed, 20 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index ac621f44237a..02e8982519ce 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
>   priv->slave_mii_bus->parent = ds->dev->parent;
>   priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
>  
> - if (dn)
> - err = of_mdiobus_register(priv->slave_mii_bus, dn);
> - else
> - err = mdiobus_register(priv->slave_mii_bus);
> -
> - if (err)
> + err = of_mdiobus_register(priv->slave_mii_bus, dn);
> + if (err && dn)
>   of_node_put(dn);
>  
>   return err;
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c 
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index b23c11d9f4b2..2bb3f03ee1cb 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct 
> mv88e6xxx_chip *chip,
>   return err;
>   }
>  
> - if (np)
> - err = of_mdiobus_register(bus, np);
> - else
> - err = mdiobus_register(bus);
> + err = of_mdiobus_register(bus, np);
>   if (err) {
>   dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
>   mv88e6xxx_g2_irq_mdio_free(chip, bus);
> diff --git a/drivers/net/ethernet/cadence/macb_main.c 
> b/drivers/net/ethernet/cadence/macb_main.c
> index b4c9268100bb..3e93df5d4e3b 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
>   dev_set_drvdata(>dev->dev, bp->mii_bus);
>  
>   np = bp->pdev->dev.of_node;
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
>  
> - if (np) {
> - err = of_mdiobus_register(bp->mii_bus, np);
> - } else {
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> - err = mdiobus_register(bp->mii_bus);
> - }
> -
> + err = of_mdiobus_register(bp->mii_bus, np);
>   if (err)
>   goto err_out_free_mdiobus;
>  
> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc8eb5b..f3e43db0d6cb 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
> *pdev)
>   fep->mii_bus->parent = >dev;
>  
>   node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> - if (node) {
> - err = of_mdiobus_register(fep->mii_bus, node);
> + err = of_mdiobus_register(fep->mii_bus, node);
> + if (node)
>   of_node_put(node);
> - } else {
> - err = mdiobus_register(fep->mii_bus);
> - }
> -
>   if (err)
>   goto err_out_free_mdiobus;
>  
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
> b/drivers/net/ethernet/marvell/mvmdio.c
> index 0495487f7b42..c5dac6bd2be4 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
>   goto out_mdio;
>   }
>  
> - if (pdev->dev.of_node)
> - ret = of_mdiobus_register(bus, pdev->dev.of_node);
> - else
> - ret = mdiobus_register(bus);
> + ret = of_mdiobus_register(bus, pdev->dev.of_node);
>   if (ret < 0) {
>   dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
>   goto out_mdio;
> diff --git 

Re: [PATCH V2 2/4] usb: gadget: configfs: Create control_config group

[Jerry Zhang]

Sorry I must have messed up in-reply-to. Patch 1 was sent here:
https://www.spinics.net/lists/linux-usb/msg167994.html. It didn't need a V2
and so I didn't resend it.

--Jerry
On Tue, May 15, 2018 at 11:15 PM Felipe Balbi  wrote:

> Jerry Zhang  writes:

> > Control_config is a group under gadget that acts
> > as a normal config group, except it does not
> > appear in cdev->configs.
> >
> > Functions that have exactly zero descriptors can
> > be linked into control_config. These functions
> > are bound and unbound with the rest of the gadget,
> > but are never enabled. Also, functions with zero
> > descriptors cannot be used in real configs.
> >
> > Create configfs_setup(), which will first attempt
> > composite setup. If that fails, it will go through
> > functions in control_config and use req_match to
> > find and deliver the request to a function that can
> > handle it.
> >
> > This allows the user to create a functionfs instance
> > dedicated to handling non-standard control requests
> > no matter what functions or configurations are
> > currently active.
> >
> > Signed-off-by: Jerry Zhang 

> I didn't get patch 1

> --
> balbi
--
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 2/4] usb: gadget: configfs: Create control_config group

[Felipe Balbi]

Jerry Zhang  writes:

> Control_config is a group under gadget that acts
> as a normal config group, except it does not
> appear in cdev->configs.
>
> Functions that have exactly zero descriptors can
> be linked into control_config. These functions
> are bound and unbound with the rest of the gadget,
> but are never enabled. Also, functions with zero
> descriptors cannot be used in real configs.
>
> Create configfs_setup(), which will first attempt
> composite setup. If that fails, it will go through
> functions in control_config and use req_match to
> find and deliver the request to a function that can
> handle it.
>
> This allows the user to create a functionfs instance
> dedicated to handling non-standard control requests
> no matter what functions or configurations are
> currently active.
>
> Signed-off-by: Jerry Zhang 

I didn't get patch 1

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: xhci: force all memory allocations to node

[Greg Kroah-Hartman]

On Tue, May 15, 2018 at 04:51:53PM -0400, Adam Wallis wrote:
> On 5/15/2018 11:07 AM, Greg Kroah-Hartman wrote:
> > On Tue, May 15, 2018 at 09:53:57AM -0400, Adam Wallis wrote:
> > Does this really do anything?  Given the speed of USB3 at the moment,
> > does fixing the memory to the node the PCI device is on show any
> > measurable speedups?  Last I remember about NUMA systems, it wasn't
> > always a win depending on where the irq came in from, right?
> > 
> > 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
> > 
> 
> I was getting really inconsistent throughput speeds on a system I was testing
> with NUMA nodes. Using an SMMU in identity mode, I was able to track down 
> where
> the performance deltas were coming from...Some of the rings were going to the
> "wrong" node.
> 
> Yes, it's possible to handle your IRQs with CPUs on the wrong NUMA node...but 
> I
> would argue that it's always best to have the rings for USB controller X as
> close to controller X if possible. Users can then properly constrain IRQs, and
> even kernel threads to the right Domain if they so desire.
> 
> After setting the IRQ affinity to the right node AND applying this patch, I
> started getting much more reliable (and faster) results.

Ok, fair enough, I was hoping that "modern" systems would have better
NUMA memory interconnects.  I guess that isn't the case still :(

thanks,

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

Re: Renesas uPD720202 USB 3.0

[Greg KH]

On Wed, May 16, 2018 at 07:16:26AM +0200, Christian Brauns wrote:
> Hi,
> 
> I'm not used to writing bug-reports.
> 
> From: https://bbs.archlinux.org/viewtopic.php?id=236806, I got adviced to do 
> that.
> 
> I have an usb 3 controller laptop expresscard
> Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)
> using that in a Lenovo X220 which does not work with the latest kernels.
> In a Lenovo R400 it works.
> 
> After some testing, I came to the result, that
> it was still working in kernel 4.12.7, and stopped working in kernel 4.12.8.
> 
> And with some advice and further testing it produces the same (working) 
> results in
> kernel 4.12.8 with 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c reverted.
> 
> (
> 
> git checkout v4.12.8
> git revert 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c #revert the noted commit
> git cherry-pick 854e55ad289efe7991f0ada85d5846f5afb9 #cherry-pick a 
> commit needed to build with gcc 8
> git cherry-pick ad343a98e74e85aa91d844310e797f96fee6983b
> )
> 
> There is a post from someone else regarding this controller at:
> https://unix.stackexchange.com/questions/440741/install-usb-3-0-express-card-under-linux-arch-linux-tried-adding-kernel-param
> who made a bug report here:
> https://bugzilla.kernel.org/show_bug.cgi?id=199627
> 

I don't understand, the 4.12.y kernel tree is long end-of-life, why are
you using that one?  Does 4.16 work?  4.14.y?

Why are you using gcc8 on 4.12.y anyway, that is not going to work for
you very well, it barely, if at all, works on Linus's latest tree.

thanks,

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

Re: [PATCH v2] usb: dwc2: Fix kernel doc's warnings.

[Felipe Balbi]

Minas Harutyunyan  writes:

> Hi Filipe,
>
> Please pickup this patch to your testing/next.

wish I could:

checking file drivers/usb/dwc2/core.c
checking file drivers/usb/dwc2/core.h
Hunk #2 succeeded at 181 with fuzz 1.
Hunk #3 FAILED at 380.
Hunk #4 succeeded at 552 (offset 4 lines).
Hunk #5 FAILED at 556.
Hunk #6 succeeded at 653 (offset 11 lines).
Hunk #7 succeeded at 690 (offset 11 lines).
Hunk #8 succeeded at 714 (offset 11 lines).
Hunk #9 succeeded at 817 (offset 11 lines).
Hunk #10 succeeded at 826 with fuzz 2 (offset 11 lines).
Hunk #11 succeeded at 852 (offset 14 lines).
Hunk #12 succeeded at 879 (offset 14 lines).
Hunk #13 succeeded at 931 (offset 12 lines).
Hunk #14 succeeded at 955 (offset 12 lines).
Hunk #15 succeeded at 969 (offset 12 lines).
2 out of 15 hunks FAILED
checking file drivers/usb/dwc2/debug.h
checking file drivers/usb/dwc2/debugfs.c
checking file drivers/usb/dwc2/gadget.c
Hunk #7 succeeded at 2430 (offset -17 lines).
Hunk #8 succeeded at 2730 (offset -15 lines).
Hunk #9 succeeded at 3190 (offset -14 lines).
Hunk #10 succeeded at 4297 (offset 9 lines).
Hunk #11 succeeded at 4448 (offset 9 lines).
Hunk #12 succeeded at 4522 (offset 9 lines).
Hunk #13 succeeded at 4578 (offset 9 lines).
Hunk #14 succeeded at 4630 (offset 9 lines).
Hunk #15 succeeded at 4728 (offset 9 lines).
Hunk #16 succeeded at 5010 (offset 9 lines).
checking file drivers/usb/dwc2/hcd.c
checking file drivers/usb/dwc2/hcd.h
checking file drivers/usb/dwc2/hcd_ddma.c
checking file drivers/usb/dwc2/hcd_intr.c
checking file drivers/usb/dwc2/hcd_queue.c
checking file drivers/usb/dwc2/params.c
Hunk #2 succeeded at 342 (offset 1 line).
Hunk #3 succeeded at 695 (offset 2 lines).
checking file drivers/usb/dwc2/pci.c

-- 
balbi


signature.asc
Description: PGP signature