the previous patch can not handle the revent is POLLHUP or POLLERR,
poll_setup needs to be executed only when the POLLIN or POLLOUT event
changes.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Fix warning:
```
serial/ptmx.c:205:34: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 8 [-Wformat-truncation=]
205 | snprintf(devname, 16, "/dev/pty%d", minor);
|
serial/ptmx.c:205:25: note: directive argument in the range [0, 2147483647]
205 | snprintf(devname, 16, "/dev/pty%d", minor);
| ^~~~~~~~~~~~
serial/ptmx.c:205:3: note: ‘snprintf’ output between 10 and 19 bytes into a destination of size 16
205 | snprintf(devname, 16, "/dev/pty%d", minor);
```
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Updated alt1250 driver with regarding to the following changes.
- Add LTE hibernation feature
- Split source code per module
- Some refactoring
- Some bug fixes
This commit reverts 19f269e54b and
substitutes the semaphore to a mutex, used as a locking mechanism
to avoid syslog messages being messed.
Considering SMP, threads running on different CPUs could call
syslog_default_write simultaneously. It then calls `up_nputs` that,
in most of the implementations, calls `up_putc` multiple times to
write to the serial. So, calling it at the same would cause syslog
messages to interfere with each other.
`up_nputs` and `up_putc` are low-level functions that could be used
during initialization and by the interrupt handler. Hence, it isn't
advisable to implement any locking mechanism on them. On the other
hand, syslog can also be used from the interrupt: if the interrupt
buffer is selected (`CONFIG_SYSLOG_INTBUFFER=y`), the syslog
messages will be flushed when we aren't serving an interrupt.
On the contrary, if it isn't set, it would call the registered
`sc_force` callback, which calls `syslog_default_putc` instead of
the lock-protected `syslog_default_write`.
Summary:
- I noticed that the driver sends incorrect packets sometimes.
- This commit fixes this issue.
Impact:
- None
Testing:
- Tested with qemu-7.1
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
This is a refactored version of the SLIP network driver. Updates
include:
1. The original design started two kernel threads per SLIP device.
The refactored version uses file_poll to essentially be driven
by the UART RX and TX interrupts and pushes work to the low
priority work queue.
2. The SLIP byte un-/stuffing is more efficient now, using memcpy
instead of handling each byte individually.
3. The switch of the old SLIP driver to IOBs caused buffer overwrites
if packets were sent that would not fit into a single IOB. This is
fixed now.
Signed-off-by: Michael Jung <michael.jung@secore.ly>
When updating the full-screen data, sq_ init() will clear the updqueue and add just one new full-screen data to the updqueue. So when the vnc_updater thread is awakened, it may read a null data due to multiple reading, leading to vnc_updater thread exited , which is not expected.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
set touch.maxpoint to 1 in vnc_server.c for circbuf_init，otherwise
touch_event will circbuf_overwrite a wrong value.
test step:vnc run lvgldemo，test input event
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
USB drivers should not try control devices in the usbhost_disconnected
function. The control endpoint is NULL at this point because the device
has already been disconnected.
Before this change, the hub driver crashed when the child called
usbhost_hubpwr after the parent had already deactivated the control
pipe and set hport->ep0 to NULL.
1 Gbit W25Q01JV flash uses two 512 Mbit dies. This requires specific
operations in the driver in order to support the entire 1 Gbit region.
This commit adds dual die support for W25Q01JV flash.
Generally the driver has to switch active dies when die specific read from
status register is required (therefore before read, write, erase and when
checking if write status register was successful).
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
if multiple threads are doing serial read/write at the same time,
the driver will only wake up one of the thread, which will cause
other threads fail to be woken up in time and cause blocking
Signed-off-by: chao an <anchao@xiaomi.com>
