Thread (10 messages) 10 messages, 5 authors, 2020-08-03

Re: [RFC PATCH 00/17] Drop uses of pci_read_config_*() return value

From: Tom Rix <trix@redhat.com>
Date: 2020-08-02 14:53:58
Also in: dmaengine, dri-devel, intel-gfx, linux-crypto, linux-edac, linux-fpga, linux-gpio, linux-hwmon, linux-i2c, linux-ide, linux-iommu, linux-kernel-mentees, linux-pci, linux-rdma, lkml, netdev

On 8/1/20 5:56 AM, Borislav Petkov wrote:
On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
quoted
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
So why isn't the *value check done in the pci_read_config_* functions
instead of touching gazillion callers?

For example, pci_conf{1,2}_read() could check whether the u32 *value it
just read depending on the access method, whether that value is ~0 and
return proper PCIBIOS_ error in that case.

The check you're replicating

	if (val32 == (u32)~0)

everywhere, instead, is just ugly and tests a naked value ~0 which
doesn't mean anything...
I agree, if there is a change, it should be in the pci_read_* functions.

Anything returning void should not fail and likely future users of the proposed change will not do the extra checks.

Tom
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help