WIP
WIP - ALS now OK with full IOCTL.
WIP
WIP
ALS now works as intended
WIP - getting to bottom of crash when ctrl-c the app
Seems to all work...
ioctl #define changes
Update ioctl.h
Maybe final changes
Maybe final changes - again
Delete .settings directory
Delete nuttx Default.launch
Maybe final changes - again
changes after initial feedback
changes after initial feedback
Add snerr error when incorrect device ID seen
Update apds9922.c
Revert "Merge branch 'apds9922' of https://github.com/TimJTi/nuttx into apds9922"
This reverts commit 8fdf5cbfb783d25251d13bc338ece6adca1308bc, reversing
changes made to 0d58237ba27f3cf87cf711658f5388d974be502e.
Improve probe error messages
APDS9922
WIP
WIP - ALS now OK with full IOCTL.
WIP
WIP
ALS now works as intended
WIP - getting to bottom of crash when ctrl-c the app
Seems to all work...
ioctl #define changes
Update ioctl.h
Maybe final changes
Maybe final changes - again
Delete .settings directory
Delete nuttx Default.launch
Maybe final changes - again
changes after initial feedback
changes after initial feedback
Add snerr error when incorrect device ID seen
Update apds9922.c
Revert "Merge branch 'apds9922' of https://github.com/TimJTi/nuttx into apds9922"
This reverts commit 8fdf5cbfb783d25251d13bc338ece6adca1308bc, reversing
changes made to 0d58237ba27f3cf87cf711658f5388d974be502e.
Improve probe error messages
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Update drivers/sensors/apds9922.c
Co-authored-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Delete .gitignore
Changes after PR review
Remove static arrays from header file
Update apds9922.c
improvements to enum usage
Restore .gitignore
Update Kconfig
Update .gitignore
Update .gitignore
We have projects that need to sense ip address changes in time,
and set ip address or clear ip address through netlink
so the relevant implementation is added.
The usage and command structure are consistent with linux
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Instead of using a volatile storage for the address environment in the
binfmt / loadinfo structures, always allocate the address environment
from kheap.
This serves two purposes:
- If the task creation fails, any kernel thread that depends on the
address environment created during task creation will not lose their
mappings (because they hold a reference to it)
- The current address environment variable (g_addrenv) will NEVER contain
a stale / incorrect value
- Releasing the address environment is simplified as any pointer given
to addrenv_drop() can be assumed to be heap memory
- Makes the kludge function addrenv_clear_current irrelevant, as the
system will NEVER have invalid mappings any more
This way the mappings can be modified for any vm area, not only the
process that is running.
Why? This allows mapping pages to kernel dynamically, this functionality
will be presented later.
Summary:
- Support arm64 pmu api, Currently only the cycle counter function is supported.
- Using ARM64 PMU hardware capability to implement perf interface, modify all
perf interface related code.
- Support for pmu init under smp.
Signed-off-by: wangming9 <wangming9@xiaomi.com>
Refer to issue #8867 for details and rational.
Convert sigset_t to an array type so that more than 32 signals can be supported.
Why not use a uin64_t?
- Using a uin32_t is more flexible if we decide to increase the number of signals beyound 64.
- 64-bit accesses are not atomic, at least not on 32-bit ARMv7-M and similar
- Keeping the base type as uint32_t does not introduce additional overhead due to padding to achieve 64-bit alignment of uin64_t
- Some architectures still supported by NuttX do not support uin64_t
types,
Increased the number of signals to 64. This matches Linux. This will support all xsignals defined by Linux and also 32 real time signals (also like Linux).
This is is a work in progress; a draft PR that you are encouraged to comment on.
usbdev/usbmsc.c:1758:5: error: conflicting types for 'usbmsc_classobject'; have 'int(void *, struct usbdev_devinfo_s *, struct usbdevclass_driver_s **)'
1758 | int usbmsc_classobject(FAR void *handle,
| ^~~~~~~~~~~~~~~~~~
In file included from /home/raiden00/git/RTOS/nuttx/nuttx/include/nuttx/usb/usbdev.h:36,
from usbdev/usbmsc.c:68:
/home/raiden00/git/RTOS/nuttx/nuttx/include/nuttx/usb/usbmsc.h:173:5: note: previous declaration of 'usbmsc_classobject' with type 'int(void *, struct usbdev_devinfo_s *, struct usbdevclass_driver_s **)'
173 | int usbmsc_classobject(FAR void *handle,
There are number problems with the implementation of realtime signals in NuttX as discussed in Issue #8869. A first step to correcting any of these is to correct the definitions of SIGRTMIN, SIGRTMAX, and RTSIG_SIX.
SIGRTMIN is the first real-time signals. Real-time signal numbers must not overlap the standard signal numbers. Before this fix, it was set equal to the first standard signal. Real-time signals differ from standard signals in that (1) they have no default actions, and (2) real time signal actions are prioritized whereas standard signal actions are processed FIFO.
SIGRTMAX is the last real-time signal.
RTSIG_MAX must be set equal to maximum number of realtime signals reserved for application use
The change corrects the definitons but has not impact at all becasuse none of there definitions are currently used in the OS. But they will be when prioritized real time signal handling is implemented.
