From: "Danilo Krummrich" <dakr@kernel.org>
To: "Greg KH" <gregkh@linuxfoundation.org>
Cc: <rafael@kernel.org>, <broonie@kernel.org>, <will@kernel.org>,
<grygorii.strashko@ti.com>, <ssantosh@kernel.org>,
<khilman@kernel.org>, <linusw@kernel.org>, <brgl@kernel.org>,
<driver-core@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-omap@vger.kernel.org>, <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH] gpio: omap: do not register driver in probe()
Date: Fri, 23 Jan 2026 16:48:01 +0100 [thread overview]
Message-ID: <DFW34RKI0FBC.WRKWPAS6IBN7@kernel.org> (raw)
In-Reply-To: <2026012302-nutmeg-grandly-1a09@gregkh>
On Fri Jan 23, 2026 at 4:23 PM CET, Greg KH wrote:
> On Fri, Jan 23, 2026 at 03:25:43PM +0100, Danilo Krummrich wrote:
>> On Fri Jan 23, 2026 at 3:19 PM CET, Greg KH wrote:
>> > But there are no platform resources for this at all, shouldn't this be a
>> > faux device instead?
>>
>> Probably, but that's for another patch, since this one may potentially be
>> backported beyond the existence of the faux bus.
>>
>> > That being said, ignoring the return value of platform_device_register()
>> > is probably not something we want to keep around.
>>
>> Yes, as mentioned below the commit message, there are a couple of things that
>> need to be followed up on here.
>>
>> With this patch I only intend to fix the deadlock condition and otherwise keep
>> all the existing semantics as it is.
>>
>> I.e. maybe it is intentional and this driver should not abort probing if this
>> can't be registered for some reason.
>
> Ok, fair enough, fixing this immediate bug is good enough for me.
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just for the record, the things that should still be addressed:
(1) Potential UAF on module unload: The device is declared as global static
(should use a dynamic allocation instead); device is never unregistered.
(2) Handle return value of *_device_register().
(3) Use faux bus; maybe not directly suitable as omap_mpuio_driver only uses
struct dev_pm_ops callbacks. Though, we could extend struct
faux_device_ops accordingly.
- Danilo
next prev parent reply other threads:[~2026-01-23 15:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 13:31 [PATCH] gpio: omap: do not register driver in probe() Danilo Krummrich
2026-01-23 13:44 ` Danilo Krummrich
2026-01-26 9:06 ` Bartosz Golaszewski
2026-01-26 11:35 ` Danilo Krummrich
2026-01-23 13:57 ` Danilo Krummrich
2026-01-23 14:19 ` Greg KH
2026-01-23 14:25 ` Danilo Krummrich
2026-01-23 15:23 ` Greg KH
2026-01-23 15:48 ` Danilo Krummrich [this message]
2026-01-27 9:09 ` Bartosz Golaszewski
2026-01-27 13:37 ` Danilo Krummrich
2026-01-27 19:26 ` Bartosz Golaszewski
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=DFW34RKI0FBC.WRKWPAS6IBN7@kernel.org \
--to=dakr@kernel.org \
--cc=brgl@kernel.org \
--cc=broonie@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=grygorii.strashko@ti.com \
--cc=khilman@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=ssantosh@kernel.org \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.