nuttx/nuttx-update
1
2
Fork 1
Code Issues 1 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Fix typos in comments and Kconfig files

Browse source 
Signed-off-by: Juha Niskanen <juha.niskanen@haltian.com>
This commit is contained in:
Juha Niskanen 2021-12-20 16:49:48 +02:00 committed by Xiang Xiao
parent 1e83c83bf3
commit 422ceec99b
21 changed files with 45 additions and 53 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
arch/Kconfig
View file

@ -423,7 +423,7 @@ config ARCH_USE_TEXT_HEAP
default n
depends on ARCH_HAVE_TEXT_HEAP
---help---
This option enables architecture-sepecific memory allocator
This option enables architecture-specific memory allocator
for dynamic code loading. For example, ESP32 has a separate memory
regions for instruction and data and the memory region used for
usual malloc doesn't work for instruction.

6
arch/arm/Kconfig
View file

@ -976,7 +976,7 @@ config DEBUG_MEMFAULT
default n
depends on ARCH_HAVE_MEMFAULT_DEBUG && DEBUG_ALERT && ARCH_USE_MPU
---help---
Enables verbose debug output when a mem fault is occurs. This verbose
Enables verbose debug output when a mem fault occurs. This verbose
output is sometimes helpful when debugging difficult mem fault problems,
but may be more than you typically want to see.
@ -989,7 +989,7 @@ config DEBUG_BUSFAULT
default n
depends on ARCH_HAVE_BUSFAULT_DEBUG && DEBUG_ALERT
---help---
Enables verbose debug output when a bus fault is occurs. This verbose
Enables verbose debug output when a bus fault occurs. This verbose
output is sometimes helpful when debugging difficult bus fault problems,
but may be more than you typically want to see.
@ -1002,7 +1002,7 @@ config DEBUG_USAGEFAULT
default n
depends on ARCH_HAVE_USAGEFAULT_DEBUG && DEBUG_ALERT
---help---
Enables verbose debug output when a usage fault is occurs. This verbose
Enables verbose debug output when a usage fault occurs. This verbose
output is sometimes helpful when debugging difficult usage fault problems,
but may be more than you typically want to see.

6
arch/arm/src/sama5/sam_serial.c
View file

