From: Joshua Grisham <josh@joshuagrisham.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: W_Armin@gmx.de, kuurtb@gmail.com, ilpo.jarvinen@linux.intel.com,
hdegoede@redhat.com, platform-driver-x86@vger.kernel.org,
corbet@lwn.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8] platform/x86: samsung-galaxybook: Add samsung-galaxybook driver
Date: Sat, 25 Jan 2025 14:42:32 +0100 [thread overview]
Message-ID: <CAMF+KeaGziFZasLT6KCqd_fYBTNeSPPMDMoXAFgdVLxE1tugMQ@mail.gmail.com> (raw)
In-Reply-To: <d242d780-9084-45c6-8df4-a78b48b80059@t-8ch.de>
Den lör 25 jan. 2025 kl 13:26 skrev Thomas Weißschuh <linux@weissschuh.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
next prev parent reply other threads:[~2025-01-25 13:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-18 20:26 Joshua Grisham
2025-01-23 23:42 ` Thomas Weißschuh
2025-01-25 11:45 ` Joshua Grisham
2025-01-25 12:26 ` Thomas Weißschuh
2025-01-25 13:42 ` Joshua Grisham [this message]
2025-01-25 15:06 ` Kurt Borja
2025-01-28 19:17 ` Joshua Grisham
2025-01-28 21:17 ` Thomas Weißschuh
2025-01-30 17:17 ` Joshua Grisham
2025-01-30 18:51 ` Thomas Weißschuh
2025-01-29 13:47 ` Ilpo Järvinen
2025-01-26 14:34 ` Armin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMF+KeaGziFZasLT6KCqd_fYBTNeSPPMDMoXAFgdVLxE1tugMQ@mail.gmail.com \
--to=josh@joshuagrisham.com \
--cc=W_Armin@gmx.de \
--cc=corbet@lwn.net \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kuurtb@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®