On 2/15/24 20:03, Christian A. Ehrhardt wrote:
> External email: Use caution opening links or attachments
>
>
> Hi Greg,
>
> On Thu, Feb 15, 2024 at 12:07:20PM +0100, Greg Kroah-Hartman wrote:
>> On Thu, Feb 15, 2024 at 11:10:24AM +0100, Christian A. Ehrhardt wrote:
>>> In case of a spurious or otherwise delayed interrupt
>>> it is possible that CCI still reports the previous completion.
>>> For this reason the UCSI spec provides different completion
>>> bits for normal commands and for UCSI_ACK_CC_CI.
>>>
>>> Only complete a sync command if the correct completion bit
>>> is set.
>>>
>>> This should avoid the need to clear out CCI before starting
>>> a command. Thus remove this code.
>>>
>>> Signed-off-by: Christian A. Ehrhardt <lk@xxxxxxx>
>>> Fixes: e32fd989ac1c ("usb: typec: ucsi: ccg: Move to the new API")
>>
>> What does "CFT" in your subject line mean?
>
> It's supposed to mean "Call For Testers". More info in the
> "Additional Information" section of the original mail.
>
> I think the change is necessary and good but I do not have the HW
> to test it.
>
> I did test a similar change for ucsi_acpi.c that got merged and this
> is the ping for ucsi_ccg.c people that they probably need this, too.
>
> regards Christian
>
>
Hi Christian,
If we don't clean the CCI cache in ucsi_ccg_async_write(), there might
be a potential problem when the driver is polling the results.
In ucsi_init(), we may get EPROBE_DEFER from ucsi_register_port().
Then it does ucsi_reset_ppm() before returning the error code, and we
will get UCSI_CCI_RESET_COMPLETE and store it in the CCI cache.
If we don't clean the cache, when the UCSI driver calls ucsi_init()
again, then in ucsi_reset_ppm(), it will get UCSI_CCI_RESET_COMPLETE
from the CCI cache instantly.
Then the driver will run the next UCSI commands when the HW is not
completely reset.
Regards,
Haotien
