All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hector Martin <hector@marcansoft.com>
To: James Hilliard <james.hilliard1@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, Johan Hovold <johan@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 17:10:20 +0900	[thread overview]
Message-ID: <ca3dfd1e-b595-18aa-3442-30363b2e2797@marcansoft.com> (raw)
In-Reply-To: <CADvTj4pZKeic1-Yb_baJkbfn8UWXczuoSRXqhH_1qHB=NV4FjA@mail.gmail.com>

On 10/09/2020 15.45, James Hilliard wrote:
>>> +static int ftdi_write_eeprom(struct usb_serial_port *port, u8 addr, u16 data)
>>> +{
>>> +     struct usb_device *udev = port->serial->dev;
>>> +     int rv;
>>> +
>>> +     rv = usb_control_msg(udev,
>>> +                          usb_sndctrlpipe(udev, 0),
>>> +                          FTDI_SIO_WRITE_EEPROM_REQUEST,
>>> +                          FTDI_SIO_WRITE_EEPROM_REQUEST_TYPE,
>>> +                          data, addr,
>>> +                          NULL, 0, WDR_TIMEOUT);
>>> +     if (rv < 0)
>>> +             dev_err(&port->dev, "Unable to write EEPROM: %i\n", rv);
>>
>> You don't check for a "short write"?
>  From my understanding the hardware only accepts 2 byte writes, and
> the non-counterfeits actually only commit writes on odd addresses
> while they buffer writes on even(this difference is what FTDI's windows
> driver exploits). So I guess this should be "if (rv < 2)"?

It's not "data" anyway, the data word gets sent in control message 
headers. Unless I'm mistaken rv == 0 on success, so the code should be 
correct as-is.

>>
>>> +     return rv;
>>> +}
>>> +
>>> +static u16 ftdi_checksum(u16 *data, int n)
>>> +{
>>> +     u16 checksum;
>>> +     int i;
>>> +
>>> +     checksum = 0xaaaa;
>>> +     for (i = 0; i < n - 1; i++) {
>>> +             checksum ^= be16_to_cpu(data[i]);
>>> +             checksum = (checksum << 1) | (checksum >> 15);
>>> +     }
>>
>> What type of function is this, don't we have all of the needed checksum
>> functions in the kernel already?
> Some custom crc16 style checksum I guess, I'm not seeing anything
> in the kernel that's the same, although I might not be looking in the
> right places.

This isn't a CRC, it's some random xor all the words thing with a 
somewhat pointless rotation in the way. I'd be surprised if anything 
elses uses this particular function. Pretty sure other drivers are 
littered with stuff like this too, hardware manufacturers love to 
reinvent checksums.

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

      reply	other threads:[~2020-09-10  8:10 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
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 [this message]

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=ca3dfd1e-b595-18aa-3442-30363b2e2797@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=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.