From: Jeremy Linton <jeremy.linton@arm.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, opendmb@gmail.com, f.fainelli@gmail.com,
davem@davemloft.net, bcm-kernel-feedback-list@broadcom.com,
linux-kernel@vger.kernel.org, wahrenst@gmx.net,
hkallweit1@gmail.com
Subject: Re: [PATCH 3/6] net: bcmgenet: enable automatic phy discovery
Date: Sat, 1 Feb 2020 14:02:01 -0600 [thread overview]
Message-ID: <ad9bc142-c0a8-74af-09c6-7150ff4b854a@arm.com> (raw)
In-Reply-To: <20200201152518.GI9639@lunn.ch>
Hi,
On 2/1/20 9:25 AM, Andrew Lunn wrote:
> On Sat, Feb 01, 2020 at 01:46:22AM -0600, Jeremy Linton wrote:
>> The unimac mdio driver falls back to scanning the
>> entire bus if its given an appropriate mask. In ACPI
>> mode we expect that the system is well behaved and
>> conforms to recent versions of the specification.
>>
>> We then utilize phy_find_first(), and
>> phy_connect_direct() to find and attach to the
>> discovered phy during net_device open.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmmii.c | 40 +++++++++++++++++---
>> 1 file changed, 34 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
>> index 2049f8218589..f3271975b375 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
>> @@ -5,7 +5,7 @@
>> * Copyright (c) 2014-2017 Broadcom
>> */
>>
>> -
>> +#include <linux/acpi.h>
>> #include <linux/types.h>
>> #include <linux/delay.h>
>> #include <linux/wait.h>
>> @@ -311,7 +311,9 @@ int bcmgenet_mii_config(struct net_device *dev, bool init)
>> int bcmgenet_mii_probe(struct net_device *dev)
>> {
>> struct bcmgenet_priv *priv = netdev_priv(dev);
>> - struct device_node *dn = priv->pdev->dev.of_node;
>> + struct device *kdev = &priv->pdev->dev;
>> + struct device_node *dn = kdev->of_node;
>> +
>> struct phy_device *phydev;
>> u32 phy_flags = 0;
>> int ret;
>> @@ -334,7 +336,27 @@ int bcmgenet_mii_probe(struct net_device *dev)
>> return -ENODEV;
>> }
>> } else {
>> - phydev = dev->phydev;
>> + if (has_acpi_companion(kdev)) {
>> + char mdio_bus_id[MII_BUS_ID_SIZE];
>> + struct mii_bus *unimacbus;
>> +
>> + snprintf(mdio_bus_id, MII_BUS_ID_SIZE, "%s-%d",
>> + UNIMAC_MDIO_DRV_NAME, priv->pdev->id);
>> +
>> + unimacbus = mdio_find_bus(mdio_bus_id);
>> + if (!unimacbus) {
>> + pr_err("Unable to find mii\n");
>> + return -ENODEV;
>> + }
>> + phydev = phy_find_first(unimacbus);
>> + put_device(&unimacbus->dev);
>> + if (!phydev) {
>> + pr_err("Unable to find PHY\n");
>> + return -ENODEV;
>
> Hi Jeremy
>
> phy_find_first() is not recommended. Only use it if you have no other
> option. If the hardware is more complex, two PHYs on one bus, you are
> going to have a problem. So i suggest this is used only for PCI cards
> where the hardware is very fixed, and there is only ever one MAC and
> PHY on the PCI card. When you do have this split between MAC and MDIO
> bus, each being independent devices, it is more likely that you do
> have multiple PHYs on one shared MDIO bus.
>
> In the DT world, you use a phy-handle to point to the PHY node in the
> device tree. Does ACPI have the same concept, a pointer to some other
> device in ACPI?
I though I should clarify the direct question here about ACPI. ACPI does
have the ability to do what you describe, but it a more rigorous way. If
you look at the ACPI GenericSerialBus abstraction you will see how ACPI
would likely handle this situation. I've been considering making a
similar comment in that large fwnode patch set posted the other day.
next prev parent reply other threads:[~2020-02-01 20:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-01 7:46 [PATCH 0/6] Add ACPI bindings to the genet Jeremy Linton
2020-02-01 7:46 ` [PATCH 1/6] mdio_bus: Add generic mdio_find_bus() Jeremy Linton
2020-02-01 7:46 ` [PATCH 2/6] net: bcmgenet: refactor phy mode configuration Jeremy Linton
2020-02-01 16:24 ` Florian Fainelli
2020-02-01 19:10 ` Jeremy Linton
2020-02-03 1:17 ` Andrew Lunn
2020-02-03 3:24 ` Florian Fainelli
2020-02-03 18:46 ` Jeremy Linton
2020-02-03 18:55 ` Florian Fainelli
2020-02-05 21:05 ` kbuild test robot
2020-02-01 7:46 ` [PATCH 3/6] net: bcmgenet: enable automatic phy discovery Jeremy Linton
2020-02-01 15:25 ` Andrew Lunn
2020-02-01 19:07 ` Jeremy Linton
2020-02-03 20:55 ` Florian Fainelli
2020-02-03 21:21 ` Andrew Lunn
2020-02-01 20:02 ` Jeremy Linton [this message]
2020-02-03 1:15 ` Andrew Lunn
2020-02-03 21:10 ` Jeremy Linton
2020-02-01 7:46 ` [PATCH 4/6] net: bcmgenet: Initial bcmgenet ACPI support Jeremy Linton
2020-02-01 15:33 ` Andrew Lunn
2020-02-01 19:09 ` Jeremy Linton
2020-02-01 7:46 ` [PATCH 5/6] net: bcmgenet: Fetch MAC address from the adapter Jeremy Linton
2020-02-01 15:37 ` Andrew Lunn
2020-02-01 19:20 ` Jeremy Linton
2020-02-01 7:46 ` [PATCH 6/6] net: bcmgenet: reduce severity of missing clock warnings Jeremy Linton
2020-02-01 16:18 ` Florian Fainelli
2020-02-01 16:44 ` Stefan Wahren
2020-02-01 19:27 ` Jeremy Linton
2020-02-03 18:36 ` Nicolas Saenz Julienne
2020-02-03 19:08 ` Stefan Wahren
2020-02-03 21:21 ` Florian Fainelli
2020-02-05 18:42 ` Stefan Wahren
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=ad9bc142-c0a8-74af-09c6-7150ff4b854a@arm.com \
--to=jeremy.linton@arm.com \
--cc=andrew@lunn.ch \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=opendmb@gmail.com \
--cc=wahrenst@gmx.net \
/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
all inboxes | Powered by JetHome®