If sched lock before irq save, and irq handler do post, scheduler will
be delayed after WFI until next sched unlock. which is not acceptable.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
pm process should be done by chip specific, but we can provide a standard
flow, then vendor & chip can only focus on handle different state change.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
This fixes syscall instrumentation in flat build:
- add syscall_names.c if LIB_SYSCALL=n to 'wraps'
subdirectory
- change execute_process to add_custom_command
- fix typo in wrapper naming convention
Signed-off-by: Daniel Jasinski <jasinskidaniel95szcz@gmail.com>
critical_section is not compatible with irq disabled, have to delay the
wd_start after spin_unlock_irqrestore.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
In a multicore task scenario, there may be a situation where the task runs on different cores at different time slices (when the task is not bound to a particular core).
When the task calls cache clean/flush(range > cache size), depending on the optimization, clean_all, flush_all are called. however, at this point, there may be dirty data or incomplete data profiles in the cache on the kernel that is running the task, which may result in dirty data being flushed into memory or make the application think that the flushed data should be successfully flushed into memory, leading to unknown consequences.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
In a multicore task scenario, there may be a situation where the task runs on different cores at different time slices (when the task is not bound to a particular core).
When the task calls cache clean/flush(range > cache size), depending on the optimization, clean_all, flush_all are called. however, at this point, there may be dirty data or incomplete data profiles in the cache on the kernel that is running the task, which may result in dirty data being flushed into memory or make the application think that the flushed data should be successfully flushed into memory, leading to unknown consequences.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Execute data and instruction sync barriers after writing MPU register,
to ensure MPU setting take effects that the new changes are seen.
testing in lm3s6965-ek:qemu-protected
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
when the vsync comes, fb drivers should call fb_vsync_pollnotify to notify POLLPRI, so that users can catch the synchronization time of vsync and do something.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
Summary:
Since there is a default definition for CONFIG_SMP_NCPUS in sys/types.h, we can remove #ifdef and return CONFIG_SMP_NCPUS directly.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Summary:
1.Remove the macro definition of getnproc in sysinfo
2.New get_nprocs_conf and get_nprocs interfaces, return CONFIG_SMP_NCPUS, return 1 when not defined
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
add a documented description of the cdcncm device module, including
execution steps and associated outputs
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
1. increase CDCECM_MXDESCLEN to avoid memory overrun when sending
configuration description(mkcfmdesc) information
2. correct the request structure used in the notify phase
3. disable unused configuration options
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
optimize the interaction flow associated with network drivers to reduce
the amount of code and improve compatibility
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
solve the interdependency problem of cross-target dependency generation.
like Makefile base, a PHONY context target is used as a dependency for timing order.
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
When our apps call getifaddrs on lo frequently, the loopback device will failed in SIOCGIFHWADDR and print too many error logs.
Signed-off-by: wangchen <wangchen41@xiaomi.com>
According to the current design on the armv7-a platform,
only fiq is processed in TEE, while irq and fiq are processed
in REE.
If we enable the irq function in TEE, when we process
some signal-related scenarios in TEE,
such as the ostest sighand testcase, this testcase will
call up_irq_enable() to enable irq interrupt in the
arm_sigdeliver() function. After the signal processing
logic is executed, irq will be disabled again.
During the interval of enabling irq, some external device
irq interrupts will be enabled, but these external device
irqs do not have corresponding handlers registered in TEE,
so an "unexpected irq isr exception" will be triggered.
Therefore, a better implementation is to keep the original
implementation of the up_irq_enable() function, that is,
to enable only fiq in TEE and to enable irq and fiq in REE.
Then for vendor-specific requirements, such as the need to
briefly enable irq during the TEE initialization process
and then disable irq before starting APz in TEE, we directly
provide a separate implementation of enabling irq in the
vendor, without modifying the implementation of the public
up_enable_irq() function.
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
The Bluetooth network on N62 does not retransmit packet, so no packet
retransmition if we drop one, we will drop packet when tcp_close_eventhandler
is register and invoke by tcp_input. then we will always early return and
never stop, the peer will only close the connection if we send reset packet.
precondition:
close -> register tcp_close_eventhandler;
tcp_input -> tcp_callback(TCP_NEWDATA) -> devif_conn_event -> tcp_close_eventhandler
-> flags &= ~TCP_NEWDATA -> NOT entry tcp_data_event -> conn->recvreq NOT increase
old flow:
tcp_input -> tcp->seqno greater than conn->rcvseq -> tcp_send(TCP_ACK)
with this patch:
tcp_input -> tcp->seqno greater than conn->rcvseq -> !TCP_ESTABLISHED
-> case TCP_FIN_WAIT_1 -> dev->d_len greater than 0 -> tcp_reset
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
