RE: [PATCH 2/2] benet: Wait I/O while resuming device

-----Original Message-----
From: Gavin Shan [mailto:shangw@linux.vnet.ibm.com]

On Mon, Mar 04, 2013 at 09:17:22AM +0000, Perla, Sathya wrote:

quoted

quoted

-----Original Message-----
From: Gavin Shan [mailto:shangw@linux.vnet.ibm.com]

After resetting the adapter, the config space register (0x7c) might
give fake information to indicate the f/w is ready. In turn, 0xFF's
is always returned while accessing on I/O space registers. The patch
adds more check to make sure the I/O space is ready for access before

accessing that region.

quoted

quoted

...

quoted

+int be_cmd_fw_wait_io(struct be_adapter *adapter) {
+	void __iomem *db = adapter->db + MPU_MAILBOX_DB_OFFSET;
+	int timeout = 0;
+	u32 val;
+
+	if (lancer_chip(adapter))
+		return 0;
+
+	do {
+		val = ioread32(db);
+		if (val != 0xffffffff)
+			return 0;

Wouldn't reading 0xffffffff from a register cause a new EEH flow to be

triggered?

quoted

I don't think 0xffffffff here indicates a new EEH error and the adapter was
recovering from EEH error, which already happened before.

Actually, I'm developing new feature to support EEH for PowerNV (PPC)
platform. While the benet adapter detected EEH error and tried to resume, the
I/O access always returned 0xffffffff even through I could get correct values
from the config space. Since I don't have the specification, I would guess the
config space becomes ready prior to I/O space after resetting the adapter and
its firmware.

The root-cause here is that the config-space/0x7c register is incorrectly
reflecting the POST state to be FW_READY. This causes the driver to go ahead
and read I/O space "prematurely" causing a 0xffffffff read. 
The config-space/0x7c register reflects the correct
value a little later. This happens only for BE2/3 chips.

I propose to fix this by polling instead on CSR-BAR/0xac register for POST status
for BE2/3 chips.

thanks,
-Sathya