Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

[Geert Uytterhoeven]

Hi Uwe,

On Thu, Mar 23, 2017 at 12:11 PM, Uwe Kleine-KÃnig
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
>> Make sure to enable all drivers and subsystems you need when building
>> your kernel. That's always true. And may indeed be hard to debug (e.g. what
>> kernel options do I need to make systemd work?).
>
> It's worse here. If you forget to enable a driver the device isn't bound
> and that's obvious to diagnose. When ignoring an optional GPIO there
> might be a device that claims to work but fails to do so. (e.g. you
> write to memory, write() returns 0, but the data never landed there.)
>
>> > write(2) and close(2) succeed most of the time, too. Still it's not a
>> > good idea to not check the return value. Or let the kernel return
>> > success unconditionally.
>>
>> Writing all bytes passed in the buffer is "optional" in another sense than
>> an "optional" GPIO: you must retry the write, while you can continue if
>> an optional GPIO is not present.
>
> And that is the point. You can continue *iff* the optional GPIO is not
> present. The patch in question removes the ability to determine if that
> GPIO is present and claims it is not present.

If you forget to enable a driver/subsystem, you sometimes cannot determine
if the device is present or not neither.

Hence it boils down to "knowing" if there is a GPIO or not.
So, when can there be a GPIO?
  1. The GPIO is described in DT.
     => Not an issue, as DT GPIO implies GPIOLIB,
  2. The GPIO is described in legacy platform data.
     => The platform code should make sure GPIOLIB is selected when needed.

Issue solved?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds