From: Jisheng Zhang <jszhang@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>,
HeinerKallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S.Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Conor Dooley <conor.dooley@microchip.com>
Cc: netdev@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: [RFC] support built-in ethernet phy which needs some mmio accesses
Date: Sun, 19 Nov 2023 21:57:17 +0800 [thread overview]
Message-ID: <ZVoUPW8pJmv5AT10@xhacker> (raw)
Hi,
I want to upstream milkv duo (powered by cv1800b) ethernet support. The SoC
contains a built-in eth phy which also needs some initialization via.
mmio access during init. So, I need to do something like this(sol A):
in dtsi:
ephy@abcd {
compatbile = "sophgo,cv1800b-ephy";
...
};
in ephy driver:
static struct phy_driver ephy_driver {
various implementaion via standard phy_read/phy_write;
};
int ephy_probe(platform_device *pdev)
{
init via. readl() and writel();
phy_drivers_register(&ephy_driver);
}
int ephy_remove()
{
phy_drivers_unregister();
}
I'm not sure whether this kind of driver modeling can be accepted or
not. The advantage of this solution is there's no hardcoding at all, the
big problem is the ephy is initialized during probe() rather than
config_init().
The vendor kernel src supports the ephy in the following way(will be
called as sol B):
in phy driver's .config_init() maps the ephy reg via. ioremap()
then init via. readl/writel on the mapped space. Obviously, this
isn't acceptable due to the hardcoding of ephy reg base and size.
But the advantage is it delay the ephy init until config_init() is
called.
could you please give some advice?
Thanks in advance
next reply other threads:[~2023-11-19 14:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-19 13:57 Jisheng Zhang [this message]
2023-11-19 14:13 ` [RFC] support built-in ethernet phy which needs some mmio accesses Heiner Kallweit
2023-11-19 16:18 ` Andrew Lunn
2023-11-20 14:03 ` Jisheng Zhang
2023-11-20 15:54 ` Andrew Lunn
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=ZVoUPW8pJmv5AT10@xhacker \
--to=jszhang@kernel.org \
--cc=andrew@lunn.ch \
--cc=conor.dooley@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).