linux-kernel - Re: [PATCH 2/4] usb: typec: tipd: add function to request firmware

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: <d70255fb-7dc0-4119-b52a-9e8a955f0712@wolfvision.net>
Date:   Wed, 13 Dec 2023 16:32:09 +0100
From:   Javier Carrasco <javier.carrasco@...fvision.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] usb: typec: tipd: add function to request firmware

On 13.12.23 16:15, Heikki Krogerus wrote:
> On Tue, Dec 12, 2023 at 03:41:35PM +0100, Javier Carrasco wrote:
>> I wonder why then there is no general solution that does not force the
>> driver to be built as a module.
> 
> Why would you need anything like that? Are you saying that even if you
> put the firmware into your ramdisk, the driver still fails to find the
> firmware if it's statically build? If so, then there is something else
> wrong.
> 
The firmware is always found unless the file system is still not ready,
which is the case on the system I am working on. If the driver is built
as a module, the issue is gone as expected.

My point was that there is no limitation to have the driver built-in and
no documentation to reference, so anyone could stumble on the same
issue. And as you said, this driver is not special in that sense, so
other drivers might be facing the same eventuality.
Am I missing any existing documentation for the fact that the firmware
must be put into the ramdisk or the driver must be built as a module? Or
is it only based on common sense?

Anyway the next version will not have any probe deferring and only
return an error if the firmware is not available.

Thanks and best regards,
Javier Carrasco