debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
When using the serial framework buffer, if the buffer is full, excess
data is cached in the usb req buffer. The CDCACM driver doesn't know
when the upper layer will read data from the serial buffer, so it
needs to periodically check if the cached data can be put into the
serial buffer. However, when using zero-copy, each usb req buffer
needs to be completely read before actively switching to the next
req buffer, so the timer is not needed to assist to query.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
in cdcacm_sndpacket, If `if (priv->wrcontainer)` is true, then
`priv->wrcontainer` is set to NULL. If an interrupt occurs before
`priv->wrcontainer` is reassigned after being NULL,
`priv->wrcontainer` will be reassigned once during the interrupt,
and `nwrq--` will be called, but no data will be sent at this time.
Only when data is sent by calling `txint` will `priv->wrcontainer`
be reassigned and `nwrq--` called again. This causes the issue.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
When CONFIG_CDCACM_DISABLE_TXBUF is enabled, if the USB is
unplugged during serial data transmission, it is possible
that cdcacm will enter the unbind process, and reqbuf will
be released, causing a crash during serial write.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
When enable CONFIG_CDCACM_DISABLE_TXBUF, dev->xmit.buffer always
take one req, so just compare CONFIG_CDCACM_NWRREQS - 1.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
usbdev/cdcacm.c:2974:3: runtime error: null pointer passed as argument 2, which is declared to never be null
#0 0x44716307 in cdcuart_dmasend usbdev/cdcacm.c:2974
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
When close the serial tool in PC, only the persent bit is cleared
on Windows but all bits are cleared on linux.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
This protects the driver in case multiple threads are trying to initialize
or uninitialize the cdcacm concurrently.
Note that this only protects the case when the private pointer is not managed
outside the kernel. If someone has acquired the pointer to the driver and uses
that, it also needs to manage the protection itself if needed.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
To be compatible with the previous method, add a buf between cdcacm
and serial. Because when using usbreqbuf directly as the buf of serial,
the amount of data sent may be insufficient due to the limit of the
number of reqs. For example, when the number of reqs is 4, the number
of data send through cdcacm is 5, and each data is a separate USB
packet, if the host does not read in time, resulting in blocking send.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
To be compatible with the previous method, add a buf between cdcacm
and serial. Because when using usbreqbuf directly as the buf of serial,
the amount of data received may be insufficient due to the limit of the
number of reqs. For example, when the number of reqs is 4, the number
of data received through cdcacm is 5, and each data is a separate USB
packet, which should require 5 reqs, resulting in the last number not
being received. If the application always waits for 5 numbers before
performing an operation, this will cause problems.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
In cdcacm, USB req buf is directly used as serial buf, so the getting
buf status operation in ioctl is different from the original serial.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
Use the CDCACM as a SYSLOG output device, send message to remote proc.
If there are more than one CDCACM devices, then a device minor number
may also need to be provided. Default: 0
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
Data form serial framework will be written to usb reqbuf directly,
and data form cdcacm will be read form reqbuf directly.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
Make sure that the cdcacm is disconnected before the usbdev gets unregistered.
Also, check if the device is connected or not in cdcuart_txempty (uart_txempty). Otherwise there may be a crash during uart_tcdrain, called in tty close path, if the usbdev unregistration happens during the loop.
This issue can be triggered by monitoring the cable connection status in one thread, sending BOARDIOC_USBDEV_DISCONNECT if the usb cable is detached. In another thread close the ttyACM.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
The request length may not exceed CONFIG_CDCACM_BULKIN_ lenghts, otherwise buffer overflow will occur
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Some USB controllers can receive or send multiple data packets then
generate one interrupt. This mechanism can reduce the number of data
copies. Extend req buf to accommodate this.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
When usb is re-enumerated due to the reset signal, we need to push
the rx_pending message into the serial port buffer.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
In usbclass_unbind, DEV_FREEEP is called first, and later
usbclass_freereq does not free memory due to ep NULL
Signed-off-by: sunkun3 <sunkun3@xiaomi.com>
config value changed after resetconfig was executed
endpoint will stay disable state after setinterface cmd
Signed-off-by: sunkun3 <sunkun3@xiaomi.com>
