On Wed, 20 Aug 2025 09:43:38 +0300 "Lifshits, Vitaly" <[email protected]> wrote:
> On 8/19/2025 8:10 PM, Timo Teras wrote: > > On Tue, 19 Aug 2025 15:43:26 +0300 > > Vitaly Lifshits <[email protected]> wrote: > > > >> The K1 state reduces power consumption on ICH family network > >> controllers during idle periods, similarly to L1 state on PCI > >> Express NICs. Therefore, it is recommended and enabled by default. > >> However, on some systems it has been observed to have adverse side > >> effects, such as packet loss. It has been established through debug > >> that the problem may be due to firmware misconfiguration of > >> specific systems, interoperability with certain link partners, or > >> marginal electrical conditions of specific units. > >> > >> These problems typically cannot be fixed in the field, and generic > >> workarounds to resolve the side effects on all systems, while > >> keeping K1 enabled, were found infeasible. > >> Therefore, add the option for users to globally disable K1 idle > >> state on the adapter. > > > > Thanks for adding this! > > > > However, as a user, I find it inconvenient if the default setting > > results in a subtly broken system on a device I just from a store. > > > > Since this affects devices from multiple large vendors, would it be > > possible to add some kind of quirk mechanism to automatically enable > > this on known "bad" systems. Perhaps something based on the DMI or > > other system specific information. Could something like this be > > implemented? > > > > At least in my use case I have multiple e1000e using laptops on the > > same link partner working, and only one broken device for which I > > reported this issue. So at least on my experience the issue relates > > to specific system primarily (perhaps also requiring a specific link > > partner for the issue to show up). > > Unfortunately, there is no visible configuration that allows the > driver to reliably identify problematic systems. > If in the future we find such data, then we can improve the > workaround and make it automatic. > > At present, the user-controlled interface is the best we have. Could you look at: - drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c - drivers/soundwire/dmi-quirks.c These use dmi_first_match() to match the DMI information of the system and then apply quirks based on the matching per-system data. Having similar mechanism in e1000e should be possible, right? I am happy to provide the needed DMI information from my system if this works out. Timo
