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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <67feeaf6-cd7c-4892-b76d-0344f9367ff4@CMEXHTCAS1.ad.emulex.com>
Date:	Mon, 4 Mar 2013 11:11:21 +0000
From:	"Perla, Sathya" <Sathya.Perla@...lex.Com>
To:	Gavin Shan <shangw@...ux.vnet.ibm.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Seetharaman, Subramanian" <subbu.seetharaman@...lex.com>,
	"Khaparde, Ajit" <Ajit.Khaparde@...lex.Com>
Subject: RE: [PATCH 2/2] benet: Wait I/O while resuming device

> -----Original Message-----
> From: Gavin Shan [mailto:shangw@...ux.vnet.ibm.com]
> 
> On Mon, Mar 04, 2013 at 09:17:22AM +0000, Perla, Sathya wrote:
> >> -----Original Message-----
> >> From: Gavin Shan [mailto:shangw@...ux.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.
> >>
> >...
> >>
> >> +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?
> >
> 
> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html