Messages in this thread | | | From | Ruihai Zhou <> | Subject | Re: [PATCH] platform/chrome: cros_ec_typec: deferred probe when typec count mismatch | Date | Wed, 21 Dec 2022 10:58:32 +0800 |
| |
> I think that is problematic. It might as well be that nports > > EC_USB_PD_MAX_PORTS. Yes, you're right. so we should consider it's a invalid argument and return -EINVAL if nports > EC_USB_PD_MAX_PORTS. right? > Is this really seen in the field ? The EC should never report a wrong > (random) number of ports. If it is not ready, there should be _some_ > indication that it isn't ready. Does it really report a more or less > random number in this case ? Yes, I saw this on corsola boards. The EC report a wrong(not random) number. because corsola emulates HDMI MUX over the current type-c mux stack. The ec has to fake a type-c port to pass the MUX info. But the task are not initiated on starting up, and increase the type-c port counts after the tasks finished. In this case, I saw the typec->num_ports = 1, but the nports = 2, which will be probe failed and block the HDMI MUX function. I will send v2 patch, if nports > EC_USB_PD_MAX_PORTS, then return -EINVAL, but if nports > typec->num_ports, we consider wait a second to ec task increase the type-c port counts if there're HDMI DB attach, then return -EPROBE_DEFER.
| |