linux-kernel - Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use 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>] [day] [month] [year] [list]

Message-ID: <CA+55aFxJ=Z+c3NxWgOajYD6MOK-7cT=8gfPN9BP_jjhYbs6Z6g@mail.gmail.com>
Date:	Wed, 3 Oct 2012 18:42:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Kay Sievers <kay@...y.org>,
	Lennart Poettering <lennart@...ttering.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kay Sievers <kay@...hat.com>,
	Linux Media Mailing List <linux-media@...r.kernel.org>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Ivan Kalvachev <ikalvachev@...il.com>
Subject: Re: udev breakages - was: Re: Need of an ".async_probe()" type of
 callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()

On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei <ming.lei@...onical.com> wrote:
>
> Yes, the patch will make firmware cache not working, I would like to fix
> that when I return from one trip next week.
>
> BTW, firmware cache is still needed even direct loading is taken.

I agree 100%, I'd have liked to do the caching for the direct-loading
case too. It's just that the freeing case for that is so intimately
tied to the firmware_buf format which is actually very inconvenient
for direct-loading, that making that happen looked a lot more
involved.

And I was indeed hoping you'd look at it, since you touched the code
last.  "Tag, you're it"

It shouldn't be *too* bad to instead of doing the "vmalloc()" allocate
an array of pages and then using "vmap()" instead in order to read
them (we end up doing the vmap anyway, since the firmware *user* wants
a virtually contiguous buffer), but the code will definitely get a bit
more opaque.

                        Linus
--
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/