On Tue, Aug 17, 2010 at 06:01:45PM -0400, Alan Stern wrote:
> On Mon, 16 Aug 2010, Chris Beauchamp wrote:
>
> > > These traces are very difficult to follow because they show multiple
> > > hubs with multiple devices attached to them. Can you provide the
> > > equivalent information for a single device with no hubs?
> > >
> >
> > Well, each box appears to be a couple of hubs and 8 dual serial port
> > adaptors. Tricky to separate without completely voiding the warranty
> > :) There is only one plugged in at a time. Is there a way to separate
> > in software - I guess I could go through and grep for each device and
> > separate into a file per device? Would that be helpful?
>
> I made some progress by concentrating on just one device. It appears
> that the problem is entirely in the io_ti.c driver; you can see by
> comparing these lines from the firstplug and secondplug kernel
> logs:
>
> [ 79.333294] /build/buildd/linux-2.6.32/drivers/usb/serial/io_ti.c: download_fw - >> FW Versions Device 4.80 Driver 0.0
> [ 79.333299] /build/buildd/linux-2.6.32/drivers/usb/serial/io_ti.c: download_fw - Update I2C dld from 4.80 to 0.0
>
> [ 227.167254] /build/buildd/linux-2.6.32/drivers/usb/serial/io_ti.c: download_fw - >> FW Versions Device 4.80 Driver 4.80
>
> See the difference in the Driver values? The first time through the
> Driver version is uninitialized, hence equal to 0.0, which is different
> from the version 4.80 firmware in the device, so the driver tries to
> update the device firmware from 4.80 to 0.0!
>
> The Driver version doesn't get updated until the driver runs across a
> device with blank firmware and then loads the firmware file from disk.
> At that point it learns what the version number should be, and things
> start to work a little better. There are still problems though,
> because when the driver sends the firmware to the device, the device
> doesn't accept the final command to start running the new firmware (the
> command times out). That's probably why you need to unplug and replug
> it.
>
> That's in 2.6.27. Back in 2.6.24 the firmware was build into the
> driver, not a separate file, so there was no problem about the Driver
> version being uninitialized.
>
> Greg, I don't know the right way to fix this. Should
> io_ti.c:download_fw() simply assume that if download_new_ver is 0 then
> download_cur_ver is correct? Or should it always request the firmware
> file (that is, call build_i2c_fw_hdr()) during module initialization?
We should probably not allow the firmware to be downgraded, so a check
for < should probably be used instead.
Chris, can you apply the patch below to see if that helps out any?
> I also don't know why the devices don't accept the command to run the
> new firmware. Any ideas?
Probably because the firmware isn't around at boot time (not built into
the kernel anymore).
thanks,
greg k-h
--------------
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index dc47f98..c3f27c3 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1151,7 +1151,7 @@ static int download_fw(struct edgeport_serial *serial)
/* Check if we have an old version in the I2C and
update if necessary */
- if (download_cur_ver != download_new_ver) {
+ if (download_cur_ver < download_new_ver) {
dbg("%s - Update I2C dld from %d.%d to %d.%d",
__func__,
firmware_version->Ver_Major,
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
