On Mon, Apr 13, 2026, 15:50 Sourabh Jain <[email protected]> wrote:
> > What is the rationale behind choosing a 60-second limit? > The 60-second value was chosen somewhat arbitrarily. Looking at rtas_busy_delay_time(), the maximum single delay returned is 100000ms (status 9905). In practice, legitimate busy delays are expected to be much shorter. I was following the spirit of rtas-rtc.c which uses a 5-second limit for simpler operations; fadump is a heavier firmware operation, so I went higher. I am open to suggestions on a more principled value. > > Would it make sense to introduce a helper function to wrap the > rtas_call, along with handling the wait time and timeout? > Absolutely, I will introduce a helper in v2. The three sites are indeed identical except for the FADUMP_REGISTER/UNREGISTER/INVALIDATE argument and the struct pointer/size. I will factor out the common busy-wait loop into a static helper. > Will send v2 shortly from my new email [email protected] > Adriano
