On Fri, Jul 03, 2026 at 10:51:37AM +0530, Varadarajan Narayanan wrote: > Quentin Schulz/Tom Rini, > > [ . . . ] > > > > > > > The issue is that the first sysreset device implementing the > > > > > > request_arg > > > > > > callback will consume the args and return EPROTONOSUPPORT which will > > > > > > stop the loop. > > > > > > > > > > > > Think about multiple sysreset devices, and let's say we have a new > > > > > > '- > > > > > > dummy' argument to the reset CLI command, then it'll depend on the > > > > > > registration order of the sysreset driver whether the dummy argument > > > > > > will be handled by the qcom driver which will return - > > > > > > EPROTONOSUPPORT since it isn't '-edl', or by the dummy sysreset > > > > > > driver. > > > > > > > > > > > > I think we should have a fourth possible return code which is "I > > > > > > don't > > > > > > know how to handle this argument", e.g. à-la IRQ_NONE in Linux > > > > > > kernel > > > > > > for interrupts that aren't for the device this IRQ handler was > > > > > > triggered > > > > > > for. Or maybe we should really be using -EPROTONOSUPPORT for that > > > > > > meaning and not exit the loop if that's the return code? > > > > > > > > > > > > Or maybe I misread or misunderstood the code? > > > > > > > > Following up here. > > > > > > > > > > Do we end up reverting just before the release then? > > > > Please send it out, cc everyone, and see if that gets some response? > > Sorry about the delay. Will post a change shortly.
Please review [1] Thanks Varada 1 - https://lore.kernel.org/u-boot/[email protected]/
