There was a reference counting problem in the TPC logic of net_clone().  net_clone() which is the common logic underlying dup() and dup2() for sockets.  When net_clone() calls net_start_monitor() and net_start_monitor() returns a failure (because the underlying TCP connection) then net_clone() must back out the reference count on the structure.  Problem noted by Pascal Speck and this implementation of the solution is based on his suggestion.

drivrs/mtd/filemtd.c: add block device MTD interface.  Block MTD interface allows using block device directly as MTD instead of having to use file-system in between.  NOTE that this provides the opposite capability of FTL which will let you use an MTD interface directly as a block device.

drivers/ioexpander:  The IRQ subsystem now supports passing a void * parameter to IRQ handlers.  Use that method to support multiple pc9555 devices, by passing a pointer to the device to the board defined irq handler.  Now the CONFIG_ for multiple PCA devices just allocates device structures dynamically instead of statically when not enabled.

The same interrupt handler is entered with the device structure parameter in all situations,
multiple or single PCA. One should still be careful if multiple PCA devices share the same IRQ.

The timer frequencies (BOARD_TIMx_FREQUENCY) are incorrectly defined in configs/stm3240g-eval/include/board.h.  Since the APB prescalers are set to divide by 4 and 2 respectively, the frequencies should be "2xAPBx" as said in the comment.  The correct frequencies are already defined but as STM32_APBx_TIMx_CLKIN.

Lower part of STM32 CAN driver arch/arm/src/stm32/stm32_can.c uses all three hw tx mailboxes and clears TXFP bit in the CAN_MCR register (it means transmission order is defined by identifier and mailbox number).

This creates situation when order frames are put in upper part of CAN driver (via can_write) and order frames are sent on bus can be different (and I experience this in wild).

Since CAN driver API pretends to be "file like" I expect data to be read from fd the same order it is written. So I consider described behaviour to be a bug.

I propose either to set TXFP bit in the CAN_MCR register (FIFO transmit order) or to use only one mailbox.

BCM2708:  The PiZero configuration now compiles and links cleanly.  Still a few thngs missing internally.

photon: Support SPI1 and SPI3

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

drivers/usbdev:  Move test for NULL pointer before the pointer is deferences.  Noted by Juha Niskanen.

fs/vfs:  Fix after recent changes.  write() was return negative values in errno. Noted by Jussi Kivilinna.

drivers/usbdev: Correct input flow control logic when watermarks are not enabled.  Problem not by and change based on suggestion by Juha Niskanen.

BCM2708: Add system timer register definitions and a partial implementation of the tickless mode timer.

Stm32 rtc small patches

* RTC: canceling an alarm marks it as inactive

* STM32L4, STM32F4, STM32F7 RTC: fix reading alarm value that is more than 24h in future

* STM32F0 RTC: fix backup register count in stm32_rtcc.h

    All other STM32: SHIFTR_SUBFS_MASK was correct in STM32F0 only

* STM32L1: use correct EXTI line definitions

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

Update last commit... Check should really use the definition MMSIZE_MAX which is really the same thing, but guaranteed to be the correct maximum size in any present and future configuration.

If size is greater than (UINT32_MAX - SIZEOF_MM_ALLOCNODE), malloc size can be overflow by MM_ALIGN_UP macro.  For example, if task_create() called with stack_size == -1, up_create_stack() functions allocates SIZEOF_MM_ALLOCNODE bytes for stack.
This can cause data abort in up_stack_color() function.

kthread_create():  Rename kernel_thread() to kthread_create() for better naming consistency with task_create() and kthread_delete().

Initial ADC support for the STM32F33XX

* stm32_adc.h: add JEXTSEL definitions and hrtim trigger configuration

* stm32_adc.c: move STM32F33 ADC logic to a separate file

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