linux-kernel - Re: [PATCH] platform/chrome: Add ChromeOS EC USB driver

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]

Message-ID: <CAJ_BA_BmPXrMqP1VxAAGDoWHffsU2pjnuYRO3MhCb=VRq-hS+Q@mail.gmail.com>
Date: Fri, 11 Jul 2025 18:00:04 +0200
From: Dawid Niedźwiecki <dawidn@...gle.com>
To: Tzung-Bi Shih <tzungbi@...nel.org>
Cc: Benson Leung <bleung@...omium.org>, chrome-platform@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, chromeos-krk-upstreaming@...gle.com, 
	Łukasz Bartosik <ukaszb@...omium.org>
Subject: Re: [PATCH] platform/chrome: Add ChromeOS EC USB driver

Resending due to HTML incident

>FWIW: It depends on the bus details.  If you find my previous message, SCP
>over RPMSG also re-registers everytime after the firmware reboot.

You are right. But I'm not sure if it is a good approach. My understanding is
that the HAL/API should behave the same way, regardless of what interface
is behind.

>One challenge for current version: it makes the driver more complicated than
>others.  E.g. what would be happening if some friend drivers try to access
>`ec_dev` while the `cros_ec_usb_probe` is writing to `ec_usb` at a time?
>It tries to manage the device's lifecycle one level upper than USB (don't
>know what it should call, "session"?).

Yes, the more complicated driver is for sure not a good thing.
In that case, it shouldn't cause anything wrong. The disconnect field is set to
false once everything is ready. Before that, there are no transfers handled.

>Another challenge: it doesn't call cros_ec_unregister() in its driver removal
>entry.  What would be happening if someone re-inserts the module multiple
>times?

That's the same case as reboot/sysjump. We would get the probe callback,
the driver would notice (by Product ID) that this EC device has been already
registered and would replace the USB related structures in the cros_ec_usb
structure and the same cros_X  file would start working again.