since clock_t may map to either 32-bit or 64-bit integer type,
UINT_MAX may not be the maximum value of clock_t.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
rpmsg_ping.c is blocking CI checks for RPTUN related patches like #11673.
this patch simply fix the compilation issue of rpmsg_ping.c:
- line 191: overflow conversion from "long unsigned int" to "unsigned int"
- line 226: "sendlen" used uninitialized
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
ALT1250 driver sends an event named LTE_CMDID_RESTARTAPI
to ALT1250 daemon when state is PM_NOARMAL in the function
of prepare registered by pm_register.
It should be possible to use ping without rptun being enabled, so striped rptun_ping out of rptun and rename to rpmsg_ping.
Signed-off-by: wangyongrong <wangyongrong@xiaomi.com>
Squashed commits:
1. Porting prior PCI work in place of jailhouse code
At this point the PCI enumeration works for x86_64 including over
pci-pci bridges.
Running QEMU with this configuration we see the bridge and the
device on the bridge. It also detected the qemu test device
qemu-system-x86_64 \
-cpu host,+pcid,+x2apic,+tsc-deadline,+xsave,+rdrand \
--enable-kvm -smp 1 -m 2G -cdrom boot.iso --nographic -no-reboot \
-device pci-testdev \
-device pci-bridge,id=bridge0,chassis_nr=2 \
-device e1000,bus=bridge0,addr=0x3
qemu_pci_init: Initializing PCI Bus
pci_probe_device: [00:00.0] Found 8086:1237, class/revision 06000002
pci_probe_device: [00:01.1] Found 8086:7010, class/revision 01018000
pci_probe_device: [00:01.2] Found ffff:ffff, class/revision ffffffff
pci_probe_device: [00:01.3] Found 8086:7113, class/revision 06800003
pci_probe_device: [00:01.4] Found ffff:ffff, class/revision ffffffff
pci_probe_device: [00:01.5] Found ffff:ffff, class/revision ffffffff
pci_probe_device: [00:01.6] Found ffff:ffff, class/revision ffffffff
pci_probe_device: [00:01.7] Found ffff:ffff, class/revision ffffffff
pci_probe_device: [00:02.0] Found 1234:1111, class/revision 03000002
pci_probe_device: [00:03.0] Found 8086:100e, class/revision 02000003
pci_probe_device: [00:04.0] Found 1b36:0005, class/revision 00ff0000
pci_probe_device: [00:04.0] Probing
pci_check_pci_bridge: [00:05.0] Found Bridge
pci_probe_device: [01:03.0] Found 8086:100e, class/revision 02000003
pci_probe_device: [00:05.0] Found 1b36:0001, class/revision 06040000
2. Remove unused CONFIG_PCI_MAX_BDF option
3. Add a workaround for Jailhouse pci scanning
4. Extend BAR parsing and handle PIO and MMIO for pci-testdev
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
5. PCI: Add initial support for QEMU 'edu' test device
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
6. Bring up PCI later in boot process
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
7. Add ISR and DMA support to QEMU edu test pci device
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
8. Fix bad function prototype definition in qemu_edu
9. intel64: Add a pci test configuration and instructions
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
10. PCI: Fix issue in identification of 64bit bar
Signed-off-by: Brennan Ashton <bashton@brennanashton.com>
Squashed commits:
1. x86_64: qemu: implement pci-e functions and enumerate pci-e devices on boot
2. virt: add qemu pci-testdev driver
3. pcie: types array should be null terminated
4. pcie: enable don't take flags, hardcoded enabling flags
5. pcie: checking bar > 4 for 64bit bars are sufficient
6. pcie: qemu: remove not used header
7. pcie: qemu: return -EINVAL if buffer argument is NULL
8. pcie: make pcie enumerate routine as common instead of architecture dependent
9. pcie: cosmetic changes to fit check tools
10. pcie: create MSI/MSIX related marcos and simplify the msi/msix routines
This commit adds basic support for iC-JX expander in SPI mode. The
expander is functional and supports both input and output pins. Further
expander functionalities (filtering, adc, interrupt support) are not
yet implemented.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
This slightly revised the USB host documentation and fixed typos
encountered in the document and some source files.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
This change adds support for the USB Transport Layer as described
in the bluetooth spec. Isochronous endpoints are not yet supported.
Because of limitations in the NuttX bluetooth stack, only one USB
device can be used. This driver will only allow one USB dongle to
use bluetooth.
A Laird USB BT4.2 dongle (from Mouser) was used for testing:
M/N BT851 1.0 1829, FCC ID:SQGBT850
lsusb: 04b4:f901 Cypress Semiconductor Corp. CYW20704A2
The following commands were used to test from the nsh prompt:
bt bnep0 scan start
bt bnep0 scan stop
bt bnep0 scan get
bt bnep0 info
The Linux gatttool was used to connect over wireless.
With the BDAddr found by "bt bnep0 info", start gatttool using:
gatttool -b BDAddr -I
Connect to the device using:
connect
Read the device name using the GAP device name UUID:
char-read-uuid 2a00
Part of the response is:
value: 41 70 61 63 68 65 20 4e 75 74 74 58
which is the string "Apache NuttX"
nuttx/driver/rpmsg: new folder, extract common rpmsg api in rptun.c to rpmsg.c.
rpmsg provide rpmsg_ops to each backend for specific implementation.
Signed-off-by: wangyongrong <wangyongrong@xiaomi.com>
The length of some config elements are not equal to 1,2,4,8, so we can't
assert in virtio_mmio_config_read/write() direclty when length != 1,2,4,8
For example, in virtio_net_config from virtio spec v1.2
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
le16 mtu;
le32 speed;
u8 duplex;
u8 rss_max_key_size;
le16 rss_max_indirection_table_length;
le32 supported_hash_types;
};
The mac length is 6 and not equal to 1,2,4,8
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
Not found the mmio device is a normal case, so should not print the
error log.
This commit change the log level to info when not found the mmio
device.
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
The lower-half implementation of the RMT character driver based on
Espressif HAL enables using the RMT peripheral of ESP32, ESP32-S2
and ESP32-S3 as a common xtensa-based Espressif driver.
The RMT packages on Espressif SoCs are 4-byte long and are known as
"items". Please check the Techinal Reference Manual of the chip to
obtain more details.
Although the LED might be RGB-only, the LED data is packed in a
32-bit long variable and, then, this is the default size of a LED
pixel to define the 'WS2812_RW_PIXEL_SIZE' macro. Please note that
the lower-half driver will deal with the case of the addressable
LED being 3 or 4-pixel sized.
The RMT (Remote Control) character driver allows to use the RMT
peripheral (usually, a one-wire peripheral dedicated to driving
IR remote control) as a character driver.
Please note that this perpiheral depends on the lower-half specific
driver implementation.
