On Wed, Feb 12, 2014 at 12:49:46PM -0500, Mark Hounschell wrote: > Add in kernel firmware loading support > > Signed-off-by: Mark Hounschell <ma...@compro.net> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
You also do other things in this patch, like coding style cleanups, right? That's fine for a staging driver, but it makes it hard to review, so you should probably break this up into pieces (i.e. one that only does the firmare stuff, and one that does the coding style stuff. > > diff -urN linux-3.13.1-orig/drivers/staging/dgap/dgap_driver.c > linux-3.13.1-new/drivers/staging/dgap/dgap_driver.c > --- linux-3.13.1-orig/drivers/staging/dgap/dgap_driver.c 2014-02-03 > 13:34:50.489287314 -0500 > +++ linux-3.13.1-new/drivers/staging/dgap/dgap_driver.c 2014-02-03 > 14:12:20.059076489 -0500 > @@ -18,6 +18,33 @@ > * > */ > > +/* > + * In the original out of kernel Digi dgap driver, firmware > + * loading was done via user land to driver handshaking. > + * > + * For cards that support a concentrator (port expander), > + * I believe the concentrator its self told the card which > + * concentrator is actually attached and then that info > + * was used to tell user land which concentrator firmware > + * image was to be downloaded. I think even the BIOS or > + * FEP images required would change with the connection > + * of a particular concentrator. > + * > + * Since I have no access to any of these cards or > + * concentrators, I cannot put the correct concentrator > + * firmware file names into the firmware_info structure > + * as is now done for the BIOS and FEP images. Trailing spaces on these paragraphs, checkpatch.pl should have complained about this. thanks, greg k-h _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
