Summary: | [CI][BAT] all suspend tests - dmesg-warn - called from state HALTED | ||
---|---|---|---|
Product: | DRI | Reporter: | Martin Peres <martin.peres> |
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | highest | CC: | intel-gfx-bugs |
Version: | DRI git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | ReadyForDev | ||
i915 platform: | ALL | i915 features: |
Description
Martin Peres
2019-01-07 15:39:31 UTC
The CI Bug Log issue associated to this bug has been updated. ### New filters associated * SNB: all suspend tests - dmesg-warn - called from state HALTED - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5366/shard-snb2/igt@i915_suspend@shrink.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5367/shard-snb7/igt@i915_suspend@shrink.html A netdev bug that isn't e1000e! Fwiw, commit 2b3e88ea65287ba738a798622405b15344871085 Author: Heiner Kallweit <hkallweit1@gmail.com> Date: Sun Dec 16 18:30:14 2018 +0100 net: phy: improve phy state checking Add helpers phy_is_started() and __phy_is_started() to avoid open-coded checks whether PHY has been started. To make the check easier move PHY_HALTED before PHY_UP in enum phy_state. Further improvements: phy_start_aneg(): Return -EBUSY and print warning if function is called from a non-started state (DOWN, READY, HALTED). Better check because function is exported and drivers may use it incorrectly. phy_interrupt(): Return IRQ_NONE also if state is DOWN or READY. We should never receive an interrupt in one of these states, but better play safe. phy_stop(): Just return and print a warning if PHY is in a non-started state. This warning should help to identify drivers with unbalanced calls to phy_start() / phy_stop(). phy_state_machine(): Schedule state machine run only if PHY is in a started state. E.g. if state is READY we don't need the state machine, it will be started by phy_start(). v2: - don't use __func__ within phy_warn_state v3: - use WARN() instead of printing error message to facilitate debugging Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> deemed to turn phy_start_aneg() while HALTED into an error (previously it still did the phy_config_aneg()). Local (topic/core-for-CI) revert for snb coverage: commit 9d7c979969612aa4b57003ac853cfafcff01ccd5 (drm-intel/topic/core-for-CI, topic/core-for-CI) Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 9 10:47:30 2019 +0000 Revert "net: phy: improve phy state checking" This reverts commit 2b3e88ea65287ba738a798622405b15344871085. commit 3a73af8b1a2c76803911ea12970cd734b7f481ec (drm-intel/topic/core-for-CI, topic/core-for-CI) Author: Heiner Kallweit <hkallweit1@gmail.com> Date: Wed Jan 9 20:34:56 2019 +0100 net: phy: fix too strict check in phy_start_aneg When adding checks to detect wrong usage of the phylib API we added a check to phy_start_aneg() which is too strict. If the phylib state machine is in state PHY_HALTED we should allow reconfiguring and restarting aneg, and just don't touch the state. Fixes: 2b3e88ea6528 ("net: phy: improve phy state checking") Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> (In reply to Chris Wilson from comment #5) > commit 3a73af8b1a2c76803911ea12970cd734b7f481ec > (drm-intel/topic/core-for-CI, topic/core-for-CI) > Author: Heiner Kallweit <hkallweit1@gmail.com> > Date: Wed Jan 9 20:34:56 2019 +0100 > > net: phy: fix too strict check in phy_start_aneg > > When adding checks to detect wrong usage of the phylib API we added > a check to phy_start_aneg() which is too strict. If the phylib > state machine is in state PHY_HALTED we should allow reconfiguring > and restarting aneg, and just don't touch the state. > > Fixes: 2b3e88ea6528 ("net: phy: improve phy state checking") > Reported-by: Chris Wilson <chris@chris-wilson.co.uk> > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Thanks! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.