From: Hector Martin <hector@marcansoft.com>
To: James Hilliard <james.hilliard1@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johan Hovold <johan@kernel.org>, Lars Melin <larsm17@gmail.com>,
Oliver Neukum <oneukum@suse.de>,
linux-usb@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Russ Dill <Russ.Dill@gmail.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
Date: Thu, 10 Sep 2020 18:57:47 +0900 [thread overview]
Message-ID: <26a723e4-e166-6377-875a-f737a15dc6b1@marcansoft.com> (raw)
In-Reply-To: <CADvTj4pYR9H1X1_f4DYTkb5ViXAdx9sO5yBgHgM5vFaDMs_miQ@mail.gmail.com>
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@marcansoft.com)
Public Key: https://mrcn.st/pub
next prev parent reply other threads:[~2020-09-10 9:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 19:34 [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom James Hilliard
2020-09-10 3:02 ` Oliver Neukum
2020-09-10 3:17 ` Hector Martin "marcan"
2020-09-10 3:46 ` James Hilliard
2020-09-10 3:49 ` Hector Martin "marcan"
2020-09-10 4:39 ` James Hilliard
2020-09-10 3:40 ` James Hilliard
2020-09-10 3:46 ` Hector Martin "marcan"
2020-09-10 4:07 ` James Hilliard
2020-09-10 5:33 ` Lars Melin
2020-09-10 6:48 ` James Hilliard
2020-09-10 8:01 ` James Hilliard
2020-09-10 8:08 ` Johan Hovold
2020-09-10 8:17 ` James Hilliard
2020-09-10 8:55 ` Greg Kroah-Hartman
2020-09-10 9:52 ` James Hilliard
2020-09-10 9:57 ` Hector Martin [this message]
2020-09-10 18:51 ` James Hilliard
2020-09-10 19:54 ` Hector Martin
2020-09-11 6:09 ` Greg Kroah-Hartman
2020-09-10 5:49 ` Greg Kroah-Hartman
2020-09-10 6:45 ` James Hilliard
2020-09-10 8:10 ` Hector Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26a723e4-e166-6377-875a-f737a15dc6b1@marcansoft.com \
--to=hector@marcansoft.com \
--cc=Russ.Dill@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.hilliard1@gmail.com \
--cc=johan@kernel.org \
--cc=larsm17@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).