Akihiko Odaki e414270000 e1000e: Add ICR clearing by corresponding IMS bit
The datasheet does not say what happens when interrupt was asserted
(ICR.INT_ASSERT=1) and auto mask is *not* active.
However, section of 13.3.27 the PCIe* GbE Controllers Open Source
Software Developer’s Manual, which were written for older devices,
namely 631xESB/632xESB, 82563EB/82564EB, 82571EB/82572EI &
82573E/82573V/82573L, does say:
> If IMS = 0b, then the ICR register is always clear-on-read. If IMS is
> not 0b, but some ICR bit is set where the corresponding IMS bit is not
> set, then a read does not clear the ICR register. For example, if
> IMS = 10101010b and ICR = 01010101b, then a read to the ICR register
> does not clear it. If IMS = 10101010b and ICR = 0101011b, then a read
> to the ICR register clears it entirely (ICR.INT_ASSERTED = 1b).

Linux does no longer activate auto mask since commit
0a8047ac68e50e4ccbadcfc6b6b070805b976885 and the real hardware clears
ICR even in such a case so we also should do so.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2023-07-07 16:35:12 +08:00
..
2023-03-10 15:35:38 +08:00
2023-03-10 15:35:38 +08:00
2023-03-10 15:35:38 +08:00
2023-03-10 15:35:38 +08:00
2023-05-23 15:20:15 +08:00
2023-05-23 15:20:15 +08:00
2023-05-23 15:20:15 +08:00
2023-05-23 15:20:15 +08:00
2023-05-23 15:20:15 +08:00
2019-08-16 13:31:52 +02:00
2023-05-23 15:20:15 +08:00
2023-05-23 15:20:15 +08:00
2023-02-08 07:28:05 +01:00