linux-kernel - Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <5020127D-136C-4CFD-83D3-A6C832A97552@holtmann.org>
Date:	Sun, 25 May 2008 20:28:13 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Michael Buesch <mb@...sch.de>
Cc:	Johannes Berg <johannes@...solutions.net>,
	David Woodhouse <dwmw2@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
	aoliva@...hat.com, alan@...rguk.ukuu.org.uk,
	Abhay Salunke <Abhay_Salunke@...l.com>, kay.sievers@...y.org,
	Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option

Hi Michael,

>> So you actually do know how request_firmware() actually works right
>> now? You need to change the firmware_class implementation and API to
>> give it an extra parameter to allow any kind if simultaneous loading
>> within one driver. Having the FIRMWARE as environment variable is
>> actually suboptimal. You want to have the FIRMWARE environment
>> variable as bus_id for the firmware struct device object.
>
> Can you explain _why_ we want to have this as bus_id?
> I don't really understand that.

we want to avoid duplicate sysfs entries. And with multi-function  
devices like in SDIO this can happen that the actual sysfs device  
entry becomes the same and then the struct device creation for the  
second firmware loading fails (if the first one hasn't finished).  
Putting the actually firmware filename as bus_id allows us to  
distinguish between the different firmware loading tasks.

With the remove of class devices and the more complex multi-function  
devices we have to make the firmware loading fully race free. If not  
we end up with sleep(1) hacks around everything and we don't want that.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/