On 02.09.2024 15:03:49, rednaxelA xelA wrote: > Hello Marc, > > Thank you for your reply. The description for necessarily of this change > can be seen below: > > > There is an approach made to implement gs_usb firmware/driver based on > Zephyr RTOS. It was found that USB stack of Zephyr RTOS overwrites USB EP > addresses, if they have different last 4 bytes in absence of other > endpoints. > For example in case of gs_usb candlelight firmware EP-IN is 0x81 and EP-OUT > 0x02. If there are no additional USB endpoints, Zephyr RTOS will overwrite > EP-OUT to 0x01. More information can be found in the discussion with Zephyr > RTOS USB stack maintainer here: > https://github.com/zephyrproject-rtos/zephyr/issues/67812 > In the end USB stack maintainer refuses to change this behavior and points > out on wrong driver implementation made by linux. Thus I have only this > last option to provide gs_usb driver linux kernel patch. > Additionally there are already two different gs_usb FW driver > implementations based on Zephyr RTOS. > 1. The first one implementation is done by Henrik and can be found here: > https://github.com/CANnectivity/cannectivity > 2. The second one implementation is done by me and can be found here: > https://github.com/zephyrproject-rtos/zephyr/compare/main...KozhinovAlexander:zephyr:gs_usb > > At the moment both Zephyr RTOS implementations use dummy USB endpoint, to > overcome described USB stack behavior from Zephyr itself. Since Zephyr RTOS > is intended to be used on microcontrollers with very constrained amount of > resources (ROM, RAM) and additional endpoint requires memory, it is more > convenient to add a patch to linux kernel's gs_usb driver. > > Please do not hesitate to ask me more questions and/or point out, what I > can do better. This is my first publicly available patch for linux kernel :) Thanks for the excellent description of the problem. Now let's transform this into a commit message that follow the Linux process: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes -------->8-------->8-------->8-------->8-------->8-------->8-------->8-------- There is an approach made to implement gs_usb firmware/driver based on Zephyr RTOS. It was found that USB stack of Zephyr RTOS overwrites USB EP addresses, if they have different last 4 bytes in absence of other endpoints. For example in case of gs_usb candlelight firmware EP-IN is 0x81 and EP-OUT 0x02. If there are no additional USB endpoints, Zephyr RTOS will overwrite EP-OUT to 0x01. More information can be found in the discussion with Zephyr RTOS USB stack maintainer here: https://github.com/zephyrproject-rtos/zephyr/issues/67812 There are already two different gs_usb FW driver implementations based on Zephyr RTOS: 1. https://github.com/CANnectivity/cannectivity (by: https://github.com/henrikbrixandersen) 2. https://github.com/zephyrproject-rtos/zephyr/compare/main...KozhinovAlexander:zephyr:gs_usb (by: https://github.com/KozhinovAlexander) At the moment both Zephyr RTOS implementations use dummy USB endpoint, to overcome described USB stack behavior from Zephyr itself. Since Zephyr RTOS is intended to be used on microcontrollers with very constrained amount of resources (ROM, RAM) and additional endpoint requires memory, it is more convenient to update the gs_usb driver in the Linux kernel. To fix this problem, update the gs_usb driver from using hard coded endpoint numbers to evaluate the endpoint descriptors and use the endpoints provided there. -------->8-------->8-------->8-------->8-------->8-------->8-------->8-------- What do you think? regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Attachment:
signature.asc
Description: PGP signature
