Re: [PATCH] platform/chrome: cros_ec_typec: Check for EC driver

From: Akihiko Odaki
Date: Tue Apr 05 2022 - 01:44:04 EST


On 2022/04/05 10:57, Guenter Roeck wrote:
On Sun, Apr 3, 2022 at 9:11 PM Akihiko Odaki <akihiko.odaki@xxxxxxxxx> wrote:

The EC driver may not be initialized when cros_typec_probe is called,
particulary when CONFIG_CROS_EC_CHARDEV=m.


Does this cause a crash ? If so, do you have a crash log ?

It indeed caused a crash but I don't have a log because I couldn't get a serial console. Adding dev_error calls revealed ec_dev in cros_typec_probe can be NULL if CONFIG_CROS_EC_CHARDEV=m.


Reason for asking is that I saw the following crash, and it would be
good to know if the problem is the same.

This is just a guess, but I don't think it is unlikely.

The call trace indicates it dereferenced a NULL pointer in cros_ec_command, which is directly called by cros_typec_probe.

At the source level, cros_ec_command is directly called just once in cros_typec_probe, which dereferences typec->ec. typec->ec is however already used by cros_typec_get_cmd_version so it would never trigger a NULL dereference. Therefore, the crash should have happened in an inlined function.

cros_ec_command is called by cros_typec_get_cmd_version and cros_ec_check_features. cros_ec_check_features, which dereferenced NULL on my laptop, is called twice and unlikely to be inlined. cros_typec_get_cmd_version is called only once and is more likely to be inlined and thus the cause of the Oops in your crash. (By the way, the possibility of inlining would also make comparing call traces meaningless due to compiler/kernel version variances.)

This is just a guess anyway so you may disassemble your kernel build to know if it is same or not, which I think should be straightforward enough.

Regards,
Akihiko Odaki


<1>[ 6.651137] #PF: error_code(0x0002) - not-present page
<6>[ 6.651139] PGD 0 P4D 0
<4>[ 6.651143] Oops: 0002 [#1] PREEMPT SMP NOPTI
<4>[ 6.651146] CPU: 0 PID: 1656 Comm: udevd Tainted: G U
5.4.163-17384-g99ca1c60d20c #1
<4>[ 6.651147] Hardware name: HP Lantis/Lantis, BIOS
Google_Lantis.13606.204.0 05/26/2021
<4>[ 6.651152] RIP: 0010:mutex_lock+0x2b/0x3c
...
<4>[ 6.651174] Call Trace:
<4>[ 6.651180] cros_ec_cmd_xfer+0x22/0xc1
<4>[ 6.651183] cros_ec_cmd_xfer_status+0x19/0x59
<4>[ 6.651185] cros_ec_command+0x82/0xc3
<4>[ 6.651189] cros_typec_probe+0x8a/0x5a2 [cros_ec_typec]

Signed-off-by: Akihiko Odaki <akihiko.odaki@xxxxxxxxx>

Not sure if this is the best solution, but I don't know a better one.

Reviewed-by: Guenter Roeck <groeck@xxxxxxxxxxxx>

---
drivers/platform/chrome/cros_ec_typec.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index 4bd2752c0823..7cb2e35c4ded 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -1084,6 +1084,9 @@ static int cros_typec_probe(struct platform_device *pdev)
}

ec_dev = dev_get_drvdata(&typec->ec->ec->dev);
+ if (!ec_dev)
+ return -EPROBE_DEFER;
+
typec->typec_cmd_supported = cros_ec_check_features(ec_dev, EC_FEATURE_TYPEC_CMD);
typec->needs_mux_ack = cros_ec_check_features(ec_dev, EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK);

--
2.35.1