linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florinel Iordache <florinel.iordache@nxp.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	Leo Li <leoyang.li@nxp.com>,
	"Madalin Bucur (OSS)" <madalin.bucur@oss.nxp.com>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Florinel Iordache <florinel.iordache@nxp.com>
Subject: RE: [EXT] Re: [PATCH net-next 6/9] net: phy: add backplane kr driver support
Date: Wed, 1 Apr 2020 14:21:28 +0000	[thread overview]
Message-ID: <AM0PR04MB544389A6B2400335A23E4960FBC90@AM0PR04MB5443.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200401135135.GA62290@lunn.ch>

> On Wed, Apr 01, 2020 at 01:35:36PM +0000, Florinel Iordache wrote:
> > > On Thu, Mar 26, 2020 at 03:51:19PM +0200, Florinel Iordache wrote:
> > > > +static void setup_supported_linkmode(struct phy_device *bpphy) {
> > > > +     struct backplane_phy_info *bp_phy = bpphy->priv;
> > >
> > > I'm not sure it is a good idea to completely take over phydev->priv
> > > like this, in what is just helper code. What if the PHY driver needs
> > > memory of its own? There are a few examples of this already in other
> > > PHY drivers. Could a KR PHY contain a temperature sensor? Could it
> > > contain statistics counters which need accumulating?
> > >
> > >         Andrew
> >
> > Backplane KR driver allocates memory for structure backplane_phy_info
> > which is saved in phydev->priv. After all this is the purpose of priv
> > according to its description in phy.h: <<private data pointer For use
> > by PHYs to maintain extra state>>. Here the priv is used to maintain
> > extra state needed for backplane. This way the backplane specific data
> > becomes available for all PHY callbacks (defined in struct phy_driver)
> > that receive a pointer to phy_device structure. This initial version
> > doesn't include accumulating statistics counters but we have in plan
> > to add these in future versions. The counters will be kept in specific
> > structures as members of the main backplane data mentioned above and
> > entire support will be integrated with ethtool.
> 
> Hi Florinel
> 
> And what about hwmon, or anything else which a driver needs memory for?
> 
> As far as i see it, we have two bodies of code here. There is a set of helpers
> which implement most of the backplane functionality. And then there is an
> example driver for your hardware. In the future we expect other drivers to be
> added for other vendors hardware.
> 
> phydev->priv is for the driver. helpers should not assume they have
> complete control over it.
> 
> Anyway, this may be a mute point. Lets first solve the problem of how a PCS is
> represented.
> 
>   Andrew

Hi Andrew,

Backplane driver was designed as a generic backplane driver over
the PHY Abstraction Layer, containing standard implementations over
which several specific devices can be added.
(please see the diagram existent in chapter: Ethernet Backplane support
architecture, in the Documentation/networking/backplane.rst)
So according to this design, the backplane driver can use the priv pointer
provided by the layer below which is the PHY to be used as extra state
by the next upper layer which is generic backplane. On the same concept
we can provide another priv pointer in backplane main structure which is
equivalent to phy_device to be used by the specific backplane drivers on
the upper layer.
Actually for this reason, in v2 which I am currently working, I already
renamed the structure 'backplane_phy_info' to 'backplane_device'

Thank you,
Florin.

  reply	other threads:[~2020-04-01 14:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01 13:35 [PATCH net-next 6/9] net: phy: add backplane kr driver support Florinel Iordache
2020-04-01 13:51 ` Andrew Lunn
2020-04-01 14:21   ` Florinel Iordache [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-03-26 13:51 [PATCH net-next 0/9] net: ethernet backplane support Florinel Iordache
     [not found] ` <1585230682-24417-7-git-send-email-florinel.iordache@nxp.com>
2020-03-27  1:07   ` [PATCH net-next 6/9] net: phy: add backplane kr driver support Andrew Lunn
2020-03-27 13:02     ` [EXT] " Florinel Iordache
2020-03-27 13:23       ` Andrew Lunn

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=AM0PR04MB544389A6B2400335A23E4960FBC90@AM0PR04MB5443.eurprd04.prod.outlook.com \
    --to=florinel.iordache@nxp.com \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=kuba@kernel.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=madalin.bucur@oss.nxp.com \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@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;
as well as URLs for NNTP newsgroup(s).