Connects the R5F to Linux remoteproc over the NAVSS mailbox.
The mailbox ISR only drains the FIFO and acknowledges; OpenAMP delivery is
deferred to HPWORK, because the rpmsg rx path takes mutexes and allocates.
The resource table publishes two vdevs, rpmsg and virtio-net, leaving every
vring address FW_RSC_ADDR_ANY: Linux allocates them from the R5F DMA pool and
rejects fixed addresses outside it.
Shared IPC memory is mapped Non-cacheable, since the R5F is not coherent with
the A53 and cached mappings leave NuttX reading stale vring state.
Also drops the duplicate arm_mpu.c from CHIP_CSRCS.
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Ulaş Sertan Kemeç <sertan.usk@gmail.com>
Add STM32_ETH_TIMESTAMP_RX for the STM32H7, as the one of the legacy
STM32 that provides the timestamp of the frames received.
Timestamp the PTP version 2 messages, over Ethernet and over UDP, except
for the announce, management and signaling messages. The MAC writes the
timestamp in a context descriptor after the last descriptor of the frame.
The driver reads it before giving the frame to the network stack and
passes it in d_rxtime, in the time of the system time of the MAC, the same
as /dev/ptp0. A frame that is not timestamped has a time of zero.
The timestamp goes over the address of the buffer of the context
descriptor, and the code that dropped the context descriptors used a
pointer that was never set. Keep the address of the buffer of each RX
descriptor, and restore it when a context descriptor is given back.
The timestamps of the PTP frames of a grandmaster clock were checked on
hardware against the system time of the MAC, and were within the delay of
the reads.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The STM32H7 page did not say anything about the Ethernet MAC.
- Describe the time counter of the MAC, the STM32_ETH_PTP option and its
behavior when the interface goes down.
- Describe the pulse-per-second output and the pins it can use.
- Describe the /dev/ptp0 clock the driver registers and the operations it
offers, and show a configuration that enables all of it.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The MAC has a system time that is the base of the PTP hardware
timestamps, but the driver never started it, and STM32_ETH_PTP only
printed a warning.
Add the registers of the timestamp unit and start the system time with
the fine update method and the digital rollover, so that the nanoseconds
count up to 10^9. The increment is 2 * 10^9 / HCLK ns, and the addend
makes the update rate half of HCLK, which leaves room to trim the
frequency in both directions. The time starts at zero right after the MAC
reset, not with the MAC configuration, so it does not depend on the PHY
having a link. The reset clears it, so it starts again each time the
interface goes up.
With STM32_ETH_PTP_GPIO, start the pulse-per-second output as a pulse
train with a period of one second and a width of half of it, at the whole
seconds of the system time. The fixed frequency mode of the MAC gives a
pulse too short to be seen, so the flexible mode is used. The interrupt
of the timestamp unit is not enabled in the MAC: it is set each time the
target time of the PPS output is reached and is cleared by reading
MACTSSR, which the interrupt handler does not do, so it would stay
pending and keep the handler running until the network stops.
Register /dev/ptp0 when CONFIG_PTP_CLOCK is set, so that a PTP daemon can
read and set the system time and correct its frequency and its phase.
The frequency is corrected by changing the addend, by up to 50% each way.
A step of the time is added or subtracted with the update register; with
the digital rollover a subtraction is programmed with the negated seconds
and with 10^9 minus the nanoseconds. The pulse train counts by itself, so
it does not follow a step of the system time and would be displaced by the
same amount: after the time is set or stepped, it is started again at the
next whole second.
With HCLK at 200 MHz the system time advanced 10.0018 s while a host
clock advanced 10.002 s, and the pulse train was seen on the pin. Reading,
setting, steps of +0.5 s and -1.25 s and a change of 100 ppm were done
through /dev/ptp0 on hardware, and the edges of the PPS output stayed at
the whole seconds of the system time.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The driver configured the pulse-per-second pin whenever STM32_ETH_PTP
was set, so a board that uses the timestamp unit without the pin still
had to define GPIO_ETH_PPS_OUT, and the pin was taken away from other
uses. The STM32F4 driver configures the pin with STM32_ETH_PTP_GPIO,
the option meant for it, but that option could not be selected on the
STM32H7, because it depended on the legacy STM32 families.
Configure the pin only with STM32_ETH_PTP_GPIO, and allow that option
on the STM32H7 and STM32H5.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
- Under CONFIG_NET_PROMISCUOUS, forward all control frames
(ETH_MACFFR_PCF_ALL) instead of only non-PAUSE ones, so link-local
PTP multicast reaches the DMA.
- Move ptp_to_timespec() above its first user so the TX timestamp path
can call it.
- stm32_receive(): do not log frames already delivered to packet
sockets (PTP, IPv6) as "Dropped, Unknown type".
- stm32_txtstamp_flush(): clear io_conn before freeing the looped-back
IOB.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Implement hardware TX timestamping support for STM32 Ethernet MAC
(stm32_eth_m3m4_v1.c) following the upstream SO_TIMESTAMPING loopback
architecture (PR #20161).
When an outgoing packet is flagged with SO_TIMESTAMPING (dev->d_iob->io_conn != NULL):
- Clone the IOB and hold a reference in priv->txmeta[txindex]
- Set ETH_TDES0_TTSE on the transmit DMA descriptor
- On transmission completion (stm32_freeframe), retrieve the hardware
timestamp from TDES6/TDES7, convert to timespec via ptp_to_timespec(),
and enqueue the clone onto priv->txtstampq
- Deliver pending TX timestamp clones back to netdev RX path in stm32_receive
using pkt_input(), where net/pkt intercepts the frame and delivers it to
userspace via recvmsg(..., MSG_ERRQUEUE)
- Properly drain pending queues and clones on interface down (stm32_ifdown)
Assisted-by: Gemini:gemini-3.8-pro
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
The Drop Transmit Status field of the MTL operation mode register is
bit 1, but it was defined as bit 0. The driver does not use it.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Implements the pthread_sigqueue Linux extension to pthreads. Follows a
similar implementation to sigqueue, except targeting a specific thread
through nxsig_dispatch.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
The page described how to write a lower-half driver but did not say
which ones are in the tree.
- List the two lower-half drivers that register a PTP clock, the dummy
driver and the Ethernet MAC of the STM32, with the option that
enables each.
- Say that the clock of the STM32 driver is the PTP counter of the MAC,
which is also the time base of the timestamps of the received
packets, and not CLOCK_REALTIME.
- Say that both use the device number 0 by default and so cannot be
registered at the same time.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The PHY was polled with nxsched_usleep(100) in a loop of 0x1998
iterations, so the time the link had to come up depended on the period
of the system tick. With the usual 10 ms tick that is about 65 s, but
with CONFIG_SCHED_TICKLESS and a 100 us tick it is about 0.65 s, shorter
than the auto-negotiation of the PHY (about 1.7 s on the board tested),
and the interface could not be brought up.
Poll every 10 ms and give the PHY up to 5 s, both for the link and for
the auto-negotiation to complete, whatever the tick.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The STM32F4 page did not say anything about the Ethernet MAC.
- Describe the time counter of the MAC and the options that enable the
timestamping of received packets, the pulse-per-second output and
the use of the counter as a high-resolution RTC.
- Describe the /dev/ptp0 clock that the driver registers: the
operations it offers, the numbering, and that the timestamps of the
received packets are values of the MAC counter and not of
CLOCK_REALTIME, so they have to be compared with /dev/ptp0.
- Show how to start ptpd with them and a configuration that enables
everything above.
- Say that the driver does not timestamp transmitted packets.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
The comment of stm32_eth_ptp_convert_rxtime() said that it converts to
CLOCK_REALTIME. Since the timestamp is delivered as the value of the
PTP counter of the MAC, which is the time base of /dev/ptp0, say
that.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
ptp_clock_dummy_getcrosststamp() stored the seconds of the monotonic
clock in the nanoseconds field of the monoraw member, so the
monotonic time of the cross timestamp was wrong. Store the nanoseconds.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
up_addrenv_va_to_pa() is declared in include/nuttx/arch.h but implemented
only by armv7-a, so no arm64 port can map a virtual address to a physical
one. A driver whose device addresses memory physically has nothing to call.
The translation is asked of the MMU with AT S1E1R rather than walked in
software, so it answers for whatever is actually mapped: any granule size,
block or page, at any level, and it cannot drift from the tables in use.
PAR_EL1 is one register per CPU, so nothing may run between the translation
and reading the result. Interrupts are banked with it, so masking them
locally is sufficient and SMP needs nothing further.
Returns zero for an address that is not mapped for a privileged read, which
is what the declaration in arch.h specifies. Note this differs from the
armv7-a implementation, which returns the virtual address unchanged.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
Document the common DMA driver framework and its usage.
Describe the DMA controller and client interfaces, channel and
transfer lifecycle, DMA links, controller implementation
requirements, and existing in-tree users.
Add references to the audio DMA and 16550 UART implementations
to provide concrete usage examples.
Signed-off-by: Arnav Sharma <2006arnavsharma@gmail.com>
Allocate the new handler node independently of the initial chain
conversion so handlers beyond the second are appended instead of silently
dropped. Delay vector conversion until both required nodes are available
to avoid leaving a partially constructed chain on allocation failure.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
xhci_enumerate() reports failure by marking the hub port disconnected,
which is what makes xhci_wait() return and the attempt repeat. The root
port is still connected, so the two disagree again immediately and the
attempt repeats for as long as the device stays plugged in. A device that
fails every time is retried forever: 1055 attempts in 90 seconds on an
EIC7700X board, enough console traffic to make the board unusable.
Count consecutive failures per root port and stop at
CONFIG_USBHOST_XHCI_ENUM_RETRIES, leaving the port as it is so xhci_wait()
blocks until something physically changes. A new connection clears the
count, as does a successful enumeration, so a device needing a second
attempt still gets one. The default of three rides out a slow device or a
marginal reset.
The same board now makes three attempts, reports that it has given up and
falls silent, while a keyboard on the other port enumerates throughout.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A device slot is a finite controller resource: HCSPARAMS1 reports how many
exist and Enable Slot fails with No Slots Available once they are gone.
Two paths took one and returned without giving it back.
xhci_device_init() enables a slot before initialising the transfer ring,
the slot context and the device address, and each of those returned
directly on failure. It also treated a slot number larger than the
controller supports as success, since Enable Slot itself had succeeded.
xhci_enumerate() is the larger leak: the device is addressed by the time
usbhost_enumerate() runs, so a device whose descriptor cannot be read, or
that no class driver claims, leaves the slot held. That path clears
hport->connected so the port is retried, taking another slot each time.
Release the slot on both paths with xhci_device_deinit(), which issues
Disable Slot, clears the DCBAA entry and resets the context. The endpoint
ring is left allocated; xhci_ring_init() reuses an existing one.
Tested on an EIC7700X board with a device no class driver claims, so the
port retries indefinitely: previously the eighth attempt failed with
completion code 9 and the controller enumerated nothing further on either
port; now 1104 consecutive attempts produced no slot failure.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
xhci_ctrl_xfer() and xhci_transfer() release the controller lock before
xhci_transfer_wait(), so the lock does not cover the interval in which a
transfer is outstanding. Two threads issuing requests on the same
endpoint both reach xhci_ioc_setup(), and the second trips the
DEBUGASSERT(!epinfo->iocwait) that guards it, or overwrites the first
thread's completion state where assertions are compiled out.
A default control endpoint reaches this readily: every interface driver on
a composite device speaks through endpoint 0, so a two interface HID
keyboard runs two poll threads both issuing GET_REPORT.
Other host controller drivers hold the controller lock across the wait,
which here would serialise the whole controller and give up the per
endpoint rings xHCI provides. Add a mutex to struct xhci_epinfo_s and
hold that instead. It is taken before the controller lock on both paths,
so the order is endpoint then controller.
xhci_epfree() also freed the endpoint container without destroying iocsem.
Destroy both.
Reachable on any xHCI controller, independently of the preceding commits.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Submitting an asynchronous transfer refused any buffer needing a cache
line stand-in, and that test also refuses every buffer whose length is not
a whole number of cache lines, which an interrupt transfer's rarely is: a
HID keyboard reads eight bytes. Every submission returned -EFAULT before
a descriptor was written, and a class driver resubmitting from its
completion callback never sees a second chance.
The refusal existed because the copy out of a stand-in is done by the
blocked caller, and an asynchronous transfer has none. The work queue
thread handling the completion will do: a buffer given to DRVR_ASYNCH
comes from DRVR_ALLOC, so it is kernel memory reachable from any thread.
Use the same stand-in machinery as every other transfer and finish the DMA
in the completion, just before the callback. A cancelled transfer returns
its stand-in on cancellation.
The callback also moves outside the spinlock. It is class driver code
that queues work and takes its own locks, and it may now free a stand-in.
Whether a completion is synchronous is still decided under the lock, since
a posted waiter may be carrying a new transfer immediately.
The asynchronous setup now records the requested length, as the
synchronous setup does. The byte count handed to the callback is worked
out from it and the residue, and was previously whatever the endpoint held
from an earlier transfer.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A root hub port whose enumeration failed is enumerated again, and the slot
the failed attempt used has been given back by then, so the port has no
device context behind it. xhci_epalloc() took that pointer and wrote the
new endpoint through it without looking, so the retry stored through NULL
and took the system down in answer to a device that had merely failed to
come up.
Check for the device, and free the endpoint that has no home rather than
leaking it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The Interval field of an endpoint context is an exponent: the controller
services the endpoint every 2^Interval microframes. An endpoint
descriptor states its period differently depending on device speed, so the
number cannot be copied across, which is what this did. A low speed
keyboard asking to be polled every 10ms was programmed as 2^10
microframes, which the controller would not accept: Configure Endpoint
went unanswered and allocation failed with -EIO.
Low and full speed interrupt endpoints state a period in frames, so the
exponent is the highest bit of that period in microframes, clamped to the
range the specification allows. Other periodic endpoints already state an
exponent, one greater than the one wanted here. Control and bulk
endpoints are not periodic and the field means nothing to them.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The copy out of a stand-in was done in the completion handler, which runs
on a work queue, while the buffer it copies into may belong to a user
process whose addresses mean nothing there. Reading a block device
directly from a user program faulted. The caller is blocked until the
transfer finishes, so the copy belongs there.
An asynchronous transfer has no blocked caller to come back to, so a
buffer that would need a stand-in is refused for that path. Its callers
are class drivers using kernel memory, which do not need one. The
refusal is lifted once the completion path can do the copy itself.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Report each device as it comes up, and report it going away.
The announcement is made at the end of the port enable rather than at
connect, because the PORTSC speed field means nothing until the port has
been reset: a USB2 port reports its reset default, full speed, until then,
so every device would be announced at 12Mbps regardless of what it
negotiates a moment later.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A transfer described by more than one TRB can reach the end of the ring
part way through, so the link that sends the controller back to the
beginning falls inside the transfer rather than between two of them.
Written without the chain bit, that link ends the transfer where it
stands: the controller follows it, considers the work finished, and
reports nothing, because the TRB that asked for the completion interrupt
is on the far side of the join. Nothing waiting is woken, and transfers
have no timeout, so the symptom is a read that never returns.
Carry the chain bit onto the link when the TRB it follows has it.
Reading 1MiB from a USB drive, where the last two sizes did not complete
at all before:
512 byte blocks 166 KB/s
4 KiB blocks 1333 KB/s
32 KiB blocks 10666 KB/s
64 KiB blocks 15515 KB/s
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
What a controller is told about a device before it will accept it. A DWC3
core validates these where QEMU's controller does not.
- HCCPARAMS1 says whether context structures are 32 or 64 bytes, and the
wider form was refused outright with -EIO; the EIC7700X reports
0x0220fe45 on both of its controllers, so this driver could not have
driven either. A wide context is the same fields with reserved space
after them, so only the stride changes. Read it at start up and use it
wherever a context array is walked.
- Contexts must be 64 byte aligned, since every device context base
address array entry points at one, and the output context came from
kmm_zalloc().
- The slot context never carried the device speed, which has no valid
zero, so a validating controller answers Address Device with a parameter
error. The speed was already implied by the endpoint context's maximum
packet size. The numbering is xHCI's own, hence the mapping.
- The output device context was cleared and never flushed. That context
is the controller's to write, so what stays behind is a dirty line of
zeros written back over the slot state, and the next command against the
slot is refused with a context state error. Enumeration reached
SET_ADDRESS and stopped.
- A buffer copied through an aligned stand-in was copied back using buflen,
which control transfers deliberately leave zero, so a descriptor read
copied nothing back and the caller was handed whatever its buffer held
before. Keep the requested length separately, and maintain the cache
over the whole stand-in rather than the part in use.
- A buffer the controller cannot reach is now copied through a stand-in
rather than refused. -EFAULT works for a caller with somewhere better
to put the data, and fails outright for one without: reading a block
device directly from a user program returned an error where the transfer
could have gone through a stand-in.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The number of event ring segments a controller allows is a power of two
reported as its exponent, and the exponent can reach 15. Computing
1 << exponent into the uint8_t that holds it wraps to zero on any
controller offering more than 128 segments, and a controller told its
event ring table holds no entries has nowhere to report anything: every
command times out.
Work it out at full width and narrow afterwards.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A failed command logged only its completion code. The difference between
a refused Address Device and a refused Evaluate Context is most of the
diagnosis, and the completion code does not give it.
Keep the command type before the result overwrites the TRB, and name it in
the message.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The register dump read HCIVERSION with a 32-bit access at offset two. It
is a 16-bit register sharing a word with CAPLENGTH, so that is an
unaligned read of a device register: harmless where the bus permits it and
a fault where it does not.
Read the word once and take both fields from it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The controller moves every byte itself, so on a machine whose caches are
not coherent with it the driver must flush before the controller reads and
invalidate before the processor does. Data buffers got no maintenance at
all: nothing pushed before an OUT, nothing dropped after an IN.
Cache operations act a whole line at a time, which is unsafe for a buffer
that does not own its lines: invalidating drops whatever else shares the
line, and a writeback lands on top of what the controller has just put
there. Mass storage passes a 31 byte command block and a 13 byte status
out of its instance structure. Such a buffer is copied through an aligned
stand-in; anything large comes from a filesystem or from xhci_ioalloc(),
which now rounds its length up as well as aligning its start, so what it
returns owns its last line.
Whether the controller can reach a buffer at all is asked of the platform
through a new dmacapable operation, since it is a property of the system
the controller was fitted into rather than of the controller. A platform
that does not supply it is taken to accept every address, which is what
existing users have. A refused buffer gives -EFAULT, which the FAT
filesystem answers by retrying through its own DMA-safe sector buffer.
The device output context is also invalidated before the assigned address
is read out of it; the controller wrote that address, and reading without
invalidating returns whatever the processor had cached.
Compiles to nothing where there is no cache to maintain, and dmacapable is
NULL on PCI, so the existing user is unaffected.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
A Normal TRB describes one run of memory that may not cross a 64K
boundary, and the block layer hands down whole multi-sector reads whose
length is bounded by nothing here. One TRB was programmed regardless, so
a long enough transfer, or merely one starting near the wrong side of a
boundary, produced a descriptor the controller is entitled to reject or to
satisfy in part.
Program as many as the run needs, chained, asking for the completion
interrupt only on the last so one event still arrives for the transfer.
A transfer needing more TRBs than the ring holds is refused.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
xhci_ctrl_start() published the event ring segment table, the device
context base address array and the scratchpad pointers with
up_flush_dcache_all(), which an architecture whose cache can only be
maintained by address implements as a barrier and nothing more, so none of
them reached memory. The controller then reads whatever those addresses
held before, which presents as every command timing out with no events
arriving. Flush each structure by address.
xhci_ring_init() has the same fault from the other direction: it clears a
whole ring and flushes only the link entry it writes afterwards, leaving
the rest of the clearing in the cache. The controller writes into that
memory itself, so a line written back later lands on top of an event
somebody is waiting for. Flush the whole ring.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The interval was left at its reset value of 4000, a millisecond, which is
how long the controller waits after an event before reporting it. Every
completion paid that, and mass storage spends three transfers on a
request.
Set it to 160, which is 40us, as Linux does. Zero puts no bound on how
often a controller may interrupt: a keyboard on an interrupt endpoint then
takes them continuously and occupies a processor.
Measured on a DWC3 with a USB 2.0 drive, doorbell to interrupt 986-1021us
before and 13-56us after:
reading 1MiB before after
512 byte blocks 166 KB/s 775 KB/s
32 KiB blocks 10666 KB/s 18618 KB/s
mounting a FAT32 volume: 92.7s before, 21.1s after
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The handler read the status, queued the work that would answer it, and
returned with the source still asserted. On a level triggered line the
interrupt controller sees the condition still true and raises it again at
once, so the work that would have cleared it never runs.
Mask the interrupter in the handler and let the worker unmask when it is
done. The unmask clears the pending flag in the same write, because a
message is sent on that flag's clear to set transition and events that
arrived while the interrupter was masked have already set it.
Clearing opens its own window, so the worker drains the ring again after
unmasking and repeats while a drain finds anything; xhci_events_poll()
returns how many events it handled for that purpose. A drain that finds
nothing is the only state in which no event can have been lost.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The event ring was acknowledged after being walked. An event arriving
during the walk sets the pending bit again, and clearing the bit
afterwards discards it. Transfers have no timeout, so the transfer that
event belonged to waits forever.
Acknowledge first. A spurious second pass over an empty ring costs
nothing.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
xhci_probe_ports() wrote PORTSC back to clear the change bits, including
PED, which is write-one-to-clear. A port that came up enabled, which is
what a device attached at power up produces, was switched off by the act
of reading it.
Mask PED out of the value written back. The port status worker already
does this.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The handler defers to a worker that walks the event ring, and the ring is
not allocated until the controller is started, several steps later. A
controller left running by a boot loader has an interrupt pending as soon
as the line is enabled, so attaching earlier is a race with nothing able
to answer it.
Attach after the start, and clear USBSTS and the interrupter pending flag
once the handler is in place: a message signalled interrupt is sent on the
flag's clear to set transition, so a flag raised before the handler
existed would never produce another.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
Describe the jail, leftover pre-opened fds, the NSH command-form scrub,
and the flat-build trust boundary shared with credentials.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Add CONFIG_FS_CHROOT and POSIX chroot(). Store the jail as an
absolute path on the task group, and require euid 0 when user
identity is enabled.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Prepare paths in inode_search_setup(): prepend tg_root, canonicalize
with a jail-floor dst_min, then walk from g_root_inode. Replace
SETUP_SEARCH / RELEASE_SEARCH with inode_search_setup() /
inode_search_release().
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Store the jail as an absolute path on the task group, copy it to
children, and free it when the last member leaves.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
The voltage, current, power, resistance and conductivity messages
declare their measurement as float, where every other message in
uorb.h declares it as sensor_data_t. That type is b16_t under
CONFIG_SENSORS_USE_B16 and float otherwise, so on a fixed point
configuration these five are the only sensors still producing floats.
A driver that computes in sensor_data_t, as the helpers in fixedmath.h
encourage, then assigns a b16_t to a float field: the raw fixed point
integer is stored as a float and the reading is wrong by 65536 with no
diagnostic.
The accumulators keep int64_t. Energy in uJ and charge in uC are
counts of micro units rather than measurements, and neither is
affected by the fixed point option.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Justin Hammond <justin@dynam.ac>
The page did not match the code in several places.
- Describe struct ptp_ops_s as it is: adjfine takes parts per billion,
adjphase, getres and control exist, there is no getcaps, and gettime
has a system timestamp argument. State which operations are optional
and give the real ptp_clock_register() arguments.
- Replace the CLOCKFD() macro, which does not exist, with the clock
identifier built from CLOCK_SHIFT and CLOCK_FD, in all examples.
- Fix the frequency values: struct timex freq is in parts per million
with 16 fractional bits, so +10 ppm is 655360.
- List the modes clock_adjtime() handles for a PTP clock
(ADJ_SETOFFSET, ADJ_FREQUENCY, ADJ_OFFSET for the phase) and say that
the others return -ENOTSUP.
- PTP_CLOCK_GETTIME and PTP_CLOCK_SETTIME take a struct timespec. Add
the ioctls that were missing.
- The dummy driver uses CLOCK_REALTIME, not the monotonic clock.
- Point to ptpd instead of ptp4l and timemaster, which are not part of
NuttX, and use the real CONFIG_DEBUG_PTP options.
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Assisted-by: Claude:claude-sonnet-5
GCC 15 added -Wunterminated-string-initialization, and both constants fill
their array exactly, leaving no room for the terminator. Every build with
that compiler fails, since crypto/Makefile treats warnings as errors.
Neither is used as a string: they are read as sixteen bytes through
U8TO32_LITTLE(). Letting the array size follow the literal keeps them
readable, costs one byte each, and needs no attribute that only some
compilers have.
The cipher state is unchanged for both key sizes.
Signed-off-by: Royyan Zahir <royzah@gmail.com>
Variable conn is declared and initialized in append_timestamping()
but never referenced, triggering -Wunused-variable compiler warning.
Assisted-by: Gemini:gemini-3.8-pro
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
Implement lower-half PTP hardware clock operations (struct ptp_lowerhalf_s
and struct ptp_ops_s) in the STM32 Ethernet driver and register it with the
generic PTP clock framework (drivers/timers/ptp_clock.c) to expose /dev/ptp0.
Supported operations:
- adjfine: adjust PTP clock frequency in parts per billion (ppb)
- adjphase: adjust PTP clock phase via hardware TSSTU
- adjtime: shift PTP clock time by signed delta in nanoseconds
- gettime: atomic double-read of hardware timestamp registers
- settime: initialize hardware timestamp counter via TSSTI
- getres: return 1 ns clock resolution
Also fix a sign bug in stm32_eth_ptp_adjust() where uint64_t addend
promoted negative ppb adjustments to unsigned, corrupting frequency trim
for crystals running faster than nominal.
Follow-up to #20148 per review recommendation to use the standard POSIX
/dev/ptp0 character driver instead of custom socket ioctls.
Assisted-by: Gemini:gemini-3.8-pro
Signed-off-by: Daniel P. Carvalho <danieloak@gmail.com>
