USB endpoint bufsz can prevent large i2c transfers

[azanegin]

If you getting EOVERFLOW out of nowhere - be aware of this line:

ft2232-mpsse-i2c-spi-kern-drivers/i2c-ftdi/i2c-ftdi.c

Line 45 in 923b705

const size_t FTDI_IO_BUFFER_SIZE = 65536;

Most likely your FTDI device is using USB <= 2.0. Bulk endpoints of USB 2.0 devices is limited in size by 512 bytes (check your actual size). AFAIK on (older?) linux kernels, buffer size to use with usb_bulk_msg must not be larger than endpoint buffer.

JUST setting FTDI_IO_BUFFER_SIZE to endpoint size could cause other problems, plus you will lose speed at USB 3.0

I temporarily fixed it like this:

static int ftdi_mpsse_read(struct ftdi_usb *ftdi, u8 *data, size_t size, size_t *read)
{
        int actual_length;
        int ret;
        int sz_real = min(512, size);

        ret = usb_bulk_msg(
                ftdi->udev,
                usb_rcvbulkpipe(ftdi->udev, ftdi->ep_in),
                /* data = */data,
                /* len = */sz_real,
                /* actual_length = */&actual_length,
                ftdi->io_timeout
        );
        *read = actual_length;
        return ret;
}

It worked cuz caller functions take care of large buffers themselves.

[bm16ton]

Awesome! Thank you so much! Besides a spelling mistake this i believe is my first time receiving fixes, very cool. I personally hadnt seen this issue so was totally unaware! i will hopefully be able to apply/test/update this weekend. Thankyou again.

…

On Wed, Nov 23, 2022 at 9:56 AM Alex Zanegin ***@***.***> wrote: If you getting EOVERFLOW out of nowhere - be aware of this line: https://github.com/bm16ton/ft2232-mpsse-i2c-spi-kern-drivers/blob/923b7059795bcba5d82a3ae0a9fc7de93c20df03/i2c-ftdi/i2c-ftdi.c#L45 Most likely your FTDI device is using USB <= 2.0. Bulk endpoints of USB 2.0 devices is limited in size by 512 bytes (check *your* actual size). AFAIK on (older?) linux kernels, buffer size to use with usb_bulk_msg must not be larger than endpoint buffer. *JUST* setting FTDI_IO_BUFFER_SIZE to endpoint size could cause other problems, plus you will lose speed at USB 3.0 I temporarily fixed it like this: static int ftdi_mpsse_read(struct ftdi_usb *ftdi, u8 *data, size_t size, size_t *read) { int actual_length; int ret; int sz_real = min(512, size); ret = usb_bulk_msg( ftdi->udev, usb_rcvbulkpipe(ftdi->udev, ftdi->ep_in), /* data = */data, /* len = */sz_real, /* actual_length = */&actual_length, ftdi->io_timeout ); *read = actual_length; return ret; } It worked cuz caller functions take care of large buzzers themselves. — Reply to this email directly, view it on GitHub <#3>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAWMP44PKDKPTUB2LPLBNLWJYWDFANCNFSM6AAAAAASJBZT2Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bm16ton]

Hopefully ill have time to check this out tomorrow (fingers crossed) any chance you could describe the setup you used to get the error so i could recreate this? Unfortunatly the offending line etc was a copy and paiste error. Early in this drivers life i had written it without any header file or human readable defines, i copied and paisted them from another persons driver, that driver didnt work for my devices and was a usb low speed device, and i just missed it. So do usb2 devices somehow get more msg bandwidth on usb3 ports? I would not have guessed that. I was under the assumption that usb2 devices connected to usb3 ports simply get routed to regular usb2 bus. Thank you again and i always like to ha e test setups that i kknow break certain things so that could be very useful

[azanegin]

[I2C device]------[I2C lines - FT232H(The Shikra) - USB2.0 port]----------<USB2.0 cable>----------[USB3.0 port on PC under Linux 5.19]

This is my setup, hope it helps. AFAIK the problem is with large reads from small endpoint, but I do not know USB stack that good to tell it right away - I just googled and tried to fix.