From: Anders Darander <anders.darander@datarespons.se>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: "David S. Miller" <davem@davemloft.net>,
Ralf Baechle <ralf@linux-mips.org>,
Maxime Bizon <mbizon@freebox.fr>,
David Daney <ddaney@caviumnetworks.com>,
Sekhar Nori <nsekhar@ti.com>,
Anton Vorontsov <avorontsov@ru.mvista.com>,
Andy Fleming <afleming@freescale.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Allow MACB to connect to a higher addresses PHY.
Date: Wed, 31 Mar 2010 07:53:06 +0200 [thread overview]
Message-ID: <20100331055306.GC4837@datarespons.se> (raw)
In-Reply-To: <fa686aa41003300741x5ef9bdbpf56133304fe4d6e6@mail.gmail.com>
Hi Grant,
Thanks for the feedback!
* Grant Likely <grant.likely@secretlab.ca> [100330 16:42]:
> On Tue, Mar 30, 2010 at 3:58 AM, Anders Darander
> <anders.darander@gmail.com> wrote:
> > Using the Atmel MACB together with an integrated switch, can make only port 1
> > work. This is caused by macb_mii_probe trying to attach the MAC to the first
> > PHY, which often is on one of the external ports.
> >
> > E.g. the Micrel KSZ8873 connects to the MAC on port 3, thus phy_addr should be
> > set to 3.
> I understand what you are trying to do, but this is the wrong way to
> go about it. Hard coding it into Kconfig breaks multiplatform
> kernels. Besides, systems may have more than one physical MDIO bus.
> This patch would make CONFIG_SWITCHING_PHY_ADDR the only address
> accessible on all MDIO busses.
True, it would at least make all addresses < CONFIG_SWITCHING_PHY_ADDR
non-accessible.
We developed the patch to solve this problem on a 2.6.29-kernel, in
which the loop in question is directly in the macb_mii_probe() in the
macb.c, thus, the original patch is at least a _little_ bit less ugly...
> Nak.
I fully agree on the nak; I completely forgot that the functions in
phy_devices should be used from more interfaces than only the macb.
> The right thing to do is to add a runtime configuration option (ie.
> kernel parameter or platform data) to the mac driver to specify
> exactly which PHY address it is supposed to use.
I'll see if I can get some time to do such a thing. Unfortunately, it'll
probably have to be dealt with on my sparetime (the customer is quite
unlikely to let me work on that).
One question, if I add such an kernel parameter, would it be OK to
implement something like this in the macb-driver:
if parameter == SOME_DEFAULT
phydev = phy_find_first(bp->mii_bus);
else
phydev = bp->mii_bus->phy_map[parameter];
I.e. if the parameter is set to some default value, the old behaviour is
retained, otherwise the specified parameter is used for the phy_addr?
I'd appreciate your input on such a design.
Best regards,
Anders Darander
next prev parent reply other threads:[~2010-03-31 6:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 9:58 [PATCH] Allow MACB to connect to a higher addresses PHY Anders Darander
2010-03-30 14:41 ` Grant Likely
2010-03-31 5:53 ` Anders Darander [this message]
2010-03-31 6:08 ` Grant Likely
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=20100331055306.GC4837@datarespons.se \
--to=anders.darander@datarespons.se \
--cc=afleming@freescale.com \
--cc=avorontsov@ru.mvista.com \
--cc=davem@davemloft.net \
--cc=ddaney@caviumnetworks.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mbizon@freebox.fr \
--cc=netdev@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=ralf@linux-mips.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;
as well as URLs for NNTP newsgroup(s).