linux-kernel - Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0bcb0208-04bc-40c8-7b42-56b4dcf93f21@marcansoft.com>
Date:   Fri, 11 Sep 2020 04:54:08 +0900
From:   Hector Martin <hector@...cansoft.com>
To:     James Hilliard <james.hilliard1@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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 11/09/2020 03.51, James Hilliard wrote:
> I haven't tested this yet but my assumption was that either a kernel driver
> or libusb can issue usb control messages, but both can not be bound to
> a device at the same time. I figured this wouldn't have come up when you
> tested your python script since the script likely predated adding the brick PID
> to the ftdi_sio Linux kernel driver.

Binding to interfaces is exclusive, but global device control messages 
are not issued to an interface. I think it should work even if the 
kernel driver is bound (this is how lsusb works too, since it issues 
control requests even to devices bound to drivers). Even if it is 
necessary to unbind it, though, libusb already provides a single 
function to do that (libusb_detach_kernel_driver).

-- 
Hector Martin (hector@...cansoft.com)
Public Key: https://mrcn.st/pub