You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by "Schock, Johannes - NIVUS GmbH" <Jo...@nivus.com> on 2020/07/21 13:06:56 UTC
RNDIS Kinetis
Hello,
I have again a little bit time to try out NuttX.
Now I'm facing a problem with the RNDIS driver under Kinetis USB device (K28-Freedom), it is not working.
If I'm not wrong I think I tracked it down: The Kinetis USB device driver doesn't support accompanying data in an nonstandard OUT setup packet.
Has someone already fixed this and can file a PR? If not I will try to fix it.
Regards, Johannes
Re: RNDIS Kinetis
Posted by Gregory Nutt <sp...@gmail.com>.
> Now I'm facing a problem with the RNDIS driver under Kinetis USB device (K28-Freedom), it is not working.
> If I'm not wrong I think I tracked it down: The Kinetis USB device driver doesn't support accompanying data in an nonstandard OUT setup packet.
> Has someone already fixed this and can file a PR? If not I will try to fix it.
That is a problem with several USB device drivers. There is more
description in the top-level TODO list:
1693 Title: EP0 OUT CLASS DATA
1694 Description: There is no mechanism in place to handle EP0 OUT
data transfers.
1695 There are two aspects to this problem, neither are
easy to fix
1696 (only because of the number of drivers that would be
impacted):
1697
1698 1. The class drivers only send EP0 write requests
and these are
1699 only queued on EP0 IN by this drivers. There is
never a read
1700 request queued on EP0 OUT.
1701 2. But EP0 OUT data could be buffered in a buffer in
the driver
1702 data structure. However, there is no method
currently
1703 defined in the USB device interface to obtain the
EP0 data.
1704
1705 Updates: (1) The USB device-to-class interface as
been extended so
1706 that EP0 OUT data can accompany the SETUP request
sent to the
1707 class drivers. (2) The logic in the STM32 F4 OTG FS
device driver
1708 has been extended to provide this data. Updates are
still needed
1709 to other drivers.
1710
1711 Here is an overview of the required changes:
1712 New two buffers in driver structure:
1713
1714 1. The existing EP0 setup request buffer (ctrlreq, 8
bytes)
1715 2. A new EP0 data buffer to driver state structure
(ep0data,
1716 max packetsize)
1717
1718 Add a new state:
1719
1720 3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)
1721
1722 General logic flow:
1723
1724 1. When an EP0 SETUP packet is received:
1725 - Read the request into EP0 setup request buffer
(ctrlreq,
1726 8 bytes)
1727 - If this is an OUT request with data length, set
the EP0
1728 state to EP0STATE_SETUP_OUT and wait to receive
data on
1729 EP0.
1730 - Otherwise, the SETUP request may be processed
now (or,
1731 in the case of the F4 driver, at the conclusion
of the
1732 SETUP phase).
1733 2. When EP0 the EP0 OUT DATA packet is received:
1734 - Verify state is EP0STATE_SETUP_OUT
1735 - Read the request into the EP0 data buffer
(ep0data, max
1736 packet size)
1737 - Now process the previously buffered SETUP
request along
1738 with the OUT data.
1739 3. When the setup packet is dispatched to the class
driver,
1740 the OUT data must be passed as the final
parameter in the
1741 call.
1742
1743 Update 2013-9-2: The new USB device-side driver for
the SAMA5D3
1744 correctly supports OUT SETUP data following the same
design as
1745 per above.
1746
1747 Update 2013-11-7: David Sidrane has fixed with issue
with the
1748 STM32 F1 USB device driver. Still a few more to go
before this
1749 can be closed out.
1750
1751 Status: Open
1752 Priority: High for class drivers that need EP0 data. For
example, the
1753 CDC/ACM serial driver might need the line coding
data (that
1754 data is not used currently, but it might be).