On Tue, 26 Mar 2024 at 10:41, Johan Hovold johan@kernel.org wrote:
On Mon, Mar 25, 2024 at 10:56:21PM +0200, Dmitry Baryshkov wrote:
On Fri, 22 Mar 2024 at 14:16, Johan Hovold johan@kernel.org wrote:
I just gave this series a quick spin on my X13s and it seems there are still some issues that needs to be resolved before merging at least the final patch in this series:
[ 7.786167] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: unknown error 0 [ 7.786445] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: UCSI_GET_PDOS failed (-5) [ 7.883493] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: unknown error 0 [ 7.883614] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: UCSI_GET_PDOS failed (-5) [ 7.905194] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: unknown error 0 [ 7.905295] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: UCSI_GET_PDOS failed (-5) [ 7.913340] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: unknown error 0 [ 7.913409] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: UCSI_GET_PDOS failed (-5)
I have traced what is causing these messages. During UCSI startup the ucsi_register_port() function queries for PDOs associated with the on-board USB-C port. This is allowed by the spec. Qualcomm firmware detects that there is no PD-device connected and instead of returning corresponding set of PDOs returns Eerror Indicator set to 1b but then it returns zero error status in response to GET_ERROR_STATUS, causing "unknown error 0" code. I have checked the PPM, it doesn't even have the code to set the error status properly in this case (not to mention that asking for device's PDOs should not be an error, unless the command is inappropriate for the target.
Thus said, I think the driver is behaving correctly. Granted that these messages are harmless, we can ignore them for now. I'll later check if we can update PD information for the device's ports when PD device is attached. I have verified that once the PD device is attached, corresponding GET_PDOS command returns correct set of PD objects. Ccurrently the driver registers usb_power_delivery devices, but with neither source nor sink set of capabilities.
An alternative option is to drop patches 4 and 5, keeping 'NO_PARTNER_PDOS' quirk equivalent to 'don't send GET_PDOS at all'. However I'd like to abstain from this option, since it doesn't allow us to check PD capabilities of the attached device.
Heikki, Johan, WDYT?
Whatever you do, you need to suppress those errors above before enabling anything more on sc8280xp (e.g. even if it means adding a quirk to the driver).
Why? The errors are legitimate.