Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200909193419.2006744-1-james.hilliard1@gmail.com>
 <1599706954.10822.3.camel@suse.de> <D2C1360E-65CC-410A-8B39-48F7340FEFCE@marcansoft.com>
In-Reply-To: <D2C1360E-65CC-410A-8B39-48F7340FEFCE@marcansoft.com>
From:   James Hilliard <james.hilliard1@gmail.com>
Date:   Wed, 9 Sep 2020 21:46:20 -0600
Message-ID: <CADvTj4o-T92C0bO6Bp9p1N-CjX80nzL+y6bPfosMqU2ftdex8Q@mail.gmail.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
To:     Hector Martin marcan <hector@marcansoft.com>
Cc:     Oliver Neukum <oneukum@suse.de>, linux-usb@vger.kernel.org,
        Johan Hovold <johan@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Russ Dill <Russ.Dill@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Sep 9, 2020 at 9:17 PM Hector Martin "marcan"
<hector@marcansoft.com> wrote:
>
>
>
> On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum <oneukum@suse.=
de> wrote:
> >Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> >> This patch detects and reverses the effects of the malicious FTDI
> >> Windows driver version 2.12.00(FTDIgate).
> >
> >Hi,
> >
> >this raises questions.
> >Should we do this unconditionally without asking?
> >Does this belong into kernel space?
>
> I agree; this is very cute, but does it really need to be an automatic Li=
nux feature? Presumably someone looking to fix a bricked FTDI chip can just=
 run my script, and those who just want to use those chips with Linux alrea=
dy can since the driver binds to the zero PID.
Well for one your script is not easily useable with embedded platforms
like mine where I ran into this issue, I have no python2 interpreter
available in my production builds.
>
> I am deeply amused by the idea of Linux automatically fixing problems cau=
sed by malicious Windows drivers, but thinking objectively, I'm not sure if=
 that's the right thing to do.
From my understanding Linux fixing up hardware issues caused
by faulty/weird Windows drivers isn't exactly unusual.
>
> >
> >> +static int ftdi_repair_brick(struct usb_serial_port *port)
> >> +{
> >> +    struct ftdi_private *priv =3D usb_get_serial_port_data(port);
> >> +    int orig_latency;
> >> +    int rv;
> >> +    u16 *eeprom_data;
> >> +    u16 checksum;
> >> +    int eeprom_size;
> >> +    int result;
> >> +
> >> +    switch (priv->chip_type) {
> >> +    case FT232RL:
> >> +            eeprom_size =3D 0x40;
> >> +            break;
> >> +    default:
> >> +            /* Unsupported for brick repair */
> >> +            return 0;
> >> +    }
> >> +
> >> +    /* Latency timer needs to be 0x77 to unlock EEPROM programming */
> >> +    if (priv->latency !=3D 0x77) {
> >> +            orig_latency =3D priv->latency;
> >> +            priv->latency =3D 0x77;
> >> +            rv =3D write_latency_timer(port);
> >> +            priv->latency =3D orig_latency;
> >> +            if (rv < 0)
> >> +                    return -EIO;
> >> +    }
> >
> >Do you really want to change this without returning to the original?
> >
> >       Regards
> >               Oliver
>
> --
> Hector Martin "marcan" (hector@marcansoft.com)
> Public key: https://mrcn.st/pub