Gracefully handle output queue full conditions. This shouldn't happen
in practice as the host is supposed to limit the number of commands
simultaneously in execution.
Reset the response queue on RNDIS_RESET_MSG. This way communication
can recover even if host and device get out of sync.
Sometimes Windows would send RNDIS_KEEPALIVE_MSG and RNDIS_QUERY_MSG close
to each other. This would cause the latter command to overwrite the reply for
the prior command. This in turn will cause Windows to drop the connection after
a 20 second timeout.
Easy way to reproduce the issue is to open the Windows "Adapter Status" dialog that
shows the realtime TX/RX byte counts. This causes multiple RNDIS_QUERY_MSGs per
second, and the connection will drop in less than an hour.
This commit fixes this issue, and other potential race conditions (such as USB
descriptor read in middle on RNDIS query) by using a separate queue for the reply
packets.
David Sidrane has submitted the ICL and we can migrate the licenses
to Apache.
Gregory Nutt has submitted the SGA and we can migrate the licenses
to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
David S. Alessio has submitted the ICL and we can migrate the licenses
to Apache.
Gregory Nutt has submitted the SGA and we can migrate the licenses
to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Sebastien Lorquet has submitted the ICL and we can migrate the licenses
to Apache.
Gregory Nutt has submitted the SGA and we can migrate the licenses
to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
drivers/sensors/qencoder.c:
* qe_close(): Call to sninfo() contained extraneous "%d"
format specifier. Removing it, as it appears there was
never a matching argument.
Because buflen is size_t (unsigned) and nsent is ssize_t (signed)
of the same size, (buflen - nsent) results in unsigned and
overflows if nsent > buflen.
This happens when sending CAN FD frame with DLC > 8 and a user
gets the buflen parameter as a result of CAN_MSGLEN(len)
where `len' is the size of data which is less then a size
for some extended DLC (e.g. 26 bytes is sent in a message with
DLC 0xD, which has 32 bytes of data).
The correct buflen value should be rather
CAN_MSGLEN(can_dlc2bytes(can_bytes2dlc(len)))
Signed-off-by: Jaroslav Beran <jara.beran@gmail.com>
Alan Carvalho de Assis has submitted the SGA and we can migrate the licenses
to Apache.
Gregory Nutt has submitted the SGA and we can migrate the licenses
to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
mmcsd:Remove CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
stm32h7:sdmmc remove CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
stm32f7:sdmmc remove CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
stm32f7:sdmmc WRITE COMPLETE prevent false triggers
stm32h7:sdmmc WRITE COMPLETE prevent false triggers
While testing PR #2989 on the H7 I noticed that the cards
were staying in 1-bit mode. The root cause was that the
scr read path was using DMA without an invlidate.
This was caused by CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT,
but the sdmmc driver, did not use the delayed invalidate
nor would it work on 8 bytes.
The driver fully supported dcache mgt on runt buffers, but
the #ifdef CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT blocked it.
Reviewing the PR that added CONFIG_ARCH_HAVE_SDIO_DELAYED_INVLDT
it may have been valid at the time. But after the dcache operations
we fixed. It is not necessary and offers no benefit.
serial/serial_dma.c: In function ‘uart_recvchars_done’:
serial/serial_dma.c:407:7: warning: implicit declaration of function ‘nxsig_kill’ [-Wimplicit-function-declaration]
407 | nxsig_kill(dev->pid, signo);
| ^~~~~~~~~~
Change-Id: I9e1c0341ecce3033889d11fff9ec2b9e3dfe303b
user should select the default action by self:
warning: (TTY_SIGINT) selects SIG_SIGKILL_ACTION which has unmet direct dependencies (SIG_DEFAULT)
Change-Id: Ied9899d18156742ce4998b40d53a481262dcd84a
Signed-off-by: ligd <liguiding1@xiaomi.com>
Reason:
nx_start use syslog at every early time event the idle thread not
full setup, then syslog_rpmsg -> work_queue -> work_signal ->
nxsig_kill -> rtcb is NULL -> crash
Fix:
sched work_queue after is_rpmsg_ept_ready() is true
Change-Id: I225469ff2526e4b810bf3e23473b55d57e64a1ff
Signed-off-by: ligd <liguiding1@xiaomi.com>
since sometime platform code need do some special action during memcpy
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Id108ef4232376feab3e37e9b3aee9a7927a03bd4
and remove the reference of CONFIG_ARCH_HAVE_PROGMEM from code
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I89a73f138d54718ee8bc9345958675d7a2a34ba8
This change reflects that the geometry isn't related to the largest
allocatable unit on the platform.
Calls to read and write block devices are also affected and have
been updated.
Summary:
- This commit introduces a driver-specific spinlock to cxd56.c
to improve performance in SMP mode.
Impact:
- cxd56.c in SMP mode only
Testing:
- Tested with nxplayer and nxrecorder with the following configs
- spresense:wifi, spresense:wifi_smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit changes spinlock APIs (spin_lock_irqsave/spin_unlock_irqrestore)
- In the previous implementation, the global spinlock (i.e. g_irq_spin) was used.
- This commit allows to use caller specific spinlock but also supports to use
g_irq_spin for backword compatibility (In this case, NULL must be specified)
Impact:
- None
Testing:
- Tested with the following configurations
- spresnse:wifi, spresense:wifi_smp
- esp32-devkitc:smp (QEMU), sabre6-quad:smp (QEMU)
- maxi-bit:smp (QEMU), sim:smp
- stm32f4discovery:wifi
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- During Wi-Fi stress test, I noticed that ASSERT() happened
in gs2200m_hal_write(). Actually, this happens in 20-40 hours.
- In this case, resp[1] was always 0x0 which is not defined
in the spec.
- In the previous implementation, retry was only done in case of
WR_RESP_NOK. (0x13)
- This commit changes this condition and it reties in case of
0x0 as well
Impact:
- gs2200m driver
Testing:
- Tested with spresense:wifi_smp and stm32f4discovery:wifi
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
The ifstate is already set in
enc_ifup -> enc_reset -> enc_linkstatus
The ifstate after this call is either ENCSTATE_RUNNING or ENCSTATE_UP
If ifstate is ENCSTATE_RUNNING, it would be wrong to set it to ENCSTATE_UP;
this would lead to enc_txavail never invoking the driver callback, causing
very long latencies in sending.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Petteri Aimonen