Merge tag 'phy-for-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next

Kishon writes:

phy: for 4.13

 *) Group phy drivers into vendor specific directories
 *) Add USB3 PHY driver for Renesas R-Car Gen3
 *) Add USB2 PHY driver for Meson GXL and GXM SoCs
 *) Add USB DRD PHY driver for Broadcom Northstar2
 *) Add USB PHY driver for CPCAP PMIC USB
 *) Make phy-meson8b-usb2 driver support USB PHY on Meson8
 *) Make phy-tusb1210 driver support TUSB1211
 *) Make phy-rockchip-inno-usb2 driver support usb2-phy in rk3228 SoCs
 *) Make phy-brcm-sata driver support for stingray SATA phy
 *) Make bcm-ns-usb3 as a MDIO driver
 *) Make rockchip-inno-usb2 support two host ports
 *) Implement ->set_mode() callback in phy-tusb1210
 *) Minor fixes in phy drivers
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

As USB 3.0 PHY is attached to the MDIO bus this module should provide a
MDIO driver and use a proper bus layer. This is a proper (cleaner)
solution which doesn't require code to know this specific MDIO bus
details. It also allows reusing the driver with other MDIO buses.

For now keep platform device support in place. We may consider dropping
it once MDIO bindings gets used "everywhere".
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Thanks to work done by Broadcom explaining their USB 3.0 PHY details we
know it's attached to the MDIO bus. Use this knowledge to update the
binding: make it a subnode to the MDIO bus and rework way of specifying
required registers. This will describe hardware more precisely and will
allow to support (describe) more devices attached to the MDIO.

While compatibility strings remain the same there isn't a direct
conflict (compatibility breakage) for the binding. Originally it wasn't
supposed to be used for MDIO subnode so this change should be safe
unless some operating system was probing MDIO subnodes as standalone
devices.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

When we finally start using MDIO layer then bus initialization will be
handled in a separated driver. It means our code handling this has to be
used for the platform driver only.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Our current writing function accesses PHY directly bypassing MDIO layer.

The aim is to extend this module to also behave as MDIO driver. This
will require using different writing function which can be handled
cleanly by having an extra pointer like this.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Move MDIO specific code to the writing helper function. This makes init
code a bit more generic and doesn't require it to track what happens
after every write.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

This patch adds support for stingray SATA phy in the
SATA BRCM phy driver.
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Update BRCM SATA phy dt-binding documentation for stingray.
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Rob Herring <rob@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
is missing return statement as noted by Colin Ian King
<colin.king@canonical.com>. If the optional pins are not configured,
we just want to return early and not attempt to configure the pins.

Fixes: 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

finish_td() could be called with a skip option to bypass most of the
function and only call xhci_td_cleanup() at the end.

Remove this skip option and call xhci_td_cleanup() directly instead
when needed

No functional changes
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Get rid of stopped_stream member in virtual endpoint structure as
it is only used in one case when cleaning a halted endpoint.

Pass it as function parameter instead.

No functional changes
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Most transfer events have a TRB pointer indicating which TRB caused
the event.
In the case of streams, transfer events such as
USB Transaction error may have its TRB pointer set to zero.

driver won't know which stream or what TRB on that stream caused
the error, but it can issue a soft reset to recover the transfer.
A soft reset will clear the host side halt of the endpoint without
clearing Data toggle or sequence number, and let the transfer
continue from where it halted.

see xhci section 4.12 streams and 4.6.8.2 soft retry.

USB Transaction errors with a zero TRB pointer are seen with
UAS usb devices.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add soft reset support to cleanup_halted_endpoint().
using soft reset will prevent it from setting a new dequeue pointer to
start the transfer from. Let it continue where it halted.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci supports soft retry recovery when the host halted the host side of an
endopint but the connected USB device is not aware of the halt.

In this case xhci needs to issue a reset endopint command  with a TSP
(Transfer State Preserve) flag set which preserves the Data toggle
and Sequence number of the endpoint.

This feature is needed to handle a few special transfer event types
such as USB Transaction error that don't always point to a causing TRB.

see xhci 4.6.8.1 for more details
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Parse the transfer event first, and remove duplicate debugging
code.

Reorder completion codes according to endpoint state.

No functional changes

We are not handling some transfer events correcly and need to
clean up this before fixing it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Anurag Kumar Vulisha reported several issues with xhci endpoint
ring caching.

