bm16ton / ft2232-mpsse-i2c-spi-kern-drivers

linux kernel drivers for ft2232 spi and i2c
28 stars 9 forks source link

USB endpoint bufsz can prevent large i2c transfers #3

Open azanegin opened 1 year ago

azanegin commented 1 year ago

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 buffers themselves.

bm16ton commented 1 year ago

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 https://github.com/bm16ton/ft2232-mpsse-i2c-spi-kern-drivers/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP44PKDKPTUB2LPLBNLWJYWDFANCNFSM6AAAAAASJBZT2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

bm16ton commented 1 year ago

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 commented 1 year ago

[I2C device]------[I2C lines - FT232H(The Shikra) - USB2.0 port]--------------------[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.