LKML Archive on
help / color / mirror / Atom feed
From: "Russell King (Oracle)" <>
To: "Pali Rohár" <>
Cc: "Marek Behún" <>,
	"Miquel Raynal" <>,
	"Kishon Vijay Abraham I" <>,
	"Vinod Koul" <>, "Andrew Lunn" <>,
	"Rob Herring" <>,,,
Subject: Re: [PATCH 3/3] phy: marvell: phy-mvebu-a3700-comphy: Remove unsupported modes
Date: Fri, 27 Aug 2021 19:33:55 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210827182502.vdapjcqimq4ulkg2@pali>

On Fri, Aug 27, 2021 at 08:25:02PM +0200, Pali Rohár wrote:
> cp110-comphy and a3700-comphy are just RPC drivers which calls SMC and
> relay on firmware support which implements real work. And both uses same
> RPC / SMC API. So merging drivers into one is possible.
> But I do not think that it is a good idea that Linux kernel depends on
> some external firmware which implements RPC API for configuring HW.
> Rather kernel should implements its native drivers without dependency on
> external firmware.
> We know from history that kernel tried to avoid using x86 BIOS/firmware
> due to bugs and all functionality (re)-implemented itself without using
> firmware RPC functionality.

Not really an argument in this case. We're not talking about closed
source firmware.

> Kernel has already "hacks" in other drivers which are using these comphy
> drivers, just because older versions of firmware do not support all
> necessary functionality and upgrading this firmware is not easy step
> (and sometimes even not possible; e.g. when is cryptographically
> signed).

The kernel used to (and probably still does) contain code to configure
the comphys. Having worked on trying to get the 10G lanes stable on
Macchiatobin, I much prefer the existing solution where it's in the
ATF firmware. I've rebuilt the firmware several times during the course
of that.

The advantage is that fixing the setup of the COMPHY is done in one
place, and it fixes it not only for the kernel, but also for u-boot
and UEFI too. So rather than having to maintain three different
places for a particular board, we can maintain the parameters in one
place - in the ATF firmware.

The problem with the past has been that stuff gets accepted into the
kernel without the "full system" view and without regard for "should
this actually be done in the firmware". Then, when it's decided that
it really should be done in the firmware, we end up needing to keep
the old stuff in the kernel for compatibility with older firmware,
which incidentally may not be up to date.

If we were to drop the comphy setup from firmware, then we will need
a lot of additional properties in the kernel's DT and u-boot DT for
the comphy to configure it appropriately. And ACPI. I don't think
that scales very well, and is a recipe for things getting out of

RMK's Patch system:
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2021-08-27 18:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27  9:27 [PATCH 1/3] phy: marvell: phy-mvebu-cp110-comphy: Rename HS-SGMMI to 2500Base-X Pali Rohár
2021-08-27  9:27 ` [PATCH 2/3] phy: marvell: phy-mvebu-a3700-comphy: " Pali Rohár
2021-08-27  9:27 ` [PATCH 3/3] phy: marvell: phy-mvebu-a3700-comphy: Remove unsupported modes Pali Rohár
2021-08-27 11:27   ` Marek Behún
2021-08-27 18:25     ` Pali Rohár
2021-08-27 18:33       ` Russell King (Oracle) [this message]
2021-08-27 19:02         ` Pali Rohár
2021-08-27 21:10           ` Russell King (Oracle)
2021-08-27 11:30 ` [PATCH 1/3] phy: marvell: phy-mvebu-cp110-comphy: Rename HS-SGMMI to 2500Base-X patchwork-bot+netdevbpf

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 3/3] phy: marvell: phy-mvebu-a3700-comphy: Remove unsupported modes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).