since the related code was removed by:
commit 4d5a964f29
Author: Jiuzhu Dong <dongjiuzhu1@xiaomi.com>
Date: Tue Feb 23 18:04:13 2021 +0800
net: unify socket into file descriptor
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
We load the code into NuttX heap, which can be too far from
the usual code segments for the relocation types used by the
default "small" model to reach.
This worked around out of range relocations seen with my local app.
current implementation incorrectly update CURRENT_REGS to interrupt context if
trigger nested interrupt, (e.g, hard fault occurs during interrupt handling)
this would ambiguous for programs using CURRENT_REGS, this patch will prohibit
the update of CURRENT_REGS on nested interrupt handling
Signed-off-by: chao.an <anchao@xiaomi.com>
and removed two tcp_send_txnotify() calls from tcp_sendfile (they are not needed anymore).
As a result, the TX throughput of both the tcp_send_buffered and tcp_send_unbuffered
is significantly boosted in case of TUN/TAP network device.
Basically, mirror the following two commits from modlib.
It's shame we have two copies of elf loaders.
```
commit 51490bad55
Author: YAMAMOTO Takashi <yamamoto@midokura.com>
Date: Wed Apr 14 17:07:39 2021 +0900
modlib: Implement sh_addralign handling
I've seen a module with 16 bytes .rodata alignment for xmm operations.
It was getting SEGV on sim/Linux because of the alignment issue.
The same module binary seems working fine after applying this patch.
Also, tested on sim/macOS and esp32 on qemu,
using a module with an artificially large alignment. (64 bytes)
```
```
commit 418e11b8b3
Author: YAMAMOTO Takashi <yamamoto@midokura.com>
Date: Thu Apr 15 11:33:48 2021 +0900
modlib: Always use separate allocation for text and data
Pros:
* Reduce code differences
* Smaller allocations for !CONFIG_ARCH_USE_MODULE_TEXT
Cons:
* Likely to use more memory for !CONFIG_ARCH_USE_MODULE_TEXT in total
Tested with:
* sim:module on macOS
* esp32-devkit:nsh + CONFIG_MODULE on qemu
* lm3s6965-ek:qemu-protected + CONFIG_EXAMPLES_SOTEST on qemu
```
Some PPG devices have 4 ADCs to output quad-channel PPG values while some of them only have 2 ADCs to output dual-channel PPG.
To deal the case above, the type PPGD(PPG of Dual-channel) takes the place of former type PPG, which also have 2-channel PPG outputs. Type PPGQ (PPG of Quad-channel) is new for 4-ADC-PPG. Both types have contained new data "gain" to indicate ADC gains of each PPG channel, for the reason that the gains may vary during automatical optical adjustments.
Signed-off-by: liucheng5 <liucheng5@xiaomi.com>