- 29 Apr, 2019 4 commits
-
-
Johan Hovold authored
Fix two long-standing bugs which could potentially lead to memory corruption or leave the port throttled until it is reopened (on weakly ordered systems), respectively, when read-URB completion races with unthrottle(). First, the URB must not be marked as free before processing is complete to prevent it from being submitted by unthrottle() on another CPU. CPU 1 CPU 2 ================ ================ complete() unthrottle() process_urb(); smp_mb__before_atomic(); set_bit(i, free); if (test_and_clear_bit(i, free)) submit_urb(); Second, the URB must be marked as free before checking the throttled flag to prevent unthrottle() on another CPU from failing to observe that the URB needs to be submitted if complete() sees that the throttled flag is set. CPU 1 CPU 2 ================ ================ complete() unthrottle() set_bit(i, free); throttled = 0; smp_mb__after_atomic(); smp_mb(); if (throttled) if (test_and_clear_bit(i, free)) return; submit_urb(); Note that test_and_clear_bit() only implies barriers when the test is successful. To handle the case where the URB is still in use an explicit barrier needs to be added to unthrottle() for the second race condition. Also note that the first race was fixed by 36e59e0d ("cdc-acm: fix race between callback and unthrottle") back in 2015, but the bug was reintroduced a year later. Fixes: 1aba579f ("cdc-acm: handle read pipe errors") Fixes: 088c64f8 ("USB: cdc-acm: re-write read processing") Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei Yongjun authored
Add the missing unlock before return from function ccg_cmd_write_flash_row() in the error handling case. Fixes: 5c9ae5a8 ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Biju Das authored
Document support for RZ/G1C (R8A77470) SoC. Signed-off-by:
Biju Das <biju.das@bp.renesas.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Fabrizio Castro authored
Document RZ/G2E (R8A774C0) SoC bindings. Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
-
- 27 Apr, 2019 5 commits
-
-
Mathias Nyman authored
The configure endpoint command configures all the endpoints that were flagged to be added or dropped. To know the content of each of the added endpoints we need to add tracing to the .add_endpoint() callback, just after initializing all the context values. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
Add tracing for the add and drop bits in the input control context used in Address device, configure endpoint, evaluate context commands. The add and drop bits tell xHC which enpoints are added and dropped. Signed-off-by:
-
Mathias Nyman authored
Improve port related dynamic debugging by printing out the bus number, port number and port status register content each time there is a port related debug messages. Use the same port numbering method as usbcore to simplify debugging. i.e. starting with port number 1. Signed-off-by:
-
Nicolas Saenz Julienne authored
Immediate data transfers (IDT) allow the HCD to copy small chunks of data (up to 8bytes) directly into its output transfer TRBs. This avoids the somewhat expensive DMA mappings that are performed by default on most URBs submissions. In the case an URB was suitable for IDT. The data is directly copied into the "Data Buffer Pointer" region of the TRB and the IDT flag is set. Instead of triggering memory accesses the HC will use the data directly. The implementation could cover all kind of output endpoints. Yet Isochronous endpoints are bypassed as I was unable to find one that matched IDT's constraints. As we try to bypass the default DMA mappings on URB buffers we'd need to find a Isochronous device with an urb->transfer_buffer_length <= 8 bytes. The implementation takes into account that the 8 byte buffers provided by the URB will never cross a 64KB boundary. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Serge Semin authored
It's pointless to scan the hub' i2c-bus segment if GPIOs aren't supported by the system, since no GPIO-driven reset could be cleared by the driver then. Moreover if CONFIG_GPIOLIB is disabled the gpio_chip structure definition won't be available, which causes the incomplete type pointer dereference compilation error. In order to fix this we need to create an empty usb251x_check_gpio_chip() method returning zero, so the driver would skip the i2c-bus segment checking and proceed with further probing in this case. Fixes: 6e3c8beb ("usb: usb251xb: Lock i2c-bus segment the hub resides") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
-
- 25 Apr, 2019 12 commits
-
-
Raul E Rangel authored
This change will send an OFFLINE event to udev with the ERROR=DEAD environment variable set when the HC dies. By notifying user space the appropriate policies can be applied. i.e., * Collect error logs. * Notify the user that USB is no longer functional. * Perform a graceful reboot. Reported-by:
Raul E Rangel <rrangel@chromium.org> Signed-off-by:
-
Ajay Gupta authored
Latest NVIDIA GPUs support VirtualLink device. Since USBIF has not assigned a Standard ID (SID) for VirtualLink so using NVIDA VID 0x955 as SVID. Signed-off-by:
Ajay Gupta <ajayg@nvidia.com> Signed-off-by:
-
Ajay Gupta authored
VirtualLink standard extends the DisplayPort Alt Mode by utilizing also the USB 2 pins on the USB Type-C connector. It uses the same messages as DisplayPort, but not the DP SVID. At the time of writing, USB IF has not assigned a Standard ID (SID) for VirtualLink, so the manufacturers of VirtualLink adapters use their Vendor IDs as the SVID. Since the SVID specific communication is exactly the same as with DisplayPort alternate mode, there is no need to implement separate driver for VirtualLink. We'll handle the current VirtualLink adapters with probe drivers, and once there is SVID assigned for it, we add it to the displayport alt mode driver. To support probing drivers, exporting the probe and remove functions, and also changing the DP_HEADER helper macro to use the SVID of the alternate mode device instead of the DisplayPort alt mode SVID. Suggested-by:
-
Heikki Krogerus authored
This makes it possible to bind a driver to a DisplayPort alt mode adapter devices. The driver attempts to cope with the limitations of UCSI by "emulating" behaviour and attempting to guess things when ever possible in order to satisfy the requirements the standard DisplayPort alt mode driver has. Tested-by:
-
Heikki Krogerus authored
With UCSI the alternate modes, just like everything else related to USB Type-C connectors, are handled in firmware. The operating system can see the status and is allowed to request certain things, for example entering and exiting the modes, but the support for alternate modes is very limited in UCSI. The feature is also optional, which means that even when the platform supports alternate modes, the operating system may not be even made aware of them. UCSI does not support direct VDM reading or writing. Instead, alternate modes can be entered and exited using a single custom command which takes also an optional SVID specific configuration value as parameter. That means every supported alternate mode has to be handled separately in UCSI driver. This commit does not include support for any specific alternate mode. The discovered alternate modes are now registered, but binding a driver to an alternate mode will not be possible until support for that alternate mode is added to the UCSI driver. Tested-by:
-
Ajay Gupta authored
CCGx has two copies of the firmware in addition to the bootloader. If the device is running FW1, FW2 can be updated with the new version. Dual firmware mode allows the CCG device to stay in a PD contract and support USB PD and Type-C functionality while a firmware update is in progress. First we read the currently flashed firmware version of both primary and secondary firmware and then compare it with version of firmware file to determine if flashing is required. Command framework is added to support sending commands to CCGx controller. We wait for response after sending the command and then read the response from RAB_RESPONSE register. Below commands are supported, - ENTER_FLASHING - RESET - PDPORT_ENABLE - JUMP_TO_BOOT - FLASH_ROW_RW - VALIDATE_FW Command specific mutex lock is also added to sync between driver and user threads. PD port number information is added which is required while sending PD_PORT_ENABLE command Signed-off-by:
-
Ajay Gupta authored
Adding device property "ccgx,firmware-build" for the CCGx device, so the CCGx driver knows which firmware binary to use for a specific vendor. Suggested-by:
-
Ajay Gupta authored
Function is to get the details of ccg firmware and device version. It will be useful in debugging and also during firmware update. Signed-off-by:
-
Serge Semin authored
SMBus slave configuration is activated by CFG_SEL[1:0]=0x1 pins state. This is the mode the hub is supposed to be to let this driver work correctly. But a race condition might happen right after reset is cleared due to CFG_SEL[0] pin being multiplexed with SMBus SCL function. In case if the reset pin is handled by a i2c GPIO expander, which is also placed at the same i2c-bus segment as the usb251x SMB-interface connected to, then the hub reset clearance might cause the CFG_SEL[0] being latched in unpredictable state. So sometimes the hub configuration mode might be 0x1 (as expected), but sometimes being 0x0, which doesn't imply to have the hub SMBus-slave interface activated and consequently causes this driver failure. In order to fix the problem we must make sure the GPIO-reset chip doesn't reside the same i2c-bus segment as the SMBus-interface of the hub. If it doesn't, we can safely block the segment for the time the reset is cleared to prevent anyone generating a traffic at the i2c-bus SCL lane connected to the CFG_SEL[0] pin. But if it does, nothing we can do, so just return an error. If we locked the i2c-bus segment and tried to communicate with the GPIO-expander, it would cause a deadlock. If we didn't lock the i2c-bus segment, it would randomly cause the CFG_SEL[0] bit flip. Signed-off-by:
-
Marc Gonzalez authored
Keep EXTCON support optional, as some platforms do not need it. Do the same for USB_DWC3_OMAP while we're at it. Fixes: 3def4031 ("usb: dwc3: add EXTCON dependency for qcom") Signed-off-by:
Marc Gonzalez <marc.w.gonzalez@free.fr> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Dan Carpenter authored
There is an extra space character before the return statement. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'phy-for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next Kishon writes: phy: for 5.2 *) Add a new *release* phy_ops invoked when the consumer relinquishes PHY that can be used to undo the operation performed in xlate *) Add new driver to support USB2 PHY and shared USB3 + PCIE PHY in Amlogic G12A SoC Family. *) Add new driver to support for Broadcom's Stingray USB PHY (Type 1 has one super speed PHY and one high speed PHY, Type 2 has one high speed PHY) *) Add new driver to support USB PHY in hi3660 SoC of Hisilicon *) Add new driver to support UFS M-PHY in MediaTek SoC *) Add new driver to support XUSB pad controller in Tegra186 SoCs *) Add new driver to support SERDES in TI's AM654 platform *) Add support for generation 2 USB2 PHY and gneration 3 USB2 PHY in r8a77470 to phy-rcar-gen2.c and phy-rcar-gen3-usb2.c respectively *) Add support for PCIe QMP PHY support in msm8998 to phy-qcom-qmp.c *) Add support for SERDES6G in phy-ocelot-serdes.c *) Add support to set drive impedance from device tree in phy-rockchip-emmc.c *) Add support to power up/down the VBUS voltage rail in phy-fsl-imx8mq-usb.c *) Add support to shut off regulators that power UFS during system suspend *) Re-design phy-rcar-gen3-usb2.c to create separate PHY instances for each channel which helps to enable/disable interrupts for each instance independently *) Fix PCIe power up sequence to follow the TRM in order to ensure the DPLL & PHY operates correctly over the entire temperature range. *) Use devm_clk_get_optional to get optional clocks instead of adding custom error checks Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> * tag 'phy-for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy: (51 commits) dt-bindings: phy-qcom-qmp: Tweak qcom,msm8998-qmp-ufs-phy dt-bindings: phy-qcom-qmp: Add qcom,msm8998-qmp-pcie-phy phy: Add usb phy support for hi3660 Soc of Hisilicon dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY scsi: phy: mediatek: fix typo in author's email address phy: ocelot-serdes: Add support for SERDES6G muxing phy: fsl-imx8mq-usb: add support for VBUS power control dt-bindings: phy-imx8mq-usb: add optional vbus supply regulator phy: qcom-qmp: Add msm8998 PCIe QMP PHY support phy: ti: am654-serdes: Support all clksel values phy: ti: Add a new SERDES driver for TI's AM654x SoC dt-bindings: phy: ti: Add dt binding documentation for SERDES in AM654x SoC phy: core: Invoke pm_runtime_get_*/pm_runtime_put_* before invoking reset callback phy: core: Add *release* phy_ops invoked when the consumer relinquishes PHY phy: phy-meson-gxl-usb2: get optional clock by devm_clk_get_optional() phy: socionext: get optional clock by devm_clk_get_optional() phy: qcom-qusb2: get optional clock by devm_clk_get_optional() phy: phy-mtk-tphy: get optional clock by devm_clk_get_optional() phy: renesas: rcar-gen3-usb2: enable/disable independent irqs phy: renesas: rcar-gen3-usb2: Use pdev's device pointer on dev_vdbg() ...
-
- 22 Apr, 2019 1 commit
-
-
Marc Gonzalez authored
Fixup MSM8998 UFS binding now that Evan's reset series has landed. https://lore.kernel.org/lkml/20190321171800.104681-1-evgreen@chromium.org/Signed-off-by:
-
- 19 Apr, 2019 10 commits
-
-
Chunfeng Yun authored
Use devm_clk_get_optional() to get optional clock instead of optional_clk_get() which uses devm_clk_get() to get clock and checks for -EPROBE_DEFER but not -ENOENT as devm_clk_get_optional() does, in fact, only ignoring -ENOENT will cover more errors, so the replacement doesn't change original purpose. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Chunfeng Yun authored
When the driver tries to get optional clock, it ignores all errors except -EPROBE_DEFER, but if only ignores -ENOENT, it will cover some real errors, such as -ENOMEM, so use devm_clk_get_optional() to get optional clock. Cc: Peter Chen <Peter.Chen@nxp.com> Signed-off-by:
Peter Chen <Peter.Chen@nxp.com> Signed-off-by:
-
Chunfeng Yun authored
When the driver tries to get optional clock, it ignores all errors, but if only ignores -ENOENT, it will cover some real errors, such as -EPROBE_DEFER, so use devm_clk_get_optional() to get optional clock. Cc: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by:
Minas Harutyunyan <hminas@synopsys.com> Signed-off-by:
-
Chunfeng Yun authored
When the driver tries to get optional clock, it ignores all errors except -EPROBE_DEFER, but if only ignores -ENOENT, it will cover some real errors, such as -ENOMEM, so use devm_clk_get_optional() to get optional clock. And remove unnecessary stack variable clk. Cc: Dongjin Kim <tobetter@gmail.com> Signed-off-by:
-
Chunfeng Yun authored
When the driver tries to get optional clock, it ignores all errors except -EPROBE_DEFER, but if only ignores -ENOENT, it will cover some real errors, such as -ENOMEM, so use devm_clk_get_optional() to get optional clock. Cc: Mathias Nyman <mathias.nyman@intel.com> Signed-off-by:
-
Chunfeng Yun authored
Use devm_clk_get_optional() to get optional clock instead of optional_clk_get() which uses devm_clk_get() to get clock and checks for -EPROBE_DEFER but not -ENOENT as devm_clk_get_optional() does, in fact, only ignoring -ENOENT will cover more errors, so the replacement doesn't change original purpose. Signed-off-by:
-
Hans de Goede authored
Some tcpc device-drivers need to explicitly be told to watch for connection events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices being plugged into the Type-C port will not be noticed. For dual-role ports tcpm_start_drp_toggling() is used to tell the tcpc to watch for connection events. But for single-role ports we've so far been falling back to just calling tcpm_set_cc(). For some tcpc-s such as the fusb302 this is not enough and no TCPM_CC_EVENT will be generated. Commit ea3b4d55 ("usb: typec: fusb302: Resolve fixed power role contract setup") fixed SRPs not working because of this by making the fusb302 driver start connection detection on every tcpm_set_cc() call. It turns out this breaks src->snk power-role swapping because during the swap we first set the Cc pins to Rp, calling set_cc, and then send a PS_RDY message. But the fusb302 cannot send PD messages while its toggling engine is active, so sending the PS_RDY message fails. Struct tcpc_dev now has a new start_srp_connection_detect callback and fusb302.c now implements this. This callback gets called when we the fusb302 needs to start connection detection, fixing fusb302 SRPs not seeing connected devices. This allows us to revert the changes to fusb302's set_cc implementation, making it once again purely setup the Cc-s and matching disconnect detection, fixing src->snk power-role swapping no longer working. Note that since the code was refactored in between, codewise this is not a straight forward revert. Functionality wise this is a straight revert and the original functionality is fully restored. Fixes: ea3b4d55 ("usb: typec: fusb302: Resolve fixed power role ...") Cc: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
-
Hans de Goede authored
When in single-role port mode, we must start single-role toggling to get an interrupt when a device / cable gets plugged into the port. This commit modifies the fusb302 start_toggling implementation to start toggling for all port-types, so that connection-detection works on single-role ports too. Fixes: ea3b4d55("usb: typec: fusb302: Resolve fixed power role ...") Cc: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
-
Hans de Goede authored
Some tcpc device-drivers need to explicitly be told to watch for connection events, otherwise the tcpc will not generate any TCPM_CC_EVENTs and devices being plugged into the Type-C port will not be noticed. For dual-role ports tcpm_start_drp_toggling() is used to tell the tcpc to watch for connection events. Sofar we lack a similar callback to the tcpc for single-role ports. With some tcpc-s such as the fusb302 this means no TCPM_CC_EVENTs will be generated when the port is configured as a single-role port. This commit renames start_drp_toggling to start_toggling and since the device-properties are parsed by the tcpm-core, adds a port_type parameter to the start_toggling callback so that the tcpc_dev driver knows the port-type and can act accordingly when it starts toggling. The new start_toggling callback now always gets called if defined, instead of only being called for DRP ports. To avoid this causing undesirable functional changes all existing start_drp_toggling implementations are not only renamed to start_toggling, but also get a port_type check added and return -EOPNOTSUPP when port_type is not DRP. Fixes: ea3b4d55("usb: typec: fusb302: Resolve fixed power role ...") Cc: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
-
Yan Zhu authored
fhci_queue_urb() shouldn't use urb->pipe to compute the maxpacket size anyway.It should use usb_endpoint_maxp(&urb->ep->desc). Signed-off-by:
Yan Zhu <zhuyan34@huawei.com> Signed-off-by:
-
- 18 Apr, 2019 7 commits
-
-
Marc Gonzalez authored
Add compatible string for QMP PCIe phy on msm8998. Signed-off-by:
-
Yu Chen authored
This driver handles usb phy power on and shutdown for hi3660 Soc of Hisilicon. Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Pengcheng Li <lpc.li@hisilicon.com> Cc: Jianguo Sun <sunjianguo1@huawei.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Jiancheng Xue <xuejiancheng@hisilicon.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Yu Chen <chenyu56@huawei.com> Signed-off-by:
-
Yu Chen authored
This patch adds binding documentation for supporting the hi3660 usb phy on boards like the HiKey960. Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Binghui Wang <wangbinghui@hisilicon.com> Reviewed-by:
-
Colin Ian King authored
There is a typo in the module author's email address. Fix this. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Stanley Chu <stanley.chu@mediatek.com> Acked-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Kavya Sree Kotagiri authored
Adding support for SERDES6G muxing required for QSGMII mode of operation. Signed-off-by:
Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com> Signed-off-by:
Quentin Schulz <quentin.schulz@bootlin.com> Signed-off-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Co-developed-by:
-
Lucas Stach authored
This adds support to the PHY driver to power up/down the VBUS voltage rail at the appropriate times. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Lucas Stach authored
Add a vbus supply regulator phandle, so the PHY can enable the VBUS voltage rail when powering up. Signed-off-by:
-
- 17 Apr, 2019 1 commit
-
-
Alan Stern authored
The SCSI core does not like to have devices or hosts unregistered while error recovery is in progress. Trying to do so can lead to self-deadlock: Part of the removal code tries to obtain a lock already held by the error handler. This can cause problems for the usb-storage and uas drivers, because their error handler routines perform a USB reset, and if the reset fails then the USB core automatically goes on to unbind all drivers from the device's interfaces -- all while still in the context of the SCSI error handler. As it turns out, practically all the scenarios leading to a USB reset failure end up causing a device disconnect (the main error pathway in usb_reset_and_verify_device(), at the end of the routine, calls hub_port_logical_disconnect() before returning). As a result, the hub_wq thread will soon become aware of the problem and will unbind all the device's drivers in its own context, not in the error-handler's context. This means that usb_reset_device() does not need to call usb_unbind_and_rebind_marked_interfaces() in cases where usb_reset_and_verify_device() has returned an error, because hub_wq will take care of everything anyway. This particular problem was observed in somewhat artificial circumstances, by using usbfs to tell a hub to power-down a port connected to a USB-3 mass storage device using the UAS protocol. With the port turned off, the currently executing command timed out and the error handler started running. The USB reset naturally failed, because the hub port was off, and the error handler deadlocked as described above. Not carrying out the call to usb_unbind_and_rebind_marked_interfaces() fixes this issue. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Kento Kobayashi <Kento.A.Kobayashi@sony.com> Tested-by:
-
