linux/drivers/usb/typec, branch v5.2

usb: typec: Make sure an alt mode exist before getting its partner

2019-06-12T15:13:02Z

Adding check to typec_altmode_get_partner() to prevent potential NULL pointer dereference. Reported-by: Vladimir Yerilov Fixes: ad74b8649bea ("usb: typec: ucsi: Preliminary support for alternate modes") Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: ccg: fix memory leak in do_flash

2019-06-03T12:24:57Z

In case memory resources for *fw* were successfully allocated, release them before return. Addresses-Coverity-ID: 1445499 ("Resource leak") Fixes: 5c9ae5a87573 ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Gustavo A. R. Silva Acked-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: ccg: fix missing unlock on error in ccg_cmd_write_flash_row()

2019-04-29T12:25:12Z

Add the missing unlock before return from function ccg_cmd_write_flash_row() in the error handling case. Fixes: 5c9ae5a87573 ("usb: typec: ucsi: ccg: add firmware flashing support") Signed-off-by: Wei Yongjun Acked-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: Add driver for NVIDIA Alt Modes

2019-04-25T09:04:56Z

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 Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: displayport: Export probe and remove functions

2019-04-25T09:04:55Z

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 Signed-off-by: Ajay Gupta Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Support for DisplayPort alt mode

2019-04-25T09:04:55Z

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: Ajay Gupta Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Preliminary support for alternate modes

2019-04-25T09:03:53Z

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 Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: ccg: add firmware flashing support

2019-04-25T09:03:53Z

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 [ heikki: Added ABI documentation. ] Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: ccg: add get_fw_info function

2019-04-25T09:03:52Z

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: Ajay Gupta Signed-off-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman

usb: typec: fusb302: Revert "Resolve fixed power role contract setup"

2019-04-19T12:23:34Z

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 ea3b4d5523bc ("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: ea3b4d5523bc ("usb: typec: fusb302: Resolve fixed power role ...") Cc: Adam Thomson Signed-off-by: Hans de Goede Reviewed-by: Guenter Roeck Acked-by: Heikki Krogerus Tested-by: Adam Thomson Signed-off-by: Greg Kroah-Hartman