On 12/9/20 9:24 PM, Christian Gagneraud wrote: >> I don't know if you have to implement the polling yourself or if there is a >> polling helper. I'll ask my co-workers. >> >> Is that a Interrupt Transfer Endpoint or a normal Bulk Endpoint? > > AFAIU the firmware, it's just a normal Bulk Endpoint, which i think is > the problem. Yes, with an Interrupt Endpoint things would be easier. >>> I have the feeling that current drivers are for devices that can >>> return data by just scheduling read transfer. >> >> Yes. Current drivers get notified by the device, if there is a CAN frame waiting. >> >>> Anyone would have a clue on how these drivers work, and if my device >>> is really that special? >> >> Yes, your device is quite special :) > > Hum, no good news... > > The device has 3 interfaces: > - keyboard > - mouse > - device specific (CAN) I think you have to implement the polling yourself. Start a transfer on ndo_open(). In the completion handler handle the received data. In case you have recieved a CAN frame, submit a new transfer in case you haven't received data yet, schedule delayed work with a delay, e.g. 1ms. Once you have that running you have fine tune the number of running transfers and delays. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