31 Rings are cached per device before a ring is freed.
These cached rings are not used as default if a new ring is needed.
They are only used if the driver fails to allocate memory for a ring.

The current ring cache is more a reason to why we run out memory than a
help when we actually do so.

Anurag Kumar Vulisha tried to use cached rings as a first option and
found new issues with cached ring initialization.
Cached rings were first zeroed and then manually reinitialized with link
trbs etc, but forgetting to set some important bits like cycle toggle bit.

Remove the ring cache completely as it's a faulty premature optimization
eating memory
Reported-by: Anurag Kumar Vulisha <anuragku@xilinx.com>
Tested-by: Anurag Kumar Vulisha <anuragku@xilinx.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The original motivation for disabling/enabling Link PM at device
suspend/resume was to force link state to go via U0 before suspend sets
the link state to U3. Going directly from U2 to U3 is not allowed.

Disabling LPM will forced the link state to U0, but will send a lot of
Set port feature requests for evert suspend and resume.

This is not needed as Hub hardware will take care of going via U0
when a U2 -> U3 transition is requested [1]

[1] USB 3.1 specification section 10.16.2.10 Set Port Feature:

"If the value is 3, then host software wants to selectively suspend the
device connected to this port. The hub shall transition the link to U3
from any of the other U states using allowed link state transitions.
If the port is not already in the U0 state, then it shall transition the
port to the U0 state and then initiate the transition to U3.
While this state is active, the hub does not propagate downstream-directed
traffic to this port, but the hub will respond to resume signaling from the
port"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the new helper for reusing a device-tree node of another device
instead of managing the node references explicitly.

This also makes sure that the new of_node_reuse flag is set if the
device is ever reprobed, something which specifically now avoids driver
core from attempting to claim any pinmux resources already claimed by
the parent device.

Fixes: ec4664b3 ("thermal: max77620: Add thermal driver for reporting junction temp")
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The thermal child device reuses the parent MFD-device device-tree node
when registering a thermal zone, but did not take a reference to the
node.

This leads to a reference imbalance, and potential use-after-free, when
the node reference is dropped by the platform-bus device destructor
(once for the child and later again for the parent).

Fix this by dropping any reference already held to a device-tree node
and getting a reference to the parent's node which will be balanced on
reprobe or on platform-device release, whichever comes first.

Note that simply clearing the of_node pointer on probe errors and on
driver unbind would not allow the use of device-managed resources as
specifically thermal_zone_of_sensor_unregister() claims that a valid
device-tree node pointer is needed during deregistration (even if it
currently does not seem to use it).

