Re: [PATCH 2/2] ACPI, APEI, PCIE AER, use general HEST table parsingin AER firmware_first setup

[Hidetoshi Seto]

(2010/03/03 10:43), Huang Ying wrote:
>> For example, assume that there are 2 endpoints under a same
>> root port.  One is (likely on-board) "firmware first" endpoint,
>> with driver which does not call pci_enable_pcie_error_reporting()
>> (because of no interest in AER, or just not implemented yet,
>> anyway).  The other is (likely card seated on a slot) not
>> firmware first, with better driver which can handle it's AER.
>> If my understanding is correct and if everything goes well,
>> errors on one should be reported via APEI while the other should
>> be reported via AER driver.
> 
> Yes. I think this should be supported. How about something as follow?
> 
> struct pci_dev {
> 	...
> 	unsigned int __firmware_first:2;
> 	...
> };
> 
> int pcie_aer_get_firmware_first(struct pci_dev *dev)
> {
> 	if (!dev->__firmware_first)
> 		aer_set_firmware_first(dev);
> 	return dev->__firmware_first & 0x1;
> }
> 
> Then we use pcie_aer_get_firmware_first() instead of dev->firmware_first
> directly.

Looks reasonable.  I think the following is more straightforward:

struct pci_dev {
	...
	unsigned int __firmware_first_valid:1;
	unsigned int __firmware_first:1;
	...
};

int pcie_aer_get_firmware_first(struct pci_dev *dev)
{
	if (!dev->__firmware_first_valid)
		aer_set_firmware_first(dev);
	return dev->__firmware_first;
}


Thanks,
H.Seto

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/