From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Chan Subject: Re: sblk->status_tag on drivers/net/ethernet/broadcom/tg3.c Date: Tue, 4 Mar 2014 15:22:23 -0800 Message-ID: <1393975344.4632.10.camel@LTIRV-MCHAN1.corp.ad.broadcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="cp1252" Content-Transfer-Encoding: 7bit Cc: , "linux-pci@vger.kernel.org" , Nithin Nayak Sujir , Grant Likely , Rob Herring , Bjorn Helgaas To: Jagan Teki Return-path: In-Reply-To: Sender: linux-pci-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, 2014-03-04 at 23:25 +0530, Jagan Teki wrote: > From the comments in ISR any non-zero value to intr-mbox-0 clear > the interrupt ie write status as 1 so I assume interrupt is clear and then > in tg3_int_reenable is going to write 0x0 on to intr-mbox-0 > which again reenables the interrupt, was my guess is true? Yes, the (last_tag << 24) is also written to the intr-mbox-0 to acknowledge the status block. > And sblk->status_tag is always 0 in ISR and BH(poll) why is that so? > If it's is 1(unsigned non-zero) then possibly tg3_int_reenable will write > non-zero value on intr-mbox-0 which will clear the interrupt. You should print out the entire status block. It shouldn't be zero. The status tag should be incrementing for each interrupt. > > Request for any help who updates sblk->status_tag value and > how many time the ISR in PCIe RC and ISR in EP will call for link up? > > If you are expecting link up, the first 32-bit word of the status block should have bit 1 set (bit 0 should also be set). I think the driver is not seeing the status block correctly, so it is not acknowledging the link change interrupt and the status_tag.