This is based on a patch by Taras Drozdovsky.  Basically, the delay that was added during the integration of the CDC/ACM host driver was interfering with streaming audio.  That delay was put there to prevent build endpoints from hogging the system bandwidth.  So what do we do?  Do we hog the bandwidth or do we insert arbitrarity delays.  I think both ideas such.

network IOCTL commands:  The only place in net/netdev/netdev_ioctl.c where the interface state should change is for SIOCSIFFLAGS. the other ones .. SIOCSIFADDR, SIOSLIFADDR, SIODIFADDR ..  should not change the link state.

binfmt: Fix .dtor memory allocation

Approved-by: Gregory Nutt <gnutt@nuttx.org>

Jira: PDFW15IS-265
Coverity-ID: 11053
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>

net procfs: Fix buffer corruption and refactor netdev_statistics.c

Approved-by: Gregory Nutt <gnutt@nuttx.org>

Signed-off-by: Masayuki Ishikawa <masayuki.ishikawa@gmail.com>

IOBs: Fix build break

Approved-by: Gregory Nutt <gnutt@nuttx.org>

Signed-off-by: Masayuki Ishikawa <masayuki.ishikawa@gmail.com>

Signed-off-by: Masayuki Ishikawa <masayuki.ishikawa@gmail.com>

STM32 Ethernet: Should not stm32_phyintenable() return a failure if it could not enable the PHY interrupt?

stm32_serial: fix freezing serial port.  Serial interrupt enable/disable functions do not disable interrupts and can freeze device when serial interrupt is received while execution is at those functions.

Trivially triggered with two or more threads write to regular syslog stream and to emergency stream. In this case, freeze happens because of mismatch of priv->ie (TXEIE == 0) and actually enabled interrupts in USART registers (TXEIE == 1), which leads to unhandled TXE interrupt
and causes interrupt storm for USART.

syslog: Add header file inclusion to eliminate a warning; mm/iob: private function needs static storage class.

There can be a failure in IOB allocation to some asynchronous behavior caused by the use of sem_post().  Consider this scenario:

Task A holds an IOB.  There are no further IOBs.  The value of semcount is zero.
Task B calls iob_alloc().  Since there are not IOBs, it calls sem_wait().  The v
alue of semcount is now -1.

Task A frees the IOB.  iob_free() adds the IOB to the free list and calls sem_post() this makes Task B ready to run and sets semcount to zero NOT 1.  There is one IOB in the free list and semcount is zero.  When Task B wakes up it would increment the sem_count back to the correct value.

But an interrupt or another task runs occurs before Task B executes.  The interrupt or other tak takes the IOB off of the free list and decrements the semcount.  But since semcount is then < 0, this causes the assertion because that is an invalid state in the interrupt handler.

So I think that the root cause is that there the asynchrony between incrementing the semcount.  This change separates the list of IOBs:  Currently there is only a free list of IOBs.  The problem, I believe, is because of asynchronies due sem_post() post cause the semcount and the list content to become out of sync.  This change adds a new 'committed' list:  When there is a task waiting for an IOB, it will go into the committed list rather than the free list before the semaphore is posted.  On the waiting side, when awakened from the semaphore wait, it will expect to find its IOB in the committed list, rather than free list.

In this way, the content of the free list and the value of the semaphore count always remain in sync.

wireless/ieee802154: Restructuring of MAC notifications. Simplifes some interfaces

Approved-by: Gregory Nutt <gnutt@nuttx.org>

drivers/bch: BCH character driver bch_ioctl() always returns -ENOTTY for DIOC_GETPRIV command.  It should returns OK if DIOC_GETPRIV command succeeds.

I had the problem that the transmit FIFO size (= actual elements in FIFO) was slowly increasing over time, and was full after a few hours.

The reason was that the code hit the line "canerr("ERROR: No available mailbox\n");" in stm32_cansend, so can_xmit thinks it has sent the packet to the hardware, but actually has not. Therefore the transmit interrupt never happens which would call can_txdone, and so the size of the FIFO size does not decrease.

The reason why the code actually hit the mentioned line above, is because stm32can_txready uses a different (incomplete) condition than stm32can_send to determine if the mailbox can be used for sending, and thus can_xmit forwards the packet to stm32can_send. stm32can_txready considered mailboxes OK for sending if the mailbox was empty, but did not consider that mailboxes may not yet be used if the request completed bit is set - stm32can_txinterrupt has to process these mailboxes first.

Note that I have also modified stm32can_txinterrupt - I removed the if condition, because the CAN controller retries to send the packet until it succeeds. Also if the condition would not evaluate to true, can_txdone would not be called and the FIFO size would not decrease also.