From: Ray Jui <ray.jui@broadcom.com>
To: Jon Mason <jon.mason@broadcom.com>,
Florian Fainelli <f.fainelli@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
rafal@milecki.pl, bcm-kernel-feedback-list@broadcom.com,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] net: ethernet: bgmac: add NS2 support
Date: Thu, 27 Oct 2016 15:21:39 -0700 [thread overview]
Message-ID: <ccbaf726-b1fc-975a-215c-17e2870328a6@broadcom.com> (raw)
In-Reply-To: <20161027205117.GA24397@broadcom.com>
On 10/27/2016 1:51 PM, Jon Mason wrote:
> On Wed, Oct 26, 2016 at 02:50:39PM -0700, Florian Fainelli wrote:
>> On 10/26/2016 12:36 PM, Jon Mason wrote:
>>> Add support for the variant of amac hardware present in the Broadcom
>>> Northstar2 based SoCs. Northstar2 requires an additional register to be
>>> configured with the port speed/duplexity (NICPM). This can be added to
>>> the link callback to hide it from the instances that do not use this.
>>> Also, the bgmac_chip_reset() was intentionally removed to prevent the
>>> resetting of the chip to the default values on open. Finally, clearing
>>> of the pending interrupts on init is required due to observed issues on
>>> some platforms.
>>>
>>> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
>>> ---
>>
>>> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
>>> +{
>>> + struct bgmac *bgmac = netdev_priv(net_dev);
>>> + u32 val;
>>> +
>>> + if (!bgmac->plat.nicpm_base)
>>> + return;
>>> +
>>> + val = NICPM_IOMUX_CTRL_INIT_VAL;
>>> + switch (bgmac->net_dev->phydev->speed) {
>>> + default:
>>> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
>>> + case SPEED_1000:
>>> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
>>> + break;
>>> + case SPEED_100:
>>> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
>>> + break;
>>> + case SPEED_10:
>>> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
>>> + break;
>>> + }
>>> +
>>> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
>>> +
>>> + usleep_range(10, 100);
>>
>> Does not seem like a good idea, do you need that sleep?
>
> Oops, that's not supposed to be there. Removed.
>
>
>>> +
>>> + bgmac_adjust_link(bgmac->net_dev);
>>> +}
>>> +
>>> static int platform_phy_connect(struct bgmac *bgmac)
>>> {
>>> struct phy_device *phy_dev;
>>>
>>> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
>>> - bgmac_adjust_link);
>>> + if (bgmac->plat.nicpm_base)
>>> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
>>> + bgmac->dev->of_node,
>>> + bgmac_nicpm_speed_set);
>>> + else
>>> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
>>> + bgmac->dev->of_node,
>>> + bgmac_adjust_link);
>>> if (!phy_dev) {
>>> dev_err(bgmac->dev, "Phy connect failed\n");
>>> return -ENODEV;
>>> }
>>>
>>> + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
>>> + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
>>> +
>>> return 0;
>>> }
>>>
>>> @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
>>>
>>> platform_set_drvdata(pdev, bgmac);
>>>
>>> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
>>> + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
>>> +
>>> /* Set the features of the 4707 family */
>>> bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
>>> bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
>>> @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
>>> if (IS_ERR(bgmac->plat.idm_base))
>>> return PTR_ERR(bgmac->plat.idm_base);
>>>
>>> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
>>> + if (regs) {
>>> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
>>> + regs);
>>> + if (IS_ERR(bgmac->plat.nicpm_base))
>>> + return PTR_ERR(bgmac->plat.nicpm_base);
>>> + }
>>> +
>>> bgmac->read = platform_bgmac_read;
>>> bgmac->write = platform_bgmac_write;
>>> bgmac->idm_read = platform_bgmac_idm_read;
>>> @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
>>> static const struct of_device_id bgmac_of_enet_match[] = {
>>> {.compatible = "brcm,amac",},
>>> {.compatible = "brcm,nsp-amac",},
>>> + {.compatible = "brcm,ns2-amac",},
>>> {},
>>> };
>>>
>>> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
>>> index 38876ec..1796208 100644
>>> --- a/drivers/net/ethernet/broadcom/bgmac.c
>>> +++ b/drivers/net/ethernet/broadcom/bgmac.c
>>> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
>>> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
>>> static void bgmac_chip_init(struct bgmac *bgmac)
>>> {
>>> + /* Clear any erroneously pending interrupts */
>>> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
>>> +
>>> /* 1 interrupt per received frame */
>>> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>>>
>>> @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
>>> struct bgmac *bgmac = netdev_priv(net_dev);
>>> int err = 0;
>>>
>>> - bgmac_chip_reset(bgmac);
>>> -
>>
>> Is this removal intentional? Maybe it should be special cased with
>> checking for a NS2 BGMAC instance and not do it in that case?
>
> The reset seems completely unnecessary. There is already 2 resets in
> the probe routine, another reset serves no purpose. I can add it
> back, as it does not seem to have the negative effect I was seeing
> before.
After repeated ifconfig down/up, does Ethernet still work with this
reset removed?
Thanks.
>
> Of course, if I remove this one I should remove the reset in the close
> too (which seems even more unnecessary, but I didn't remove it).
>
> Thanks,
> Jon
>
>> --
>> Florian
next prev parent reply other threads:[~2016-10-27 22:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 19:35 [PATCH 0/5] add NS2 support to bgmac Jon Mason
2016-10-26 19:35 ` [PATCH 1/5] net: phy: broadcom: Add BCM54810 phy entry Jon Mason
[not found] ` <20161027091505.GB12841@lunn.ch>
2016-10-27 22:43 ` Jon Mason
2016-10-26 19:35 ` [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac Jon Mason
2016-10-27 9:17 ` Andrew Lunn
2016-10-27 21:21 ` Jon Mason
2016-10-27 21:25 ` Florian Fainelli
2016-10-26 19:35 ` [PATCH 3/5] net: ethernet: bgmac: device tree phy enablement Jon Mason
2016-10-26 19:36 ` [PATCH 4/5] net: ethernet: bgmac: add NS2 support Jon Mason
2016-10-26 21:50 ` Florian Fainelli
2016-10-27 20:51 ` Jon Mason
2016-10-27 22:21 ` Ray Jui [this message]
2016-10-27 22:32 ` Ray Jui
2016-10-26 19:36 ` [PATCH 5/5] arm64: dts: NS2: add AMAC ethernet support Jon Mason
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=ccbaf726-b1fc-975a-215c-17e2870328a6@broadcom.com \
--to=ray.jui@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=jon.mason@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
--cc=rafal@milecki.pl \
--cc=robh+dt@kernel.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
all inboxes | Powered by JetHome®