@ -1074,13 +1074,13 @@ static int up_setup(struct uart_dev_s *dev)
&& priv->usartbase != SAM_UART1_VBASE
#endif
#if defined(CONFIG_SAMA5_UART2)
# warning REVIST
# warning REVISIT
#endif
#if defined(CONFIG_SAMA5_UART3)
# warning REVIST
# warning REVISIT
#endif
#if defined(CONFIG_SAMA5_UART4)
# warning REVIST
# warning REVISIT
#endif
)
{

2
arch/arm/src/sama5/sam_xdmac.c
View file

@ -1662,7 +1662,7 @@ static inline int sam_multiple(struct sam_xdmach_s *xdmach)
* (CNDA) Register with the first descriptor address and bit NDAIF
* with the master interface identifier.
*
* REVIST: Using NDAIF=0. Is that correct?
* REVISIT: Using NDAIF=0. Is that correct?
*/
paddr = sam_physramaddr((uintptr_t)llhead);

2
arch/arm/src/samv7/sam_xdmac.c
View file

@ -1356,7 +1356,7 @@ static inline int sam_multiple(struct sam_xdmach_s *xdmach)
* (CNDA) Register with the first descriptor address and bit NDAIF
* with the master interface identifier.
*
* REVIST: Using NDAIF=0. Is that correct?
* REVISIT: Using NDAIF=0. Is that correct?
*/
paddr = sam_physramaddr((uintptr_t)llhead);

2
arch/misoc/src/lm32/lm32_decodeirq.c
View file

@ -69,7 +69,7 @@ uint32_t *lm32_decodeirq(uint32_t intstat, uint32_t *regs)
{
/* Yes.. Dispatch the interrupt */
/* REVIST: Do I need to acknowledge the interrupt first? */
/* REVISIT: Do I need to acknowledge the interrupt first? */
irqinfo("irq=%d\n", irq);
regs = lm32_doirq(irq, regs);

2
arch/misoc/src/minerva/minerva_decodeirq.c
View file

@ -69,7 +69,7 @@ uint32_t *minerva_decodeirq(uint32_t intstat, uint32_t * regs)
if ((intstat & bit) != 0)
{
/* Yes.. Dispatch the interrupt
* REVIST: Do I need to acknowledge the interrupt first?
* REVISIT: Do I need to acknowledge the interrupt first?
*/
irqinfo("irq=%d\n", irq);

4
boards/Kconfig
View file

@ -2065,7 +2065,7 @@ config ARCH_BOARD_TEENSY_3X
This board configuration can also be used with the older Teensy-3.0. The
Teensy-3.0 has the same schematic (although some pins are not used on the
Teensy-3.0). the primary difference is that the Teensy 3.0 has a
Teensy-3.0). The primary difference is that the Teensy 3.0 has a
MK20DX128VLH5 with slightly less capability.
config ARCH_BOARD_TEENSY_4X
@ -2271,7 +2271,7 @@ config ARCH_BOARD_PHY6222
depends on ARCH_CHIP_PHY62XX
---help---
none
config ARCH_BOARD_SIM
bool "User mode simulation"
select ARCH_HAVE_BUTTONS

4
boards/arm/lpc54xx/lpcxpresso-lpc54628/include/board.h
View file

@ -161,12 +161,12 @@
# define BOARD_SYSTICK_CLOCK (BOARD_AHB_FREQUENCY / BOARD_SYSTICKCLKDIV)
#endif
/* Flexcomm0: USART0 (REVIST) */
/* Flexcomm0: USART0 (REVISIT) */
#define BOARD_FLEXCOMM0_CLKSEL SYSCON_FCLKSEL_FRO12M
#define BOARD_FLEXCOMM0_FCLK LPC54_FRO_12MHZ
/* Flexcomm2: I2C2 (REVIST) */
/* Flexcomm2: I2C2 (REVISIT) */
#define BOARD_FLEXCOMM2_CLKSEL SYSCON_FCLKSEL_FRO12M
#define BOARD_FLEXCOMM2_FCLK LPC54_FRO_12MHZ

2
boards/arm/stm32/olimex-stm32-p407/src/stm32_sram.c
View file

@ -48,7 +48,7 @@
#endif
/* SRAM Timing
* REVIST:
* REVISIT:
* These were ported from the STM3240G-EVAL and have not been verified on
* this platform.
*/

2
boards/arm/stm32/viewtool-stm32f107/src/stm32_ssd1289.c
View file

@ -177,7 +177,7 @@ static void stm32_extmemgpios(const uint16_t *gpios, int ngpios);
const uint16_t fsmc_gpios[] =
{
/* A16... A23. REVIST: only A16 is used by the LCD */
/* A16... A23. REVISIT: only A16 is used by the LCD */
GPIO_NPS_A16, GPIO_NPS_A17, GPIO_NPS_A18, GPIO_NPS_A19, GPIO_NPS_A20,
GPIO_NPS_A21, GPIO_NPS_A22, GPIO_NPS_A23,

2
boards/sim/sim/sim/README.txt
View file

@ -538,7 +538,7 @@ bluetooth
drivers/wireless/bluetooth/bt_null.c
There is also support on a Linux Host for attaching the bluetooth hardware
from the host to the NuttX bluetoooth stack via the HCI Socket interface
from the host to the NuttX bluetooth stack via the HCI Socket interface
over the User Channel. This is enabled in the bthcisock configuration.
In order to use this you must give the nuttx elf additional capabilities:

2
drivers/wireless/spirit/lib/spirit_spi.c
View file

@ -634,7 +634,7 @@ int spirit_waitstatus(FAR struct spirit_library_s *spirit,
* resulting delay in ticks is greater than or equal to the requested time
* in MSEC.
*
* REVIST: If USEC_PER_TICK and 'msec' are large, then the second
* REVISIT: If USEC_PER_TICK and 'msec' are large, then the second
* computation may overflow!
*/

2
libs/libc/dlfcn/lib_dlopen.c
View file

@ -258,7 +258,7 @@ errout_with_lock:
/* In the FLAT build, a shared library is essentially the same as a kernel
* module.
*
* REVIST: Missing functionality:
* REVISIT: Missing functionality:
* - No automatic binding of symbols
* - No dependencies
* - mode is ignored.

2
libs/libc/stdio/lib_setvbuf.c
View file

@ -143,7 +143,7 @@ int setvbuf(FAR FILE *stream, FAR char *buffer, int mode, size_t size)
* Here we really only verify that there is no valid data in the existing
* buffer.
*
* REVIST: There could be race conditions here, could there not?
* REVISIT: There could be race conditions here, could there not?
*/
if (stream->fs_bufpos != stream->fs_bufstart)

2
net/local/local_fifo.c
View file

@ -419,7 +419,7 @@ int local_release_fifos(FAR struct local_conn_s *conn)
int local_release_halfduplex(FAR struct local_conn_s *conn)
{
#if 1
/* REVIST: We need to think about this carefully. Unlike the connection-
/* REVISIT: We need to think about this carefully. Unlike the connection-
* oriented Unix domain socket, we don't really know the best time to
* release the FIFO resource. It would be extremely inefficient to create
* and destroy the FIFO on each packet. But, on the other hand, failing

2
net/local/local_sockif.c
View file

@ -163,7 +163,7 @@ static int local_setup(FAR struct socket *psock, int protocol)
* connection structure, it is unallocated at this point. It will not
* actually be initialized until the socket is connected.
*
* REVIST: Only SOCK_STREAM and SOCK_DGRAM are supported. Should also
* REVISIT: Only SOCK_STREAM and SOCK_DGRAM are supported. Should also
* support SOCK_RAW.
*/

2
net/mld/mld_leave.c
View file

@ -148,7 +148,7 @@ int mld_leavegroup(FAR const struct ipv6_mreq *mrec)
MLD_STATINCR(g_netstats.mld.done_sched);
/* REVIST: This will interfere is the are any other tasks
/* REVISIT: This will interfere if there are any other tasks
* waiting for a message to be sent. Can that happen?
*/

2
net/mld/mld_timer.c
View file

@ -253,7 +253,7 @@ static void mld_v1dog_work(FAR void *arg)
CLR_MLD_V1COMPAT(dev->d_mld.flags);
/* REVIST: Whenever a host changes its compatibility mode, it cancels
/* REVISIT: Whenever a host changes its compatibility mode, it cancels
* all of its pending responses and retransmission timers.
*/
}

8
net/udp/udp_conn.c
View file

@ -242,10 +242,10 @@ static inline FAR struct udp_conn_s *
* - Call send() with no address address information
* - call recv() (from address information should not be needed)
*
* REVIST: SO_BROADCAST flag is currently ignored.
* REVISIT: SO_BROADCAST flag is currently ignored.
*/
/* Check that there is a local port number and this is matches
/* Check that there is a local port number and this matches
* the port number in the destination address.
*/
@ -380,10 +380,10 @@ static inline FAR struct udp_conn_s *
* - Call send() with no address address information
* - call recv() (from address information should not be needed)
*
* REVIST: SO_BROADCAST flag is currently ignored.
* REVISIT: SO_BROADCAST flag is currently ignored.
*/
/* Check that there is a local port number and this is matches
/* Check that there is a local port number and this matches
* the port number in the destination address.
*/

40
sched/Kconfig
View file

@ -13,14 +13,6 @@ menuconfig DISABLE_OS_API
disable functions unless you want to restrict usage
of those APIs.
There are certain dependency relationships in these
features.
1) mq_notify logic depends on signals to awaken tasks
waiting for queues to become full or empty.
2) pthread_condtimedwait() depends on signals to wake
up waiting tasks.
if DISABLE_OS_API
config DISABLE_POSIX_TIMERS
@ -63,11 +55,11 @@ config SCHED_TICKLESS
---help---
By default, system time is driven by a periodic timer interrupt. An
alternative configurations is a tick-less configuration in which
there is no periodic timer interrupt. Instead and interval timer is
there is no periodic timer interrupt. Instead an interval timer is
used to schedule the next OS time event. This option selects that
tick-less OS option. If the tick-less OS is selected, then there are
additional platform specific interfaces that must be provided as
defined include/nuttx/arch.h
defined in include/nuttx/arch.h
if SCHED_TICKLESS
@ -605,7 +597,7 @@ config SCHED_THREAD_LOCAL
default n
depends on ARCH_HAVE_THREAD_LOCAL
---help---
This option enables architecture-sepecific TLS supports (__thread/thread_local keyword)
This option enables architecture-specific TLS support (__thread/thread_local keyword)
Note: Toolchain must be compiled with '--enable-tls' enabled
endmenu # Tasks and Scheduling
@ -688,7 +680,7 @@ config CANCELLATION_POINTS
default n
---help---
Enable POSIX cancellation points for pthread_cancel(). If selected,
cancellation points will also used with the () task_delete() API even if
cancellation points will also used with the task_delete() API even if
pthreads are not enabled.
endmenu # Pthread Options
@ -755,48 +747,48 @@ config SCHED_CRITMONITOR_MAXTIME_THREAD
default 0
---help---
Thread execution time should be smaller than
SCHED_CRITMONITOR_MAXTIME_THREAD, or system will give a warnning.
For debugging system lantency, 0 means disabled.
SCHED_CRITMONITOR_MAXTIME_THREAD, or system will give a warning.
For debugging system latency, 0 means disabled.
config SCHED_CRITMONITOR_MAXTIME_WQUEUE
int "WORK queue max execution time"
default SCHED_CRITMONITOR_MAXTIME_THREAD
---help---
Worker execution time should be smaller than
SCHED_CRITMONITOR_MAXTIME_WQUEUE, or system will give a warnning.
For debugging system lantency, 0 means disabled.
SCHED_CRITMONITOR_MAXTIME_WQUEUE, or system will give a warning.
For debugging system latency, 0 means disabled.
config SCHED_CRITMONITOR_MAXTIME_PREEMPTION
int "Pre-emption (sched_lock) max holding time"
default SCHED_CRITMONITOR_MAXTIME_WQUEUE
---help---
Pre-emption holding time should be smaller than
SCHED_CRITMONITOR_MAXTIME_PREEMPTION, or system will give a warnning.
For debugging system lantency, 0 means disabled.
SCHED_CRITMONITOR_MAXTIME_PREEMPTION, or system will give a warning.
For debugging system latency, 0 means disabled.
config SCHED_CRITMONITOR_MAXTIME_CSECTION
int "Csection (enter_critical_section) max holding time"
default SCHED_CRITMONITOR_MAXTIME_PREEMPTION
---help---
Csection holding time should be smaller than
SCHED_CRITMONITOR_MAXTIME_CSECTION, or system will give a warnning.
For debugging system lantency, 0 means disabled.
SCHED_CRITMONITOR_MAXTIME_CSECTION, or system will give a warning.
For debugging system latency, 0 means disabled.
config SCHED_CRITMONITOR_MAXTIME_IRQ
int "IRQ max execution time"
default SCHED_CRITMONITOR_MAXTIME_CSECTION
---help---
IRQ handler execution time should be smaller than
SCHED_CRITMONITOR_MAXTIME_IRQ, or system will give a warnning.
For debugging system lantency, 0 means disabled.
SCHED_CRITMONITOR_MAXTIME_IRQ, or system will give a warning.
For debugging system latency, 0 means disabled.
config SCHED_CRITMONITOR_MAXTIME_WDOG
int "WDOG callback max execution time"
default SCHED_CRITMONITOR_MAXTIME_IRQ
---help---
Wdog callback execution time should be smaller than
SCHED_CRITMONITOR_MAXTIME_WDOG, or system will give a warnning.
For debugging system lantency, 0 means disabled.
SCHED_CRITMONITOR_MAXTIME_WDOG, or system will give a warning.
For debugging system latency, 0 means disabled.
endif # SCHED_CRITMONITOR