[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e04a5a51-10cb-3015-2e3e-44a6f6348d06@gmail.com>
Date: Tue, 5 Apr 2022 14:43:53 +0900
From: Akihiko Odaki <akihiko.odaki@...il.com>
To: Guenter Roeck <groeck@...gle.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
chrome-platform@...ts.linux.dev,
Prashant Malani <pmalani@...omium.org>,
Benson Leung <bleung@...omium.org>,
Guenter Roeck <groeck@...omium.org>
Subject: Re: [PATCH] platform/chrome: cros_ec_typec: Check for EC driver
On 2022/04/05 10:57, Guenter Roeck wrote:
> On Sun, Apr 3, 2022 at 9:11 PM Akihiko Odaki <akihiko.odaki@...il.com> 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@...il.com>
>
> Not sure if this is the best solution, but I don't know a better one.
>
> Reviewed-by: Guenter Roeck <groeck@...omium.org>
>
>> ---
>> 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
>>
Powered by blists - more mailing lists