From: Andrew Lunn <andrew@lunn.ch>
To: "Andreas Böhler" <news@aboehler.at>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC] MDIO firmware upload for offloading CPU
Date: Sun, 22 Mar 2020 22:09:58 +0100 [thread overview]
Message-ID: <20200322210958.GF3819@lunn.ch> (raw)
In-Reply-To: <96bfdd47-80ce-b7fd-75f7-d2ad0705f8bb@aboehler.at>
> > Hi Andreas
> >
> > You say there is no PHY. So is the MDIO bus used for anything other
> > than firmware upload?
>
> Yes - there are four other PHYs on the bus, everything is attached to
> the Lantiq Gigabit switch. I wasn't clear enough in this regard.
O.K. That makes it more difficult. Does probing just these four PHYs
upset the firmware upload? You need to probe them in order to use
them.
> > This two stage firmware upload is messy. If it had been just MDIO i
> > would of said do it from the kernel, as part of the Atheros SoC WiFi
> > driver. MDIO is a nice simple interface. Sending Ethernet frames is a
> > bit harder. Still, if you can do it all in the wifi driver, i
> > would. You can use phandle's to get references to the MDIO bus and the
> > Ehernet interface. There are examples of this in net/dsa/dsa2.c.
>
> A bit more info on the two-stage firmware upload: The Atheros SoC is a
> complete AR9342 or QCA9558 SoC with 64MB or 128MB RAM. The stage 1
> firmware only initializes the Ethernet connection and waits for the
> stage 2 firmware. The latter consists in the vendor implementation of a
> Linux kernel and minimal user space, the wireless cards are then somehow
> "exported" over Ethernet to the Lantiq SoC. On the Lantiq, they look
> like local Atheros interfaces - it looks a lot like ath9k-htc with a
> different transport
So the traditional model would be, the driver on the Lantiq for the
interfaces would be responsible for downloading the firmware to the
Atheros. Is there a driver for the ath9k-htc transport? That transport
is probably specific to the Atheros chip. So you can do the firmware
download from there.
Do you only use one address on the MDIO bus for firmware download?
Another option would be to have an mdio 'device' with a driver. When
the MDIO bus is enumerated by of_mdiobus_register(), it would find
this 'device' in DT, and load the driver for it. That driver could
then download the firmware over MDIO, and then later Ethernet. All the
infrastructure is in place for this. It is used by Ethernet switches
on MDIO busses.
Andrew
prev parent reply other threads:[~2020-03-22 21:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 13:56 [RFC] MDIO firmware upload for offloading CPU Andreas Böhler
2020-03-22 14:43 ` Andrew Lunn
2020-03-22 20:29 ` Andreas Böhler
2020-03-22 21:09 ` Andrew Lunn [this message]
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=20200322210958.GF3819@lunn.ch \
--to=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=news@aboehler.at \
/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).