netdev - Re: [PATCH] firmware: convert acenic driver to request

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]

Date:	Mon, 16 Jun 2008 16:34:11 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	Jes Sorensen <jes@...ined-monkey.org>, netdev@...r.kernel.org,
	jaswinder@...radead.org
Subject: Re: [PATCH] firmware: convert acenic driver to request_firmware()

David Woodhouse wrote:
> Again with help from Jaswinder Singh.
> 
> Omitting the large part of the patch which actually moves the firmware
> around, since you'll need to pull from the git tree to get the preceding
> patches if you want to test it anyway.
> 
> We store the firmware in little-endian form now, and thus use
> __raw_writel() to write it to the device, to avoid byteswapping by
> writel(). I've revamped that loop in ace_copy() a little bit so it could
> probably do with being tested.
> 
> I've dropped the information about SBSS and BSS sections of the firmware
> -- we were clearing the whole of the device's memory in advance anyway,
> so clearing the BSS sections for a _second_ time seems pointless. And
> since the text,rodata,data sections were (almost) contiguous, we now
> just load those as a single blob rather than keeping them separate.
> 
> Although it probably isn't necessary, we do preserve the ability to
> change the load and start addresses from 0x4000, by putting them into a
> header at the beginning of the firmware blob, along with the version
> number.

Mostly ok...

1) firmware separation should be a separate patch from 
request_firmware() support addition

2) [minor] firmware Kconfig entries should default to 'Y' during 
transition, though it's ok to remove those after transition is over

3) there are enough changes to warrant a requirement of a "driver still 
works" test before going in, IMO

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html