This series brings e1000e's PHY power-management handling (BMCR.PDOWN,
CTRL.RST vs CTRL.PHY_RST, and the PCI D3hot -> D0 transition) in line
with the 82574 datasheet (Order 317694-016, Rev 2.5) and with what I
measured on a real 82574L NIC (8086:10d3, via direct MDIC register
access, bypassing the guest driver so the link-down and power-down
states could actually be observed).

Currently the model:
- ignores BMCR.PDOWN entirely for the link (patch 1);
- resets the PHY on every CTRL.RST (a software/MAC reset) but not on
  CTRL.PHY_RST (backwards from the datasheet and from what I measured
  on real hardware) (patch 2);
- does nothing on a D3hot -> D0 PCI power-state transition, although
  the datasheet says the device performs an internal reset that
  includes the PHY (patch 3).

Patch 2 depends on patch 1 (e1000e_phy_powered_down()), and patch 3
depends on patch 2 (e1000e_phy_reset()). Each patch adds its own qtest
(phy_power_down, phy_reset_semantics, phy_d3hot_reset); I verified each
new test fails without its patch and passes with it, and that the
existing e1000e qtests (init, tx, rx, multiple_transfers, hotplug)
still pass throughout. The series applies to and builds cleanly against
current master.

I found this while implementing a fault-injection test harness for the
e1000e driver (suspend/resume and RX-buffer fault scenarios) - the
model's link/PHY state didn't behave like the real 82574L it emulates,
which made some of those scenarios impossible to exercise faithfully.

oyasan2-ba2 (1):
  hw/net/e1000e: reset the PHY on a D3hot to D0 transition

 hw/net/e1000e.c           | 14 ++++++++++++++
 hw/net/e1000e_core.c      | 15 +++++++++++++++
 hw/net/e1000e_core.h      |  3 +++
 tests/qtest/e1000e-test.c | 40 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 72 insertions(+)

-- 
2.49.1

On 2026/09/23 16:54, ~oyasan2-ba2 wrote:
> This series brings e1000e's PHY power-management handling (BMCR.PDOWN,
> CTRL.RST vs CTRL.PHY_RST, and the PCI D3hot -> D0 transition) in line
> with the 82574 datasheet (Order 317694-016, Rev 2.5) and with what I
> measured on a real 82574L NIC (8086:10d3, via direct MDIC register
> access, bypassing the guest driver so the link-down and power-down
> states could actually be observed).
> 
> Currently the model:
> - ignores BMCR.PDOWN entirely for the link (patch 1);
> - resets the PHY on every CTRL.RST (a software/MAC reset) but not on
>    CTRL.PHY_RST (backwards from the datasheet and from what I measured
>    on real hardware) (patch 2);
> - does nothing on a D3hot -> D0 PCI power-state transition, although
>    the datasheet says the device performs an internal reset that
>    includes the PHY (patch 3).
> 
> Patch 2 depends on patch 1 (e1000e_phy_powered_down()), and patch 3
> depends on patch 2 (e1000e_phy_reset()). Each patch adds its own qtest
> (phy_power_down, phy_reset_semantics, phy_d3hot_reset); I verified each
> new test fails without its patch and passes with it, and that the
> existing e1000e qtests (init, tx, rx, multiple_transfers, hotplug)
> still pass throughout. The series applies to and builds cleanly against
> current master.

This series only contains one patch and cannot be applied.

Regards,
Akihiko Odaki

> 
> I found this while implementing a fault-injection test harness for the
> e1000e driver (suspend/resume and RX-buffer fault scenarios) - the
> model's link/PHY state didn't behave like the real 82574L it emulates,
> which made some of those scenarios impossible to exercise faithfully.
> 
> oyasan2-ba2 (1):
>    hw/net/e1000e: reset the PHY on a D3hot to D0 transition
> 
>   hw/net/e1000e.c           | 14 ++++++++++++++
>   hw/net/e1000e_core.c      | 15 +++++++++++++++
>   hw/net/e1000e_core.h      |  3 +++
>   tests/qtest/e1000e-test.c | 40 +++++++++++++++++++++++++++++++++++++++
>   4 files changed, 72 insertions(+)
>