Jaswinder Singh wrote:
> this is a first draft; please be kind :)
>
> Firmware blob is little endian looks like this...
> unsigned char Version1
> unsigned char Version2
> unsigned char Version3
> unsigned char Padding
> unsigned short start_address
> unsigned short data
Hello,
As the maintainer of this driver I am going to say that I think this is
a stupid change. Yes I know that politically there's a move to make
everything use request firmware. However for my boot device, this is
going to be a royal pain in the butt for developers who wish to boot
test kernels with a / sitting on a 1280.
IMHO this patch brings us nothing, but provides a lot of unnecessary
hassle for users.
Nacked-By: Jes Sorensen <[email protected]>
Regards,
Jes
Hello Jes,
On Mon, 2008-07-14 at 11:29 +0200, Jes Sorensen wrote:
> Jaswinder Singh wrote:
> > this is a first draft; please be kind :)
> >
> > Firmware blob is little endian looks like this...
> > unsigned char Version1
> > unsigned char Version2
> > unsigned char Version3
> > unsigned char Padding
> > unsigned short start_address
> > unsigned short data
>
> Hello,
>
> As the maintainer of this driver I am going to say that I think this is
> a stupid change.
We have not changed the data.
We are passing risc_code01 data by using request_firmware when required.
If you found some problem in the code, Please let me know.
Thank you,
Jaswinder Singh.
On Mon, 2008-07-14 at 11:29 +0200, Jes Sorensen wrote:
> However for my boot device, this is going to be a royal pain in the
> butt for developers who wish to boot test kernels with a / sitting on
> a 1280.
Not so. All they have to do is choose to build the firmware into their
kernel, and it works as it always did.
--
dwmw2
Jaswinder Singh wrote:
> We have not changed the data.
> We are passing risc_code01 data by using request_firmware when required.
>
> If you found some problem in the code, Please let me know.
My issue was not about changing the format of the data, but about it
being forced into userland, ie. requiring an initrd. After speaking to
Woodhouse over irc, I have learned that with the new firmware
infrastructure this is optional and one can still link the firmware into
the kernel.
Given that the previous firmware moving patches have always been about
getting firmware out of the kernel due to certain distro's being silly
about it, this wasn't actually obvious. If your patch description had
been a little more detailed and explained that it didn't require
firmware to go into userland it would have been easier for someone who
hasn't been following the previous thread on the subject.
So, I don't have any objections to this patch as long as the new
firmware interface continues to allow me to link this into the kernel.
Regards,
Jes