Re: [PATCH] gpio: omap: do not register driver in probe()

["Danilo Krummrich" <dakr@kernel.org>]

On Fri Jan 23, 2026 at 3:19 PM CET, Greg KH wrote:
> On Fri, Jan 23, 2026 at 02:57:45PM +0100, Danilo Krummrich wrote:
>> On Fri Jan 23, 2026 at 2:31 PM CET, Danilo Krummrich wrote:
>> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> > index e136e81794df..8db71a2db9ff 100644
>> > --- a/drivers/gpio/gpio-omap.c
>> > +++ b/drivers/gpio/gpio-omap.c
>> > @@ -800,9 +800,7 @@ static struct platform_device omap_mpuio_device = {
>> >  static inline void omap_mpuio_init(struct gpio_bank *bank)
>> >  {
>> >  	platform_set_drvdata(&omap_mpuio_device, bank);
>> > -
>> > -	if (platform_driver_register(&omap_mpuio_driver) == 0)
>> > -		(void) platform_device_register(&omap_mpuio_device);
>> > +	(void)platform_device_register(&omap_mpuio_device);
>> >  }
>> 
>> On a second look, it recognize that this did abuse the fact that
>> platform_driver_register() fails when attempting to register a driver multiple
>> times to avoid registering the same static device multiple times.
>> 
>> So, I guess this has to be changed to:
>> 
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index 8db71a2db9ff..3e1ac34994fb 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -799,8 +799,13 @@ static struct platform_device omap_mpuio_device = {
>> 
>>  static inline void omap_mpuio_init(struct gpio_bank *bank)
>>  {
>> +       static bool registered = false;
>> +
>>         platform_set_drvdata(&omap_mpuio_device, bank);
>> -       (void)platform_device_register(&omap_mpuio_device);
>> +       if (!registered) {
>> +               (void)platform_device_register(&omap_mpuio_device);
>> +               registered = true;
>> +       }
>>  }
>
> 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.