Received-SPF: pass (google.com: domain of linux-kernel+bounces-66993-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 15 Feb 2024 15:36:12 +0200
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= <u.kleine-koenig@pengutronix.de>
Cc: Raag Jadav <raag.jadav@intel.com>, jarkko.nikula@linux.intel.com,
	mika.westerberg@linux.intel.com, lakshmi.sowjanya.d@intel.com,
	linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] pwm: dwc: drop redundant error check
Message-ID: <Zc4TTLetiGhJlx8d@smile.fi.intel.com>
References: <20240208070529.28562-1-raag.jadav@intel.com>
 <20240208070529.28562-2-raag.jadav@intel.com>
 <qrwcje4t2pbbxilnlfz2q7njodcp6vl54uaypdbvjgvwhgvc5g@4eq5wvumpjjx>
 <ZcUJoSMhgC7lhY-H@smile.fi.intel.com>
 <cv6w4n2ptcdehn5n3mipuyfrtemm4rldhiyppazk4uqdn2xx7e@hxg4kldaacxk>
 <Zcz-csPY5x29DP7v@smile.fi.intel.com>
 <sd2ugzjrmrdvcyxotoyg53qp3i7ta4yko225ln3gk4fmik7iof@a7mab6o2kkvz>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <sd2ugzjrmrdvcyxotoyg53qp3i7ta4yko225ln3gk4fmik7iof@a7mab6o2kkvz>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

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