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. Thanks Varada
