pci_size() error condition

pci_size() error condition

[John Rose]

Can anyone lend an explanation of the following?

	/* base == maxbase can be valid only if the BAR has
	   already been programmed with all 1s.  */
	if (base == maxbase && ((base | size) & mask) != mask) {
		printk("%s: 2 returning 0\n", __FUNCTION__);
		return 0;
	}

Before a recent change, mask was a 64-bit number.  The second part of
the if statement would always resolve to true, since the 32-bit bitop
would never equal the 64-bit mask.  So the second part of the if
statement was ineffectual up until very recently.

After the recent change, this is no longer the case.  Nonzero PCI sizes
are generating bogus resource records for some PPC64 devices.  So for
cases of base == maxbase, why would we ever want to return a nonzero
value?  What is the intended purpose of the second part of that
conditional?

Thanks-
John

Re: pci_size() error condition

[Ivan Kokshaysky]

On Wed, Jul 13, 2005 at 05:53:13PM -0500, John Rose wrote:
> Before a recent change, mask was a 64-bit number.  The second part of
> the if statement would always resolve to true, since the 32-bit bitop
> would never equal the 64-bit mask.  So the second part of the if
> statement was ineffectual up until very recently.

It was always effectual for IO where the mask is 0xffff.

Ivan.

Re: pci_size() error condition

[John Rose]

> It was always effectual for IO where the mask is 0xffff.

Okay, point taken :)  So for cases of base == maxbase, why would we ever
want to return a nonzero value?  What is the intended purpose of the
second part of that conditional?

Re: pci_size() error condition

[Ivan Kokshaysky]

On Thu, Jul 14, 2005 at 11:04:00AM -0500, John Rose wrote:
> Okay, point taken :)  So for cases of base == maxbase, why would we ever
> want to return a nonzero value?  What is the intended purpose of the
> second part of that conditional?

Well, just two examples (both for PCI IO limited to 16 bits for simplicity,
but still from real life):
1. Consider some BAR that defines 16 bytes of IO space. It's
   perfectly valid for the PCI firmware to program this BAR to
   its max value, so after writing all 1s during the probe and proper
   masking we have base == maxbase == 0xfff0. But, since all high
   order bits are all 1s, (((base | size) & mask) != mask) is false,
   and we return correct value of 16.
2. Another BAR of some broken PCI device (typically, IDE controller)
   has *read-only* value of 0x1f0, for instance. After writing 0xffff
   we still read back the same 0x1f0, so base == maxbase == 0x1f0.
   But the second part of that "if" clause is now true, so we return 0,
   which means that the BAR is invalid and must be ignored.

Ivan.