Fixes: ec4664b3 ("thermal: max77620: Add thermal driver for reporting junction temp")
Cc: stable <stable@vger.kernel.org>     # 4.9
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In an attempt to work around a pinmux over-allocation issue in driver
core, commit dc5878ab ("usb: core: move root hub's device node
assignment after it is added to bus") moved the device-tree node
assignment until after the root hub had been registered.

This not only makes the device-tree node unavailable to the usb driver
during probe, but also prevents the of_node from being linked to in
sysfs and causes a race with user-space for the (recently added) devspec
attribute.

Use the new device_set_of_node_from_dev() helper to reuse the node of
the sysdev device, something which now prevents driver core from trying
to reclaim any pinctrl pins during probe.

Fixes: dc5878ab ("usb: core: move root hub's device node assignment after it is added to bus")
Fixes: 51fa9147 ("usb/core: Added devspec sysfs entry for devices behind the usb hub")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit ab78029e ("drivers/pinctrl: grab default handles from device
core") added automatic pin-control management to driver core by looking
up and setting any default pinctrl state found in device tree while a
device is being probed.

This obviously runs into problems as soon as device-tree nodes are
reused for child devices which are later also probed as pins would
already have been claimed by the ancestor device.

For example if a USB host controller claims a pin, its root hub would
consequently fail to probe when its device-tree node is set to the node
of the controller:

    pinctrl-single 48002030.pinmux: pin PIN204 already requested by 48064800.ehci; cannot claim for usb1
    pinctrl-single 48002030.pinmux: pin-204 (usb1) status -22
    pinctrl-single 48002030.pinmux: could not request pin 204 (PIN204) from group usb_dbg_pins  on device pinctrl-single
    usb usb1: Error applying setting, reverse things back
    usb: probe of usb1 failed with error -22

Fix this by checking the new of_node_reused flag and skipping automatic
pinctrl configuration during probe if set.

Note that the flag is checked in driver core rather than in pinctrl
(e.g. in pinctrl_dt_to_map()) which would specifically have prevented
intentional use of a parent's pinctrl properties by a child device
(should such a need ever arise).

Fixes: ab78029e ("drivers/pinctrl: grab default handles from device core")
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a helper function to be used when reusing the device-tree node of
another device.

It is fairly common for drivers to reuse the device-tree node of a
parent (or other ancestor) device when creating class or bus devices
(e.g. gpio chips, i2c adapters, iio chips, spi masters, serdev, phys,
usb root hubs). But reusing a device-tree node may cause problems if the
new device is later probed as for example driver core would currently
attempt to reinitialise an already active associated pinmux
configuration.

Other potential issues include the platform-bus code unconditionally
dropping the device-tree node reference in its device destructor,
reinitialisation of other bus-managed resources such as clocks, and the
recently added DMA-setup in driver core.

Note that for most examples above this is currently not an issue as the
devices are never probed, but this is a problem for the USB bus which
has recently gained device-tree support. This was discovered and
worked-around in a rather ad-hoc fashion by commit dc5878ab ("usb:
core: move root hub's device node assignment after it is added to bus")
by not setting the of_node pointer until after the root-hub device has
been registered.

Instead we can allow devices to reuse a device-tree node by setting a
flag in their struct device that can be used by core, bus and driver
code to avoid resources from being over-allocated.

Note that the helper also grabs an extra reference to the device node,
which specifically balances the unconditional put in the platform-device
destructor.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Document that the child-node lookup helper takes a reference to the
device-tree node which needs to be dropped after use.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure to release any OF device-node reference taken when creating
the USB device.

Note that we currently do not hold a reference to the root hub
device-tree node (i.e. the parent controller node).

Fixes: 69bec725 ("USB: core: let USB device know device node")
Cc: stable <stable@vger.kernel.org>	# v4.6
Acked-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use sysfs_match_string() helper instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Trace_printk() was used to log debug messages in xhci-dbc.c where
printk() isn't feasible. As there should not be a single caller to
trace_printk() in normal kernels, replace them with empty functions.

Cc: Vlastimil Babka <vbabka.lkml@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Each vhci has 2*VHCI_HC_PORTS ports, in which VHCI_HC_PORTS
ports are HighSpeed (or below), and VHCI_HC_PORTS are SuperSpeed.
This new macro VHCI_PORTS reflects this configuration.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

As USB3 has (slightly) different bit meanings in the port
status. Add a new status bit array for USB3.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

With this patch, USB_SPEED_SUPER is a valid speed when attaching
a USB3 SuperSpeed device.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds a USB3 HCD to an existing USB2 HCD and provides
the support of SuperSpeed, in case the device can only be enumerated
with SuperSpeed.

The bulk of the added code in usb3_bos_desc and hub_control to support
SuperSpeed is borrowed from the commit 1cd8fd28 ("usb: gadget:
dummy_hcd: add SuperSpeed support").

With this patch, each vhci will have VHCI_HC_PORTS HighSpeed ports
and VHCI_HC_PORTS SuperSpeed ports.
Suggested-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch enables the new vhci structure. Its lock protects
both the USB2 hub and the shared USB3 hub.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A vhci struct is added as the platform-specific data to the vhci
platform device, in order to get the vhci by its platform device.
This is done in vhci_hcd_init().
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Every VHCI is a platform device, so move the platform_device struct
into the VHCI struct.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to support SuperSpeed devices, a USB3 HCD is added to
share the USB2 HCD. As a result, a VHCI is composed of two
vhci_hcds associated with the two HCDs respectively. So we add
another level of abstraction, vhci, and thus this vhci structure.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

These helper function names are renamed to have their full struct
names to avoid confusion:

 - hcd_to_vhci() -> hcd_to_vhci_hcd()
 - vhci_to_hcd() -> vhci_hcd_to_hcd()
 - vdev_to_vhci() -> vdev_to_vhci_hcd()
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The current definition is wrong. This breaks my upcoming
Aspeed virtual hub driver.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In parse_status(), all nports number of idev's are initiated to
0 by memset(), it is simply wrong, because parse_status() reads
the status sys file one by one, therefore, it can only update the
according vhci_driver->idev's for it to parse.
Reviewed-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit 0775a9cb ("usbip: vhci extension: modifications
to vhci driver") introduced multiple controllers, but the status
of the ports are only extracted from the first status file, fix it.
Reviewed-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>