From: Andrew Lunn <andrew@lunn.ch>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>,
linux@armlinux.org.uk, "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] net: phy: marvell: Honor phy LED set by system firmware on a Dell hardware
Date: Sat, 22 Jan 2022 22:18:37 +0100 [thread overview]
Message-ID: <Yex0rZ0wRWQH/L4n@lunn.ch> (raw)
In-Reply-To: <3d7b1ff0-6776-6480-ed20-c9ad61b400f7@gmail.com>
> One more idea:
> The hw reset default for register 16 is 0x101e. If the current value
> is different when entering config_init then we could preserve it
> because intentionally a specific value has been set.
> Only if we find the hw reset default we'd set the values according
> to the current code.
We can split the problem into two.
1) I think saving LED configuration over suspend/resume is not an
issue. It is probably something we will be needed if we ever get PHY
LED configuration via sys/class/leds.
2) Knowing something else has configured the LEDs and the Linux driver
should not touch it. In general, Linux tries not to trust the
bootloader, because experience has shown bad things can happen when
you do. We cannot tell if the LED configuration is different to
defaults because something has deliberately set it, or it is just
messed up, maybe from the previous boot/kexec, maybe by the
bootloader. Even this Dell system BIOS gets it wrong, it configures
the LED on power on, but not resume !?!?!. And what about reboot?
So i really would like the bootloader to explicitly say it has
configured the LEDs and it takes full responsibility for any and all
bad behaviour as a result.
Andrew
next prev parent reply other threads:[~2022-01-22 21:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 5:19 Kai-Heng Feng
2022-01-20 7:58 ` Heiner Kallweit
2022-01-20 11:40 ` Kai-Heng Feng
2022-01-20 13:46 ` Andrew Lunn
2022-01-21 3:54 ` Kai-Heng Feng
2022-01-21 13:04 ` Andrew Lunn
2022-01-21 14:04 ` Kai-Heng Feng
2022-01-21 15:05 ` Andrew Lunn
2022-01-21 13:10 ` Andrew Lunn
2022-01-21 14:06 ` Kai-Heng Feng
2022-01-21 15:08 ` Andrew Lunn
2022-01-21 7:49 ` Heiner Kallweit
2022-01-20 14:26 ` Andrew Lunn
2022-01-21 4:01 ` Kai-Heng Feng
2022-01-21 13:22 ` Andrew Lunn
2022-01-21 14:17 ` Kai-Heng Feng
2022-01-21 15:15 ` Andrew Lunn
2022-01-22 19:13 ` Heiner Kallweit
2022-01-22 21:18 ` Andrew Lunn [this message]
2022-02-14 5:40 ` Kai-Heng Feng
2022-02-15 20:27 ` Andrew Lunn
2022-02-16 2:30 ` Kai-Heng Feng
2022-02-16 7:39 ` Andrew Lunn
2022-01-20 15:33 ` kernel test robot
2022-01-21 6:47 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yex0rZ0wRWQH/L4n@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=kai.heng.feng@canonical.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome