On Tue, Mar 03, 2026 at 03:14:02PM +0000, Mark Brown wrote:

On Tue, Mar 03, 2026 at 03:12:14PM +0000, Russell King (Oracle) wrote:

quoted

On Tue, Mar 03, 2026 at 02:22:40PM +0000, Mark Brown wrote:

quoted

On Tue, Mar 03, 2026 at 02:54:27PM +0100, Romain Gantois wrote:

quoted

quoted

quoted

If phandles to receiver and/or transmitter regulators for an SFP device are
found, enable them at probe time.

quoted

quoted

The driver should unconditionally request whatever power the device
needs.

quoted

... and then we break everyone, just like you broke SATA, and I've
never forgiven you for taking a principled line on this rather than a
pragmatic approach. You're making the same mistake here.

Sorry, what's the breakage here?  The log messages, or something else?

... which then caused someone to "fix" DT by disabling devices to shut
up those log messages, including for platforms where those devices were
being used, which ultimately caused a boot failure.

... and your argument that SATA PHYs need these supplies, which is false
when the SATA PHY is integrated into the SoC and there's no details on
what those supplies are or where they come from, or even if they are
controllable.

Yet you demand that a SATA PHY supply must be provided, and so we're
stuck with:

[    1.207484] ahci f2540000.sata: supply ahci not found, using dummy regulator
[    1.213524] ahci f2540000.sata: supply phy not found, using dummy regulator
[    1.219630] platform f2540000.sata:sata-port@1: supply target not found, using dummy regulator
[    1.227800] ahci f4540000.sata: supply ahci not found, using dummy regulator
[    1.233757] ahci f4540000.sata: supply phy not found, using dummy regulator
[    1.239805] platform f4540000.sata:sata-port@0: supply target not found, using dummy regulator

on every boot with no way to shut them up. These supplies *ARE*
optional in terms of whether they can be described in DT.

As I've told you before, we have no information by which to describe
these supplies in DT on these platforms (not even with the data for
the chip) so you are effectively forcing people to "make stuff up" in
DT to shut up your warnings - blowing the whole idea that DT should
describe the hardware out of the water. How can we describe this
hardware if we don't have the internal design details of the chip?

The only way is to make something up, and all because you've decided
SATA supplies are no longer optional.

As SFP cages have not had to describe these supplies, requiring them
*now* will cause *regressions* because no one is going to be specifying
them, which will lead to stuff breaking. Again.

So, for the good of users of my SFP code, I will refuse any
introduction of regulators into my code for as long as you're take
the principled stance that regulators shall not be optional, rather
than applying a sensible pragmatic approach. You give me no option
here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!