Re: [patch, attach, RFC] usb-serial: ti_usb removing firmware
On 12/16/06, Al Borchers <alborchers@steinerpoint.com> wrote:
Oleg --
Some comments. I will be away until next Tuesday, when I can do
more with this.
Thanks.
* We can't remove the compiled in firmware--that would break things
until users get and install the firmware images.
* What I did in my patch at www.brimson.com/downloads/ti_usb_multitech-1.1.tgz
is to use request_firmware for new devices, and, if the firmware files are
present, for the existing 3410 and 5052 devices. If the firmware files are
not present for 3410 and 5052, then it uses the compiled in firmware.
Please, see this as policy, not as the need ("this" here is no binary
blobs in the linux
sources && symlink your windowz firmware files in "/lib/firmware".
Please see my last
e-mail.) I can understand "all cases handling" in application
programming, but not here.
[...]
* The whitespace, 80 cols, dbg cleanup is great--maybe put that in a separate
patch.
emacs, and this is problem with linux/Makefile (my first ever
code-patch for linux ;)
* I would not remove the comments about the hotplug script until we
can use the 2.6.19 usb_driver_set_configuration function.
Please see my last e-mail [1]. And many useless code must be copies
for every ID.
* - status = -ENODEV;
+ status = 0xFAC; /* greater than zero -- device is going down
*/
- status = -ENODEV;
+ status = 0x0FF;
Why 0xFAC and 0x0FF? I will have to investigate and test this. I think
we want negative values.
Please see my last e-mail [1]. Serial-converter device _is_ made to be
that way, and
configuration steps must be good steps. With error codes you did that
as error, _two_
I/O errors is very much for ordinary setup of the plugged-in device,
do you see my point?
* + dev_info(&dev->dev, "%s - Choose configuration #2, please.\n",
+ ti_usb_driver.name);
+
This is what the hotplug script does automatically. Drop this info message.
Yes. (in my prev. e-mail [1]) I said, that most people can use bash
and not udev.
* Using smaller buffers in download_firmware sounds like a good idea.
I will look at that next week--no time tonight.
* +#define TI_3410_EZ430_ID 0xF430 /* TI ez430 development tool
*/
Where do you use this?
Shiny new device from TI, don't you know? You've lost nothing MSP430
Design Contest
is over ;D www.designmsp430.com
Thanks,
-- Al
Thank you very much, Al.
But if debian guys do not against, i think it can be in the Etch,
there isn't any crap in patch.
[1] <http://article.gmane.org/gmane.linux.usb.devel/49186>
--
-o--=O`C
#oo'L O
<___=E M
Reply to: