Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Nov 2022 15:57:53 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= 
        <u.kleine-koenig@pengutronix.de>
Cc:     Mika Westerberg <mika.westerberg@linux.intel.com>,
        Hans de Goede <hdegoede@redhat.com>,
        Thierry Reding <thierry.reding@gmail.com>,
        linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
        linux-pwm@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v2 5/6] pwm: lpss: Add pwm_lpss_probe() stub
Message-ID: <Y25U4S2OAOskKI60@smile.fi.intel.com>
References: <20221108142226.63161-1-andriy.shevchenko@linux.intel.com>
 <20221108142226.63161-6-andriy.shevchenko@linux.intel.com>
 <20221110073831.ggudvgl6jzgbo2vb@pengutronix.de>
 <CAHp75Ve837d_2UEQRMJEcmOdPVdqSAKv+dJje057uJouCPAe9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHp75Ve837d_2UEQRMJEcmOdPVdqSAKv+dJje057uJouCPAe9Q@mail.gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Thu, Nov 10, 2022 at 12:01:50PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 10, 2022 at 9:38 AM Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Tue, Nov 08, 2022 at 04:22:25PM +0200, Andy Shevchenko wrote:
> > > In case the PWM LPSS module is not provided, allow users to be
> > > compiled with a help of a pwm_lpss_probe() stub.

...

> > > +static inline
> > > +struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, void __iomem *base,
> > > +                                  const struct pwm_lpss_boardinfo *info)
> > > +{
> > > +     return ERR_PTR(-ENODEV);
> >
> > Would it be more consistent to return the same value as the pwmchip_add
> > stub does?
> 
> Then I will lose the ability to distinguish between absent driver (or
> device) and actual error during the probing of it. Any suggestions on
> how to do that better?

Independently on the above, I think that _probe() != _chip_add() semantically
and having the same, and we know weird, return code doesn't make it anyhow
better. I believe that -ENODEV is the best fit here.

That said, I leave it as is for v3 and we may continue discussing it there.

-- 
With Best Regards,
Andy Shevchenko