[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EA929A9653AAE14F841771FB1DE5A1365F7A1DF466@rrsmsx501.amr.corp.intel.com>
Date: Wed, 13 May 2009 15:07:56 -0600
From: "Williams, Mitch A" <mitch.a.williams@...el.com>
To: Jesper Dangaard Brouer <hawk@...x.dk>
CC: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"David S. Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"e1000-devel@...ts.sourceforge.net"
<e1000-devel@...ts.sourceforge.net>,
"Ronciak, John" <john.ronciak@...el.com>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Subject: RE: [PATCH 1/2] igb: Implement reading of reg RQDPC (Receive Queue
Drop Packet Count)
>-----Original Message-----
>From: Jesper Dangaard Brouer [mailto:hawk@...x.dk]
>Sent: Monday, May 11, 2009 2:50 AM
>
>I have now tested it on a 82575 chip NIC. (I just got my 82575 NIC
>working again (This 12 port monster from Hotlava Systems, just needed
>more power on PCIe 100Watt)).
>
>I don't see the reason for doing special checks for the 82575. Reading
>the RQDPC registers on 82575 always returns 0. I don't see any harm in
>that!? (it also returns zero in overload situations)
>
>What do you want to redraw your NAK?
>
Jesper, I still stand by my NAK. It's never ever a good idea to read
non-existent hardware registers. You don't know what effect those
reads will have on the hardware. These addresses may be aliased to other
registers without being documented. Hardware designers do this all the
time to save a few gates in the address decode logic, and these aliases
may or may not be documented. If this is the case, reading these
registers will have unintended consequences. You might be clearing some
other statistic, or worse.
Since we just don't know, it's better to be safe than sorry. Wrap
those register reads so they only happen on 82576, and I'll happily
ack your patch.
-Mitch--
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
Powered by blists - more mailing lists