Re: [PATCH v2 1/5] pwm: dwc: drop redundant error check

[Andy Shevchenko]

On Thu, Feb 15, 2024 at 10:22:57AM +0100, Uwe Kleine-König wrote:
> On Wed, Feb 14, 2024 at 07:54:58PM +0200, Andy Shevchenko wrote:
> > On Wed, Feb 14, 2024 at 06:45:48PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Feb 08, 2024 at 07:04:33PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 08, 2024 at 08:46:44AM +0100, Uwe Kleine-König wrote:
> > > > > On Thu, Feb 08, 2024 at 12:35:25PM +0530, Raag Jadav wrote:
> > > > > > pcim_iomap_table() fails only if pcim_iomap_regions() fails. No need to
> > > > > > check for failure if the latter is already successful.
> > > > > 
> > > > > Is this really true? pcim_iomap_table() calls devres_alloc_node() which
> > > > > might fail if the allocation fails. (Yes, I know
> > > > > https://lwn.net/Articles/627419/, but the rule is still to check for
> > > > > errors, right?)
> > > > 
> > > > We do not add a dead code to the kernel, right?
> > > > 
> > > > > What am I missing?
> > > > 
> > > > Mysterious ways of the twisted PCI devres code.
> > > > Read the above commit message again :-)
> > > > 
> > > > For your convenience I can elaborate. pcim_iomap_table() calls _first_
> > > > devres_find() which _will_ succeed if the pcim_iomap_regions() previously
> > > > succeeded. Does it help to understand how it designed?
> > > 
> > > I assume you're saying that after pcim_iomap_regions() succeeded it's
> > > already known that pcim_iomap_table() succeeds (because the former
> > > already called the latter).
> > > 
> > > I'm still concerned here. I agree that error checking might be skipped
> > > if it's clear that no error can happen (the device cannot disappear
> > > between these two calls, can it?), 
> > 
> > It depends. If you call it in some asynchronous callbacks which may be run
> > after PCI device disappears, then indeed, it's problematic. But you probably
> > will have much bigger issue at that point already.
> > 
> > In ->probe() it's guaranteed to work as I suggested (assuming properly working
> > hardware).
> 
> Assuming properly working hardware allows to drop many error checks :-)

Yes, and we have some checks are being not implemented ("dropped"), but here is
the thing: this is a PCI device and surprise removal (while it's not possible
for the on-die devices) should be handled differently, not related to this code
anyway. Malicious hardware is out of scope either.

> > > but for me as an uninitiated pci code
> > > reader, I wonder about
> > > 
> > > 	dwc->base = pcim_iomap_table(pci)[0];
> > > 
> > > without error checking. (OTOH, if pcim_iomap_table() returned NULL, the
> > > "[0]" part is already problematic.)
> > 
> > Seems it's your problem, many drivers use the way I suggested.
> > 
> > > I'd like to have a code comment here saying that pcim_iomap_table()
> > > won't return NULL.
> > 
> > Why? It's redundant. If you use it, you should know this API.
> > So, the bottom line, does this API needs better documentation?
> 
> If a driver author knows it while writing the code, it's obvious. But if
> the driver author looks again in 2 years or someone else (e.g. me with
> the PWM maintainer hat on and with little pci experience) that knowledge
> might be faded.

This is widely used pattern. Anybody who works with Git should know how
to use `git grep` tool. If in doubts, always can ask in the mailing lists.
I still consider it redundant.

P.S. That's what you call "bikeshedding" (done by yourself here)?



-- 
With Best Regards,
Andy Shevchenko