On Sat, Jan 28, 2023 at 2:46 AM Gregory Nutt <spudan...@gmail.com> wrote:
> Typically, if you want to pass a small amount of information from an > interrupt handler to a task, you would use a normal IPC like sigqueue() > (https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigqueue.html) which > allows to send a type union sigval to the task. > > The task would have to catch the signal with something like > sigwaitinfo() > (https://pubs.opengroup.org/onlinepubs/7908799/xsh/sigwaitinfo.html). > > Originally, you could use mq_send() from interrupt handlers to send > interrupt status to tasks, but unfortunately that feature was lost with > some recent commits that redesigned the message handler that were > apparently done without knowledge of that requirement. NOTE that the > documentation is now wrong, it says that you can still messages from > interrupt handlers. That is not true. > Yes, with the new design mq_xxx can't be called from interrupt context since mq is a normal file handle and then needs to hold file lock to do fd->file conversion. But, there are new API for kernel user which start with file_mq_xxx, this set of API can still be called from the interrupt handler context. > > On 1/27/2023 12:15 PM, Nathan Hartman wrote: > > Is there a global structure where you retain state information where it > > would be appropriate to save the most refent known state in a volatile > > variable? > > > > On Fri, Jan 27, 2023 at 1:00 PM Tim Hardisty <t...@hardisty.co.uk> wrote: > > > >> Think this is an easy one but it's stumped me so far... > >> > >> I am setting up the USB Overcurrent interrupt and can't find any fully > >> implemented examples. > >> > >> The interrupt is set to both edges as I want to know when the over > current > >> state is first set and later hopefully cleared. > >> > >> I can obviously read the state of the input pin, but I sort of feel I > >> should be able to pass the state as an arg to the handler (via xcpt_t > >> handler). > >> > >> Is that possible and, if so, how? > >> > >
