[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMF+KeaGziFZasLT6KCqd_fYBTNeSPPMDMoXAFgdVLxE1tugMQ@mail.gmail.com>
Date: Sat, 25 Jan 2025 14:42:32 +0100
From: Joshua Grisham <josh@...huagrisham.com>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: W_Armin@....de, kuurtb@...il.com, ilpo.jarvinen@...ux.intel.com,
hdegoede@...hat.com, platform-driver-x86@...r.kernel.org, corbet@....net,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8] platform/x86: samsung-galaxybook: Add
samsung-galaxybook driver
Den lör 25 jan. 2025 kl 13:26 skrev Thomas Weißschuh <linux@...ssschuh.net>:
>
>
> You could designate a special error code to mean:
> "This feature is not supported, but that's fine and continue probing".
>
> For example EOPNOTSUPP:
>
> ret = init_foo();
> if (ret == 0)
> priv->have_foo;
> elif (ret != EOPNOTSUPP)
> return ret;
>
> ret = init_bar();
> ...
>
> [snip]
Hi Thomas! This is an good suggestion and might make it seem more
"native," which I like. One thing I am worried about, though, do you
think it is possible that any of the other functions called by these
various inits (registering various devices etc) could or might be
updated in the future to legitimately return EOPNOTSUPP, in which case
when I just pass their return code along there would be some
unexpected behavior? (that the driver does not unload but in fact
continues)
Or are you saying to return a positive EOPNOTSUPP instead of a
negative -EOPNOTSUPP to help ensure that this problem would be less
likely?
Thanks again!
Joshua
Powered by blists - more mailing lists