From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] [media] cec: Handle RC capability more elegantly
Date: Wed, 5 Apr 2017 10:09:33 +0100 [thread overview]
Message-ID: <20170405090933.ji6bapwcvnrinz5z@dell> (raw)
In-Reply-To: <20170404163455.GD7909@n2100.armlinux.org.uk>
On Tue, 04 Apr 2017, Russell King - ARM Linux wrote:
> On Tue, Apr 04, 2017 at 05:10:05PM +0100, Lee Jones wrote:
> > @@ -237,7 +241,6 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
> > if (!(caps & CEC_CAP_RC))
> > return adap;
> >
> > -#if IS_REACHABLE(CONFIG_RC_CORE)
> > /* Prepare the RC input device */
> > adap->rc = rc_allocate_device(RC_DRIVER_SCANCODE);
> > if (!adap->rc) {
>
> The above, coupled with patch 1:
>
> +#ifdef CONFIG_RC_CORE
> struct rc_dev *rc_allocate_device(enum rc_driver_type);
> +#else
> +static inline struct rc_dev *rc_allocate_device(int unused)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}
> +#endif
>
> is really not nice. You claim that this is how stuff is done elsewhere
> in the kernel, but no, it isn't. Look at debugfs.
I'm afraid you have entered half way through a conversation, which as
caused a misunderstanding. Apologies for not being clear in my commit
log.
When I say "this is how it's done else where", that is in reference to
offering stubs which can be tucked away in a header file, rather than
being forced to #if out any functionality which is not available.
> You're right that debugfs returns an error pointer when it's not
> configured. However, the debugfs dentry is only ever passed back into
> the debugfs APIs, it is never dereferenced by the caller.
Continued on from my last point:
What I do not mean is that this solution is perfect and does not
require a review. You are completely correct in what you say, the
return values I have used are not suitable. I failed to see how
callers were treating the return value. I will carry out due
diligence on that point and re-submit as per your request.
> That is not the case here. The effect if your change is that the
> following dereferences will oops the kernel. This is unacceptable for
> a feature that is deconfigured.
Fair point Russell. Thanks, will fix.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2017-04-05 9:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 16:10 [PATCH 1/2] [media] rc-core: Add inlined stubs for core rc_* functions Lee Jones
2017-04-04 16:10 ` [PATCH 2/2] [media] cec: Handle RC capability more elegantly Lee Jones
2017-04-04 16:34 ` Russell King - ARM Linux
2017-04-05 9:09 ` Lee Jones [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-04-05 10:37 [PATCH 1/2] [media] rc-core: Add inlined stubs for core rc_* functions Lee Jones
2017-04-05 10:37 ` [PATCH 2/2] [media] cec: Handle RC capability more elegantly Lee Jones
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=20170405090933.ji6bapwcvnrinz5z@dell \
--to=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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