All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antoine Tenart <antoine.tenart@free-electrons.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>,
	davem@davemloft.net, andrew@lunn.ch, jason@lakedaemon.net,
	sebastian.hesselbarth@gmail.com,
	gregory.clement@free-electrons.com,
	thomas.petazzoni@free-electrons.com, nadavh@marvell.com,
	linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
	mw@semihalf.com, stefanc@marvell.com,
	miquel.raynal@free-electrons.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
Date: Tue, 29 Aug 2017 13:23:40 +0200	[thread overview]
Message-ID: <20170829112340.GB31552@kwain> (raw)
In-Reply-To: <50072fdd-d370-8518-a9f4-73e121114e67@ti.com>

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

Hi Kishon,

On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> >  
> > +config PHY_MVEBU_CP110_COMPHY
> > +	tristate "Marvell CP110 comphy driver"
> > +	depends on ARCH_MVEBU && OF
> 
> (ARCH_MVEBU || COMPILE_TEST) above..

Sure, I'll update.

> > +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> > +	/* lane 0 */
> > +	MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> > +	/* lane 1 */
> > +	MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> > +	/* lane 2 */
> > +	MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> > +	MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> > +	/* lane 3 */
> > +	MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> > +	/* lane 4 */
> > +	MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> > +	MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> > +	MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> > +	/* lane 5 */
> > +	MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> > +};
> 
> IMHO all the lane and mode configuration should come from dt. That would make
> it more reusable when comphy is configured differently.

These connexions between engines and the comphy lanes are inside the
SoC. They won't change for a given SoC, and the actual configuration is
at the board level to know what is connected to the output of a given
lane, which is already described into the dt (the lane phandle).

So I think we can keep this inside the driver, and we'll had other
tables if the same comphy is ever used in another SoC.

What do you think?

> > +static const struct phy_ops mvebu_comphy_ops = {
> > +	.power_on	= mvebu_comphy_power_on,
> > +	.power_off	= mvebu_comphy_power_off,
> > +	.set_mode	= mvebu_comphy_set_mode,
> 
> missing .owner

I'll fix that.

> > +static struct phy *mvebu_comphy_xlate(struct device *dev,
> > +				      struct of_phandle_args *args)
> > +{
> > +	struct mvebu_comphy_priv *priv = dev_get_drvdata(dev);
> > +	struct mvebu_comphy_lane *lane;
> > +	int i;
> > +
> > +	if (WARN_ON(args->args[0] >= MVEBU_COMPHY_PORTS))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	for (i = 0; i < MVEBU_COMPHY_LANES; i++) {
> > +		if (!priv->phys[i])
> > +			continue;
> > +
> > +		lane = phy_get_drvdata(priv->phys[i]);
> > +		if (priv->phys[i] && args->np == lane->of_node)
> > +			break;
> > +	}
> 
> You should be able to directly use of_phy_simple_xlate to get the phy pointer.
> (For that to work child node pointer should be passed in devm_phy_create).

Good idea, I'll look into this and update.

Thanks!
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-08-29 11:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28 14:57 [PATCH net-next v3 00/13] net: mvpp2: comphy configuration Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum Antoine Tenart
2017-08-29 10:38   ` Kishon Vijay Abraham I
2017-08-29 11:27     ` Antoine Tenart
2017-08-29 12:21       ` Kishon Vijay Abraham I
2017-08-28 14:57 ` [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver Antoine Tenart
2017-08-29 11:04   ` Kishon Vijay Abraham I
2017-08-29 11:23     ` Antoine Tenart [this message]
2017-08-29 12:25       ` Kishon Vijay Abraham I
2017-08-29 13:12         ` Antoine Tenart
2017-08-30  5:31           ` Kishon Vijay Abraham I
2017-08-30  6:43             ` Antoine Tenart
2017-08-30  5:19   ` Kishon Vijay Abraham I
2017-08-30  6:36     ` Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 03/13] Documentation/bindings: phy: document the Marvell " Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 04/13] net: mvpp2: initialize the comphy Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 05/13] net: mvpp2: simplify the link_event function Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 06/13] net: mvpp2: improve the link management function Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 07/13] net: mvpp2: do not set GMAC autoneg when using XLG MAC Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 08/13] net: mvpp2: dynamic reconfiguration of the comphy/GoP/MAC Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 09/13] arm64: dts: marvell: extend the cp110 syscon register area length Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 10/13] arm64: dts: marvell: add comphy nodes on cp110 master and slave Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 11/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 12/13] arm64: dts: marvell: 7040-db: " Antoine Tenart
2017-08-28 14:57 ` [PATCH net-next v3 13/13] arm64: defconfig: enable Marvell CP110 comphy Antoine Tenart

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=20170829112340.GB31552@kwain \
    --to=antoine.tenart@free-electrons.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=miquel.raynal@free-electrons.com \
    --cc=mw@semihalf.com \
    --cc=nadavh@marvell.com \
    --cc=netdev@vger.kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=stefanc@marvell.com \
    --cc=thomas.petazzoni@free-electrons.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.