Re: [PATCH 7/8] gpio: bd73800: Support ROHM BD73800 PMIC GPIOs

[Bartosz Golaszewski]

On Sun, 12 Jul 2026 17:42:17 +0200, Matti Vaittinen
<mazziesaccount@xxxxxxxxx> said:
> pe 3.7.2026 klo 16.11 Bartosz Golaszewski (brgl@xxxxxxxxxx) kirjoitti:
>> > +
>> > +     if (!g->num_pins) {
>> > +             /*
>> > +              * The BD73800 may or may not have pins allocated for GPIO
>> > +              * depending on the OTP used at manufacturing. Free the memory
>> > +              * and go out if there is no pins as then we have nothing to do
>> > +              */
>> > +             dev_dbg(dev, "no GPIO pins\n");
>> > +             devm_kfree(dev, g);
>>
>> No need for that, because...
>>
>> > +             return 0;
>>
>> ... this will still leave a bound device in the system, I'm not sure we want
>> it? The correct error code in this case is -ENODEV.
>
> I am a bit uncertain. This isn't really an error. It should be very
> much Ok to configure the support for PMICs with GPIOs to be compiled -
> and also very much Ok to have a PMIC with no GPIOs. Returning an error
> doesn't feel right. Furthermore, I am afraid that returning an error
> might hurt the system start-up? Do you see some really problematic
> consequences if we return Ok without registering the GPIOs. I'd assume
> that wastes some bytes but I don't see other really severe
> consequences.

But -ENODEV/-ENXIO error codes are meant to do exactly that - tell the driver
core to assume this device legitimately cannot be enabled on this system. There
will be no error splat in the kernel log and the probe will not be deferred.

This really isn't the first device to need this behavior. :)

Bart