On Mon, Mar 25, 2024 at 10:56:21PM +0200, Dmitry Baryshkov wrote: > On Fri, 22 Mar 2024 at 14:16, Johan Hovold <johan@xxxxxxxxxx> 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). Johan
