From: Parshuram Raju Thombare <pthombar@cadence.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: "andrew@lunn.ch" <andrew@lunn.ch>,
"nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rafal Ciepiela <rafalc@cadence.com>,
Anil Joy Varughese <aniljoy@cadence.com>,
Piotr Sroka <piotrs@cadence.com>
Subject: RE: [PATCH v2 1/5] net: macb: add phylink support
Date: Wed, 19 Jun 2019 10:51:16 +0000 [thread overview]
Message-ID: <CO2PR07MB2469165566F5C46D1A35BF28C1E50@CO2PR07MB2469.namprd07.prod.outlook.com> (raw)
In-Reply-To: <20190619092213.32fpgehe74qhln5z@shell.armlinux.org.uk>
Hi Russel,
Thanks for review comments.
>On Wed, Jun 19, 2019 at 09:40:36AM +0100, Parshuram Thombare wrote:
>
>> + bitmap_and(supported, supported, mask,
>__ETHTOOL_LINK_MODE_MASK_NBITS);
>
>> + bitmap_and(state->advertising, state->advertising, mask,
>
>> + __ETHTOOL_LINK_MODE_MASK_NBITS);
>
>
>
>Consider using linkmode_and() here.
>
Ok
>> +static int gem_phylink_mac_link_state(struct phylink_config *pl_config,
>
>> + struct phylink_link_state *state)
>
>> + state->speed = bp->speed;
>
>> + state->duplex = bp->duplex;
>
>> + state->link = bp->link;
>
>
>
>You can't read from the hardware what the actual MAC is doing?
As mostly PHY mode was used in driver and this method is called only for
in band mode, I added this is just as place holder and used in next patch set
where SGMII support is added. Should I remove it from this patch ?
>> +static void gem_mac_config(struct phylink_config *pl_config, unsigned int
>mode,
>> + const struct phylink_link_state *state)
>
>> +{
>> + if (bp->speed != state->speed ||
>
>> + bp->duplex != state->duplex) {
>
>Please read the updated phylink documentation - state->{speed,duplex}
>are not always valid depending on the negotiation mode.
At least for PHY and FIXED mode I see mac_config is called after state is updated in phylink_resolve().
In case of IN BAND mode, I see mac_config may not get called after state is updated in mac_link_state()
method. Are you suggesting to configure MAC here only for FIXED and PHY mode ?
>> + bp->pl_config.type = PHYLINK_NETDEV;
>
>> + bp->pl = phylink_create(&bp->pl_config, of_fwnode_handle(np),
>
>> + bp->phy_interface, &gem_phylink_ops);
>
>> + if (IS_ERR(bp->pl)) {
>
>> + netdev_err(dev,
>
>> + "error creating PHYLINK: %ld\n", PTR_ERR(bp->pl));
>
>> + return PTR_ERR(bp->pl);
>
>> }
>
>At this point bp->pl can never be NULL.
phylink_create() does return failure also. I think this comment is not for above snippet.
>
>> - if (!dev->phydev) {
>
>> + if (!bp->pl) {
>
>
>
>So this check is unnecessary.
>
Ok, I will remove this check.
>> - if (dev->phydev)
>
>> - phy_stop(dev->phydev);
>
>> + if (bp->pl)
>
>> + phylink_stop(bp->pl);
>
>
>
>Ditto.
Ok, I will remove this redundant check.
>> + if (!bp->pl)
>
>> + return -ENOTSUPP;
>
>
>
>Ditto.
Ok, I will remove this redundant check.
>
>> + if (!bp->pl)
>
>> + return -ENOTSUPP;
>
>
>
>Ditto.
Ok, I will remove this redundant check.
>
>> + if (!bp->pl)
>
>> return -ENODEV;
>
>
>
>Ditto.
Ok, I will remove this redundant check.
>> @@ -4183,13 +4219,12 @@ static int macb_probe(struct platform_device
>*pdev)
>
>> struct clk *tsu_clk = NULL;
>
>> unsigned int queue_mask, num_queues;
>> + phy_mode = of_get_phy_mode(np);
>
>> + if (phy_mode < 0)
>
>> /* not found in DT, MII by default */
>
>> bp->phy_interface = PHY_INTERFACE_MODE_MII;
>
>> else
>
>> - bp->phy_interface = err;
>
>> + bp->phy_interface = phy_mode;
>
>The phy interface mode is managed by phylink - and there are phys out
>there that dynamically change their link mode. You may wish to update
>the link mode in your mac_config() implementation too.
>
Ok, I will modify mac_config to check phy_mode and program MAC accordingly.
>> + if (dev->phydev)
>
>> + phy_attached_info(dev->phydev);[]
>
>phylink already prints information about the attached phy, why do we
>need another print here?
>
Ok, I will remove this.
>> - phy_stop(netdev->phydev);
>> - phy_suspend(netdev->phydev);
>> + phylink_stop(bp->pl);
>> + if (netdev->phydev)
>> + phy_suspend(netdev->phydev);
>
>When the attached phy is stopped, the state machine suspends the phy.
>Why do we need an explicit call to phy_suspend() here, bypassing
>phylink?
>
Here I am just trying to keep functionality unchanged, just replacing
Phylib API's with phylink API's.
>> - phy_resume(netdev->phydev);
>
>> - phy_init_hw(netdev->phydev);
>
>> - phy_start(netdev->phydev);
>
>> + if (netdev->phydev) {
>
>> + phy_resume(netdev->phydev);
>
>> + phy_init_hw(netdev->phydev);
>
>> + }
>
>> + phylink_start(bp->pl);
>
>
>
>When the phy is started, the phy state machine will resume the phy.
>Same question as above.
>
Here I am just trying to keep functionality unchanged, just replacing
Phylib API's with phylink API's.
Regards,
Parshuram Thombare
next prev parent reply other threads:[~2019-06-19 10:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 8:40 [PATCH v2 0/5] net: macb: cover letter Parshuram Thombare
2019-06-19 8:40 ` [PATCH v2 1/5] net: macb: add phylink support Parshuram Thombare
2019-06-19 9:22 ` Russell King - ARM Linux admin
2019-06-19 10:51 ` Parshuram Raju Thombare [this message]
2019-06-19 8:40 ` [PATCH v2 2/5] net: macb: add support for sgmii MAC-PHY interface Parshuram Thombare
2019-06-19 9:31 ` Russell King - ARM Linux admin
2019-06-19 11:23 ` Parshuram Raju Thombare
2019-06-19 12:32 ` Russell King - ARM Linux admin
2019-06-20 5:56 ` Parshuram Raju Thombare
2019-06-20 7:46 ` Russell King - ARM Linux admin
2019-06-19 8:40 ` [PATCH v2 3/5] net: macb: add support for c45 PHY Parshuram Thombare
2019-06-19 8:41 ` [PATCH v2 4/5] net: macb: add support for high speed interface Parshuram Thombare
2019-06-19 8:41 ` [PATCH v2 5/5] net: macb: parameter added to cadence ethernet controller DT binding Parshuram Thombare
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=CO2PR07MB2469165566F5C46D1A35BF28C1E50@CO2PR07MB2469.namprd07.prod.outlook.com \
--to=pthombar@cadence.com \
--cc=andrew@lunn.ch \
--cc=aniljoy@cadence.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=piotrs@cadence.com \
--cc=rafalc@cadence.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).