[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26a723e4-e166-6377-875a-f737a15dc6b1@marcansoft.com>
Date: Thu, 10 Sep 2020 18:57:47 +0900
From: Hector Martin <hector@...cansoft.com>
To: James Hilliard <james.hilliard1@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Johan Hovold <johan@...nel.org>, Lars Melin <larsm17@...il.com>,
Oliver Neukum <oneukum@...e.de>, linux-usb@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Russ Dill <Russ.Dill@...il.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On 10/09/2020 18.52, James Hilliard wrote:
> So I'm having trouble coming up with a reliable way to fix this in userspace,
> I've already got quite a few moving parts there as is and most of what I
> come up with seems like it would not work reliably, at least for automatically
> repairing the eeprom.
I'm confused as to why this is hard to fix in userspace. You already
said you have userspace code binding to the proper VID/PID, so your code
won't find the bricked device. Then it's just a matter of having a udev
rule run the unbricker when it detects the bad device (which should
issue a USB reset when it's done reprogramming, making the device appear
as the right VID/PID), thus effectively doing the same thing the kernel
does. If this is embedded and not using udev, then substitute whatever
equivalent you have. If you're polling for the device at runtime instead
and don't have a device manager, just poll for the VID 0 device too and
apply the fix.
I can't think of a scenario where this would be difficult to fix in
userspace...
--
Hector Martin (hector@...cansoft.com)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists