Update the MIPS Creator CI20 board documentation to include a detailed
peripherals support table. This replaces the basic bulleted list with
comprehensive status details for CPU cores, RAM, Display, Ethernet,
GPIO, TRNG, Timers, UART0, USB Host, and Watchdog.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
romfs_seek() clamps the computed position to the file size when it
exceeds rf_size, but never checks for a negative result. lseek(fd,
offset, SEEK_SET/SEEK_CUR/SEEK_END) with an offset that produces a
negative position (e.g. a negative SEEK_SET offset, or a SEEK_CUR/
SEEK_END offset more negative than the current position/file size)
is written straight into filep->f_pos.
The subsequent romfs_read() computes
`rf->rf_startoffset + filep->f_pos` into a uint32_t, so a negative
f_pos wraps around to a huge unsigned offset, and romfs_hwread()'s
XIP path memcpy()s from rm_xipbase plus that offset -- an
out-of-bounds read far past the mapped flash region.
Add the same "if (position < 0) return -EINVAL" guard already used
by fs/fat/fs_fat32.c's seek function, before the existing
end-of-file clamp.
Signed-off-by: yi chen <94xhn1@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Fix NULL pointer dereference and memory corruption by using
file_put() instead of file_close() + kmm_free().
Add peer NULL check to local_freectl().
Signed-off-by: Bogdan <Bogdan4ik0759@gmail.com>
Document the usb-cdc-uart configuration, which keeps NSH on the USART2
ST-LINK virtual COM port and exposes a separate USB CDC/ACM serial
device on the STM32 USB FS connector.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The STM32F072RB provides a full speed USB device controller, but the
Nucleo-F072RB board support did not enable it and no configuration
exercised it.
Add the pieces required to run USB device mode on this board:
- Select HSI48 as the 48MHz source and use the USB start of frame packet
as the CRS synchronisation event, which is the intended crystal-less
USB configuration for this part.
- Add the USB device pin definitions to the STM32F07x pin map.
- Provide board level pull-up control and register the CDC/ACM class at
boot when it is selected.
- Add a usb-cdc-uart configuration that presents an NSH console on
USART2 and a CDC/ACM serial device on USB.
- Enable the USB device pins in the nsh configuration so the two
configurations stay consistent.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
clock_gettime(CLOCK_MONOTONIC) reads g_system_ticks, which is only
refreshed when a timer expiration is processed. On SCHED_TICKLESS an
idle system has no timeout armed, so the clock returns 0 before the
first expiration and a frozen value afterwards.
This regressed in commit c7b6442974, which switched CLOCK_MONOTONIC to
the sched tick counter to exclude suspended time. Excluding suspend time
needs explicit accounting maintained by PM code, the tick counter cannot
provide it on tickless.
Restore the live read. On non-tickless builds clock_systime_timespec()
falls back to the same tick counter, so behavior there is unchanged.
Verified on qemu-intel64, nrf52840-dk and rv-virt.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
vrefint_enable() sets SYSCFG_CFGR3_ENBUFVREFINTHSI48 in its local copy
of the register value but never writes that value back to the hardware.
The VREFINT reference for the HSI48 scaler is therefore never enabled.
Only the earlier ENVREFINT update reaches the register, so VREFINT
itself is enabled while the HSI48 reference is not. HSI48 then runs
without its voltage reference and the 48MHz clock is not accurate enough
to be used by the USB device controller.
Write the register after applying the HSI48 reference bit.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
STM32_HSI48_SYNCSRC was SYNCSRC_NONE, which makes stm32_enable_hsi48()
return before configuring the CRS at all. HSI48 then free runs at its
untrimmed factory frequency, which is not accurate enough for USB full
speed operation.
The board has no CRS_SYNC pin wired and does not fit an LSE crystal for
this purpose, so the USB start of frame packet is the available
synchronisation source. This is the intended configuration for
crystal-less USB on this part.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
stm32_enable_hsi48() set CRS_CR_AUTOTRIMEN but left CRS_CR_CEN clear.
AUTOTRIMEN only instructs the hardware to apply corrections derived from
the frequency error counter; the counter itself is enabled by CEN. With
CEN clear no error measurement is ever produced and the HSI48 TRIM value
stays at its reset default, so the oscillator is never disciplined to the
synchronisation source.
Set both bits, matching the value the STM32 ROM bootloader programs when
it runs its own crystal-less USB stack (CRS_CR = 0x1a60, i.e.
CEN | AUTOTRIMEN with a trimmed TRIM field).
This file is shared by the M0 STM32 parts (F0, G0, C0, L0); all of them
require CEN for automatic trimming to function.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The SYSCFG peripheral clock was gated on CONFIG_STM32_SYSCFG, but that
symbol is not defined by the STM32L0 Kconfig (only stm32h7 declares it),
so RCC_APB2ENR_SYSCFGEN was never set on this chip.
With SYSCFG unclocked every write performed by vrefint_enable() is
discarded and SYSCFG_CFGR3 reads back as 0x00000000. VREFINT and, in
particular, the ENBUFVREFINTHSI48 reference for the HSI48 oscillator are
therefore never enabled. HSI48 still reports HSI48RDY, but it runs
without its voltage reference and the 48MHz clock supplied to the USB
device controller is unusable: the controller cannot sample the bus,
never latches a reset condition in USB_ISTR, and never raises its
interrupt. The result is a USB device that is configured correctly in
every visible register yet never enumerates.
VREFINT is configured exclusively through SYSCFG_CFGR3, so enable the
SYSCFG clock whenever CONFIG_STM32_VREFINT is selected.
Observed on NUCLEO-L073RZ (STM32L073RZ):
before: SYSCFG_CFGR3 = 0x00000000, no enumeration
after: SYSCFG_CFGR3 non-zero, device enumerates as CDC/ACM
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The clock recovery system peripheral clock was enabled only when
CONFIG_STM32_CRS was selected. The CRS is required by any board that
uses HSI48 as the 48MHz clock source, because HSI48 must be trimmed from
an external synchronisation event to stay within the tolerance demanded
by USB full speed operation.
STM32_USE_HSI48 is the condition under which the remaining HSI48 and CRS
setup is compiled in, see stm32_enable_hsi48(), so accept that condition
here as well. Without the peripheral clock the CRS registers are
inaccessible and automatic trimming silently does nothing.
CONFIG_STM32_CRS is retained so that boards selecting the CRS directly
are unaffected.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The code that claimed to "enable clocking to the USB peripheral" cleared
RCC_APB1ENR_USBEN inside RCC_APB1RSTR. That is both the wrong register
and the wrong bit: USBEN belongs to RCC_APB1ENR, while APB1RSTR holds
RCC_APB1RSTR_USBRST. The peripheral clock is enabled by the RCC setup
performed at boot, so the write had no useful effect and merely cleared
an unrelated reset bit.
Issue a proper reset pulse on RCC_APB1RSTR_USBRST instead, so the
controller starts from a known state.
On STM32L0 the D+/D- lines are connected to the USB transceiver
automatically once the peripheral is enabled and there is no alternate
function to select, so skip the GPIO configuration on that chip. The
board GPIO_USB_DM/GPIO_USB_DP definitions do not exist there.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The initial interrupt mask enabled only reset, suspend and correct
transfer. Error conditions reported by the controller, USB_ISTR_ERR and
USB_ISTR_PMAOVRN, were neither enabled nor acknowledged.
Because the status bits are never cleared, an error condition latched in
USB_ISTR remains set and is re-evaluated on every subsequent interrupt,
which makes the reported status misleading when debugging transfer
problems.
Add ERRM and PMAOVRN to the initial mask and clear the corresponding
status bits when they are seen.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The correct transfer loop in stm32_usb_interrupt() dispatched every
completion to stm32_epdone(), including those for endpoint 0.
stm32_epdone() implements the generic bulk/interrupt endpoint completion
path. It does not decode the SETUP stage, does not maintain the EP0
state machine, and does not apply the EP0 specific RX/TX status rules.
Control transfers therefore never completed correctly and the device
could not be enumerated.
Dispatch endpoint 0 to stm32_ep0done(), which is the control endpoint
handler and is already used for the same purpose by the low priority
transfer path in stm32_lptransfer().
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
The packet memory area (PMA) accessors in the M0 USB device driver were
carried over from the STM32F1 implementation, where the PMA is seen by
the CPU as 16-bit values placed on 32-bit boundaries. On the STM32F0,
STM32L0 and other M0 parts the PMA is a linear 16-bit memory, so the
F1 scaling is wrong:
- STM32_USB_BTABLE_RADDR() shifted the computed buffer descriptor offset
left by one, addressing every second descriptor entry.
- The buffer descriptor accessors declared the descriptor entries as
uint32_t and accessed them 32 bits at a time, so each write clobbered
the adjacent entry.
- stm32_copytopma() and stm32_copyfrompma() scaled the PMA offset by two
when computing the packet buffer address.
The result is that endpoint buffer descriptors and packet data are
written to the wrong offsets in packet memory, and no transfer completes
correctly.
Drop the F1 scaling and use 16-bit accesses throughout. Note that the
sibling stm32_usbfs.h defines STM32_USB_BTABLE_RADDR() without the shift
already, so this brings the M0 header in line with it.
Assisted-by: GitHub Copilot:claude-opus-5
Signed-off-by: jsanchez-2g <jsanchez@2g-eng.com>
CONFIG_STM32_GPIOIRQ has never had a Kconfig definition, and the guarded
stm32_gpioirqinitialize function has no declaration or implementation.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
CONFIG_STM32_GPIO_IRQ has no Kconfig definition, and the guarded stm32_gpioirq
functions have no declarations or implementations.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
Remove the dependency on the iLLD SFR headers (IfxCpu_bf.h and
IfxCbs_reg.h) and the iLLD intrinsics (__mfcr/__mtcr) from the
hardware debug monitor implementation.
The debug CSFR numbers, trigger-event register (TR0..TR7) addresses,
TREVT bit-field offsets and the CBS_OEC register address are now
defined locally with a TC_ prefix, so the file no longer leaks the
iLLD CPU_* namespace (which is still pulled in transitively through
arch/irq.h). Register accesses use the tricore_mfcr/tricore_mtcr
macros, and the DBGTCR/DBGCFG/DBGACT bit-field unions are replaced
with explicit shifts.
This is a pure de-iLLD refactor with no behavior change, verified on
a TC4x7 EVB: the board boots to NuttShell and breakpoints trigger
identically before and after the change.
Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>
add an MTD driver for the Macronix MX25UW25645G Octal SPI NOR flash.
Extend the QSPI transfer descriptors with octal and DTR flags so
controller lower halves can issue OPI transactions.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: OpenAI Codex:gpt-5
Add initial Apache NuttX support for the Allwinner D1 / T-Head C906
running in supervisor mode under OpenSBI.
Add support for:
- RV64 D1 architecture definitions
- Lichee RV 86 Panel board configuration
- UART0 console at 115200 baud
- D1 PLIC interrupt controller
- native D1 Timer1 scheduler tick
- early inherited-watchdog disable
- FLAT S-mode NSH configuration
The port has been tested on physical Sipeed Lichee RV / 86 Panel
hardware and boots to an interactive NuttShell.
The scheduler tick uses OSC24M Timer1 at 1000 Hz. The Timer1 interval
register is programmed with 23999 to produce exactly 24000 input clocks
per tick on the physical D1.
Assisted-by: OpenAI Codex:gpt-5.6-sol
Signed-off-by: Lance Harvie <lanceharvie@gmail.com>
The memory order '__ATOMIC_xxx' is not a name specified by the standard.
To achieve uniformity, if it is not defined, it will be defined one by
one in the order of 0 to 5.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
Add a fallback macro in compiler.h that defines __has_include(x) as 0
when the compiler does not natively support it. This allows simplifying
the guards in atomic.h by removing the defined(__has_include) check
and the __has_include(<stdatomic.h>) check, since __has_include is now
always defined and __STDC_NO_ATOMICS__ is sufficient to determine
atomic support.
The NEED_ATOMIC_MACROS logic is kept unchanged to preserve the C++
conflict fix from commit cd8ba3377c.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
Launder each register value through a register with an empty asm, on
loads and stores both, so the access is the width the source specifies.
Same fix as usbhost_xhci_pci.c commit 4b702058f6.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Launder each register value through a register with an empty asm, on
loads and stores both, so the access is the width the source specifies.
Same fix as usbhost_xhci_pci.c commit 4b702058f6.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Launder each register value through a register with an empty asm, on
loads and stores both, so the access is the width the source specifies.
Same fix as usbhost_xhci_pci.c commit 4b702058f6.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
Add initial NuttX port for the original (white) BeagleBone board, which is
powered by the TI AM335x Sitara Cortex-A8 processor.
This commit includes:
- Board documentation
- Board support package files derived from BeagleBone black
- Architecture-specific page allocator for memory management in kernel build.
- Default configurations for both flat (`nsh`) and kernel (`knsh`) builds
running via U-Boot from a microSD card.
Signed-off-by: Lwazi Dube <lwazeh@gmail.com>
When stdio buffering is disabled, fgetc/getchar on stdin always returned EOF
because fs_cookie and fs_oflags were left uninitialized and lib_fread_unlocked
bails out on (fs_oflags & O_RDOK) == 0.
Fix this by moving the initialization of the fs_cookie and fs_oflags outside the
CONFIG check; these fields need to be initialized regardless of
CONFIG_STDIO_DISABLE_BUFFERING.
In addition, initializing stream[i].fs_iofunc pointers to NULL is redundant
since the task group is allocated with kmm_zalloc/group_zalloc. Zero
allocation was already assumed on fs_flags, so remove the unnecessary code.
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Remove the feature #ifdef guard since the file
is conditionally compiled.
Remove the #ifdefs for other stm32 families that came from the
common stm32_wdg.h.
Add additional extended prescaler values for stm32h5 IWDG.
Change the WWDG_CFR_WDGTB shift value to match
what it should be on stm32h5. (WWDG not supported on stm32h5 yet.)
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Copy the common m3m4_v1 implementation. The only
difference is a debug log of the register which
contains the LSI enabled status bit. In the common
implementation the register is RCC_CSR. On stm32h5
it is RCC_BDCR.
The common implementation is _not_ used because it's
only built if CONFIG_STM32_COMMON_LEGACY which
stm32h5 currently is not. IWDG is added similarly to stm32l4.
STM32_HAVE_IP_WDG_M3M4_V1 is selected but a distinct
source file implements it.
Signed-off-by: Liam Howatt <liamhowatt@geotab.com>
Co-authored-by: Nathan Best <nathanbest@geotab.com>
USB class drivers do their transfers on the low priority queue and block
there, so one thread means a device waiting on a transfer stalls every
other user of the queue. usbhost_cdcacm.c says so at compile time when
CONFIG_SCHED_LPNTHREADS is 1.
The high priority queue keeps one thread. Nothing asks for more, and the
work it carries is meant to be short.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Both boards used the C string and memory routines while the
architecture's hand written ones sat unused beside them. A 64 bit core
with a filesystem, a network stack and a display above it spends a great
deal of its time in these functions, and the assembly moves a register at
a time rather than a byte.
RISCV_STRING_FUNCTION selects the whole set, so one symbol covers memcpy,
memset, memmove and the string routines together. The generic memset
tuning options go with it, since the C memset they tune is no longer
built.
These routines need the alignment fixes in apache/nuttx#19856 and
apache/nuttx#19857 to be correct on misaligned pointers.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
ESWIN's own evaluation board for this SoC. Where the StarPro64 is a
single board computer built around the chip, the EVB brings out most of
the SoC's interfaces.
Everything shared with the StarPro64 is already in the common directory,
so this carries the board's own facts: which UART reaches which connector,
which pads carry the boot straps, where its memory sits, and a
configuration starting from the same place the StarPro64's does.
The summary tables on sheet 3 of both boards' schematics are inherited
from ESWIN's reference design and describe that design rather than either
board. On this board the console is UART0 through the FT4232 bridge,
UART1 goes to the M.2 socket and a header, and UART2 reaches the RS232
port.
The documentation page follows the board template: a photograph, the
board's features, the console and its port on the FT4232 bridge, power,
the build and TFTP boot procedure, and what NuttX drives so far.
Boots to an NSH prompt over UART0 with all four harts running.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The port had one board directory holding one board, with everything in it
whether it described the SoC or the PCB. A second EIC7700X board follows,
so this adopts the common-plus-board layout NuttX provides, as mpfs uses.
boards/risc-v/eic7700x/common holds what is true of the SoC: the boot path
that mounts the RAM disk and /proc before calling the board's own bring
up, the linker script, the start up scripts and the image builder.
ARCH_CHIP_EIC7700X selects ARCH_BOARD_COMMON, so the symlinks the build
makes always point at code that compiles.
The board directory keeps what is a fact about the PCB: its own board.h
and board_memorymap.h, since the include fallback is all or nothing, a
bring up that owns the order its devices register in, and a board_config.h
declaring what that bring up may call.
The image builder moves to common/tools and derives its output name from
the configuration. It computes the padding between the kernel and the RAM
disk from _ebss rather than assuming 64 KiB, which fails once BSS grows
past it: the disk lands below _ebss and the BSS clear zeroes it before
anything searches for it.
The StarPro64 configuration gains what the port now needs: four harts,
960 MiB of RAM, a larger task stack, a backtrace on assert, the system log
in RAM for dmesg, and ELF applications, for which ARCH_CHIP_EIC7700X now
selects ARCH_HAVE_ELF_EXECUTABLE.
board.h loses its LED definitions. CONFIG_ARCH_LEDS is not set, nothing
implements board_autoled_on(), and the indices they gave named no LED.
The documentation pages gain the tags the template asks for.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Three faults in how the kernel maps itself.
The page pool covered the RAM disk, which the boot loader appends above
the kernel, so the BSS clear destroyed it before anything searched for it.
The pool now covers only pgram, and the RAM disk is mapped on its own
account.
The kernel data region is mapped with 2 MiB pages rather than 4 KiB ones.
Everything in it carries the same permissions, so the finer granularity
bought nothing while costing one L3 slab per 2 MiB from a pool of two.
The linker script and Kconfig describe the page pool separately and both
descriptions are used, so they now agree. When they disagree, pages
outside the smaller of the two get a virtual address of zero and are
written through, which on this SoC lands on identity mapped low memory
rather than faulting.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
External interrupts were enabled and claimed in the context of whichever
hart the firmware handed over on, which is not fixed. They reset routed
to wherever the boot loader left them, and an interrupt delivered to a
context nobody services cannot be told from a device that never raised
one.
Enable and claim in CPU0's S mode context, which is hart 0's. Steering a
source at another hart would mean choosing which, and NuttX has no way for
a driver to say.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The port ran on whichever hart the firmware handed over on, with a single
idle stack. The firmware does not pick the same hart every boot, so
nothing may assume one.
The hart that arrives first records which it was, indexes its idle stack
by its own ID, and restarts on hart 0; NuttX runs CPU0 there because that
is the only hart riscv_set_inital_sp() gives a whole idle stack to. The
first hart in owns the one time setup, and that guard lives in .data
because it is read before the BSS is cleared.
CONFIG_SMP_NCPUS below four is refused in chip.h: the hart the firmware
picked would have no slot and would stop in __start before it could
restart, which fails on some resets and not others.
Secondary harts are released through the common SBI helper rather than a
private copy of the same call.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The pins a board publishes are visible in /dev and each can be read
through its own node, but surveying a whole board that way means an open
and two ioctls per pin, and the signal and interrupt counters the upper
half keeps are not reachable through any of them.
Adds a list of registered pins and publishes it as /proc/gpio, behind
GPIO_PROCFS: a quality of life view of the same kind as /proc/pinctrl
and /proc/reset. Every common field comes from state the upper half
already holds: the pin type, the value through go_read(), how many times
the pin has been registered for signals, and how many interrupts it has
taken. Lines carry the same key:value tokens in the same order, so the
file is machine parseable.
Lower halves may supply an optional go_describe() adding what only they
can say, such as which pad carries the line or how its trigger is
configured. It writes text into a caller supplied buffer and the upper
half owns the line, so a lower half needs no procfs knowledge. A lower
half without it is listed with the common tokens alone.
The pin type index is bounded before use: it comes from the lower half
and the name table cannot cover a type the enumeration does not define.
A pin that cannot be read reports val:- rather than a zero that would
read as a real level.
procfs_register() appends without checking for duplicates, so the entry
is claimed once for the lifetime of the system rather than whenever the
list is empty; pins come and go at run time.
The name is held in a buffer as long as the one gpio_pin_register()
accepts, so a listing always names the same string as /dev.
The pin type name table is declared without an explicit size so that the
assertion beside it compares against the enumeration and can fail; sized
as [GPIO_NPINTYPES] it would have been tautological.
Documents the entry, its tokens, and how a lower half describes a pin.
Off by default: with GPIO_PROCFS unset the list, the lock and the procfs
entry are compiled out, and go_describe() is one more member at the end
of a structure existing lower halves do not reach.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Add a defconfig that runs CPython on qemu-intel64 (flat build) and
place the .PyRuntime section (created by the apps CPython port) in
.data so it is covered by the kernel physical mapping.
Signed-off-by: raiden00pl <raiden00@railab.me>
Assisted-by: Claude Code
The TMP112 driver was character mode only, and carried the warning that
says so: a read returns a bare float, at a size the driver chose, and
nothing but code written for this one part can make sense of it.
Add the sensor framework version beside it, in the shape the tree
already uses for a part that has both. The old driver is untouched and
still builds by default; the new one replaces it when
SENSORS_TMP112_UORB is set, and the part then appears as a temperature
topic that the common sensor tools can read without knowing what a
TMP112 is.
It reads on the low priority work queue at whatever interval the caller
asks for. The part converts continuously out of reset, so nothing is
configured and the temperature register always holds the last completed
conversion: a reading is one bus transaction with nothing to wait for.
Reading faster than the part converts repeats a value, which costs bus
traffic and nothing else, so the interval is taken as given: the upper
half treats a lower half that hands back a longer interval than it was
given as a failed request, so clamping here would refuse a fast caller
rather than serve it slowly.
get_info reports what the part is and what its readings mean, so a
consumer need not know it is talking to a TMP112 to know the range and
the resolution.
It also sign extends the reading. The register holds twelve bits, and
the character mode driver treats them as unsigned, so anything below
freezing comes back as a large positive temperature; the part is
specified down to -40C. Fixing that in the old driver would change what
existing callers see, so it is fixed here, where there are no callers
yet to surprise.
This driver also covers the TMP102, which differs in accuracy rather
than in its registers: only the two both parts have are touched.
Documented under the sensors section, beside the other parts with a page
of their own, and listed among the uORB drivers.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A driver author had to read the core to learn what a frequency table may
contain: the rules live in devfreq_table_validate() and in the four other
places that skip DEVFREQ_ENTRY_INVALID. State them where the special
values are defined instead. A table ascends, DEVFREQ_ENTRY_END terminates
it, DEVFREQ_ENTRY_INVALID stands in for a frequency the device cannot use
and is skipped by every consumer, and devfreq_register() rejects a table
whose usable entries do not ascend.
Say on get_table that it is called once, by devfreq_register(), which
keeps the returned table for the life of the device. That is a real
constraint on the caller, since the table cannot be on its stack, and
consumers outside the core retain the same pointer.
Comments only, no functional change.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The dummy driver's frequency cooling device is now a devfreq one, so the
configuration that tests it needs devfreq built. This is a change in what
the configuration covers, not just a symbol rename: nothing in the tree
registered a devfreq device before, and this is now the one place the
thermal to devfreq path runs without hardware.
Walking the dummy zone from 45 to 90 degrees steps the device through
every entry of its table, 900 down to 100, and back up as it cools.
The documentation follows the same rename, and devfreq's own page now says
that thermal is a requester and that a driver expecting to be throttled
wants DEVFREQ_CONFLICT_PREFER_LOW.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
