linux-kernel - Re: [PATCH] platform/chrome: cros_ec_typec: deferred probe when typec count mismatch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 22 Dec 2022 09:53:19 +0800
From:   Ruihai Zhou <zhouruihai@...qin.corp-partner.google.com>
To:     pmalani@...omium.org, bleung@...omium.org, groeck@...omium.org,
        knoxchiou@...omium.org, weishunc@...omium.org
Cc:     chrome-platform@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] platform/chrome: cros_ec_typec: deferred probe when typec count mismatch

> Sorry, but I agree with Guenter; I don't think this is justification to add a
> hack for 1 board in this driver.
>
> In what situation does the EC task take so long after reboot that it
> occurs after a module probe (which occurs shortly after system boot up)?
>
> Why is the "corsola" board increasing the Type-C port count dynamically
> after some delay, and what is that delay amount? Why can't this be set
> via CBI/DT or its equivalent on your ARM platform?
>
> This seems like fragile code in the EC and should be fixed there. The
> number of Type-C ports reported by the EC really should be invariant
> across the boot lifecycle. I don't think this patch can be accepted.
>

Alright, I got it. Thank you for your patience and the suggestions.

Because the tcpc/pd tasks are not needed for the HDMI port.
The EC don't want the tasks initiated on starting up, and increase the
counts after the tasks are launched. The delay amount was 2 second before,
(always failed when ec reboot on firmware normal mode) and change to
1 second later, and 500ms yesterday(not reproduce until now).
The delay on EC can be referred to here [1]. However, with the current
design, the number of type-c ports reported by EC isn't invariant across
the boot lifecycle. Also, maybe printing the counts getting from EC
when encountered this field will be a littel helpful for debugging. just
an insignificant thought.

> If you really need to change the number of ports dynamically in the EC,
> add a board specific-hook to not respond to the EC_CMD_USB_PD_PORTS
> host command until you have "set" the number of ports.

Got it. Thank you again for your suggestions.

Link:
[1] https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/ec/zephyr/program/corsola/src/usbc.c;l=222