On 10.03.2021 11:18:15, Stéphane Grosjean wrote: > To complete the open reflection on this subject: to be perfect, the > echo skb should in fact not be released by the USB write completion > routine but, like the PCI/PCIe version, on reception in the Rx queue > of an echo frame to the one written... If you don't have a TX complete notification, this would be a workaround to let the TX echo better reflect what's going on on the bus. > This means : > 1 - the core of the peak_usb driver has to be deeply modified > 2 - the rx path of the USB interface will be much more loaded, > resulting in a higher CPU load > 2 - in the case of a one-shot frame, how to manage the fact that this > echo frame is never received because the one-shot frame could not > be written on the bus? Does this need a garbage collector on the > echo skbs? Yes, you have to free the echo skb in case of a no-send due to one-shot mode. Does the HW offer a TX aborted notification? > Is it worth it? If you don't have TX complete or TX abort notifications, then it's not worth it. Better spend time implementing these notifications on the controller side :) regards, 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: PGP signature
