On Mon, May 2, 2016 at 11:10 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Mon, May 2, 2016 at 11:06 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> On Mon, May 2, 2016 at 11:04 AM, Geert Uytterhoeven >> <geert@xxxxxxxxxxxxxx> wrote: >> >>> [silly response deleted] >>> >>> Scrap it. >> >> :D >> >>> The only annoying thing is that 0 cannot easily be propagated upstream as >>> an error code, so it has to be tested for explicitly. >> >> Well with the Big Penguin's clear opinion on the matter there is not >> much we can do. >> >> What about this? >> >> diff --git a/drivers/tty/serial/serial_mctrl_gpio.c >> b/drivers/tty/serial/serial_mctrl_gpio.c >> index 02147361eaa9..2297ec781681 100644 >> --- a/drivers/tty/serial/serial_mctrl_gpio.c >> +++ b/drivers/tty/serial/serial_mctrl_gpio.c >> @@ -172,6 +172,13 @@ struct mctrl_gpios *mctrl_gpio_init(struct >> uart_port *port, unsigned int idx) >> dev_err(port->dev, >> "failed to find corresponding irq for >> %s (idx=%d, err=%d)\n", >> mctrl_gpios_desc[i].name, idx, ret); >> + /* >> + * Satisfy the error code semantics for a missing IRQ, >> + * 0 means NO_IRQ, but the framework needs to return >> + * a negative to deal with the error. >> + */ >> + if (!ret) >> + ret = -ENOSYS; > > No, not -ENOSYS, as that triggers my initial problem again (please read the > deleted silly response ;-) > Checkpatch says: "ENOSYS means 'invalid syscall nr' and nothing else". > > -EINVAL? Sure, whatever works with your semantics. Will you test & send a patch? Yours, Linus Walleij
