From: Madalin-Cristian Bucur <madalin.bucur@freescale.com>
To: Stas Sergeev <stsp@list.ru>, Florian Fainelli <f.fainelli@gmail.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "grant.likely@linaro.org" <grant.likely@linaro.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>
CC: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Liberman Igal <Igal.Liberman@freescale.com>,
        Stas Sergeev <stsp@users.sourceforge.net>,
        "joakim.tjernlund@transmode.se" <joakim.tjernlund@transmode.se>,
        Shaohui Xie <Shaohui.Xie@freescale.com>
Subject: RE: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code
Thread-Topic: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code
Thread-Index: AQHQz40u7/EeGP0M3EaSWT7KT29M554CYVyAgASdLgCAAAcBIIAACVUAgAFL3eCAABP/gIAABbOQ
Date: Wed, 12 Aug 2015 14:43:38 +0000
Message-ID: <BL2PR03MB5458B9D2402DE68E9B9014AE67E0@BL2PR03MB545.namprd03.prod.outlook.com>
References: <1438785745-15517-1-git-send-email-madalin.bucur@freescale.com>
 <55C63D3B.5020005@gmail.com> <55CA1C14.3000202@list.ru>
 <BL2PR03MB545D4E18DE41AE01AFC37D6E67F0@BL2PR03MB545.namprd03.prod.outlook.com>
 <55CA29C8.5000707@list.ru>
 <BL2PR03MB545929237EF33BA13089EC1E67E0@BL2PR03MB545.namprd03.prod.outlook.com>
 <55CB50F1.7050308@list.ru>
In-Reply-To: <55CB50F1.7050308@list.ru>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2015 14:43:38.3199
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB500
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t7CEhmup019267
Content-Length: 5594
Lines: 148

> -----Original Message-----
> From: Stas Sergeev [mailto:stsp@list.ru]
>
> 12.08.2015 16:26, Madalin-Cristian Bucur пишет:
> >>> I've tried to make the smallest changes that allow me to retrieve those
> >>> without modifying existing API.
> >>> Why is it important to hide the default values from the MAC driver?
> >> My worry is that the fixed values are not really fixed, and
> >> therefore are not always useful to access directly. It is likely
> >> not a problem for your use-case, as, as you say, the AN is
> >> disabled, but this is probably not the best to do in general.
> > Yes, not a problem in my case.
> >
> >> And also you do:
> >> ---
> >>
> >> -		err = of_phy_register_fixed_link(mac_node);
> >> -		if (err)
> >> +		struct phy_device *phy;
> >> +
> >> +		mac_dev->fixed_link = kzalloc(sizeof(*mac_dev-
> >>> fixed_link),
> >> +					      GFP_KERNEL);
> >> +		if (of_phy_parse_fixed_link(mac_node, mac_dev-
> >>> fixed_link))
> >> +			goto _return_dev_set_drvdata;
> >> +
> >> +		phy = fixed_phy_register(PHY_POLL, mac_dev->fixed_link,
> >> +					 mac_node);
> >>
> >> ---
> >>
> >> which means you really want to circumvent the current OF
> >> api quite a lot, without saying why in the patch description.
> > I circumvent the API because I din not want to change existing API.
> > If I could get a reference to the status struct without changing any code
> > or without being required to call by myself fixed_phy_register(), I
> > would of done that. Given the existing code in
> of_phy_register_fixed_link(),
> > this was my only option. I could have broken of_phy_register_fixed_link()
> > in two functions:
> >
> > of_phy_parse_fixed_link() and of_phy_register_fixed_link(), the latter
> doing only
> > the call to fixed_phy_register()
> >
> > that would allow to keep of_phy_register_fixed_link() as it is, broken in
> two stages:
> >
> > - parsing
> > - registering
> >
> > than can be used by other drivers in order to get the status but I think it's
> overkill.
> What I referred to as "circumventing an API" is that you do
> phy = fixed_phy_register(PHY_POLL, mac_dev->fixed_link, + mac_node);
> by hands, instead of letting the of_phy_register_fixed_link() doing so.
> 
> How about a smaller circumvention, like this for instance:
> ---
> err = of_phy_register_fixed_link(mac_node);
> phy = of_phy_find_device(dn);
> status = fixed_phy_get_link_status(phy);    // no such func, to be coded up
> ---
> 
> Or even like this:
> ---
> err = of_phy_register_fixed_link(mac_node);
> phy = of_phy_find_device(dn);
> set_speed_and_duplex(phy->speed, phy->duplex);    // not sure if these
> values are available that early
> ---

After my patch, all that of_phy_register_fixed_link() does is to call
the new parsing function I introduced then register the fixed PHY.
I could have done this (pseudocode):

- add of_phy_parse_fixed_link() as seen in the patch
- add of_phy_register_fixed_phy() that just calls fixed_phy_register():

int of_phy_register_fixed_phy(node)
{
	phy = fixed_phy_register(PHY_POLL, mac_dev->fixed_link,
				     mac_node);
	return (!phy);
}

- change of_phy_register_fixed_link() to contain only this:

int of_phy_register_fixed_link(node)
{
	of_phy_parse_fixed_link(node, &status);

	return of_phy_register_fixed_phy(node);
}

Then I could call only of_* functions but the end result would be the same and
of_phy_register_fixed_phy() would not justify its existence that much...

The getter for status you suggest would be fine, but not sure how one would retrieve
it from the mac_node unless we change of_phy_register_fixed_link() to return the
pointer to phy (and all the drivers that use it...).

> 
> Also I meant the description should have been in the patch,
> not in the e-mail. :) You only wrote _what_ the patch does
> (which is of course obvious from the code itself), but not
> _why_ and _what was fixed_ (what didn't work).
> 


If you refer to the first, separation patch, I thought the description was enough:

    of: separate fixed link parsing from registration
    
    Some drivers may need to parse the fixed link values before registering
    the fixed link phy. Separate the parsing from the actual registration
    and provide an export for the added parsing function.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>

For this one it was a bit brief, I admit - the longer version would be that before it
we were not using from fixed link anything else but the fact the link was fixed
(ignored actual speed, duplex values there) and this patch tries to fix that.
In the end this patch will be squashed in a new FMan patch set, let me use that as
an excuse for the brief commit log :)

<snip>

> >   You are concerned about people
> > abusing this API to read fixed link status when the link is not really fixed, I'm
> concerned
> > about declaring the link as fixed-link when it's not. Maybe the
> naming/binding needs to be
> > revised to cover the case when all is fixed but the link.
> Yes, naming is the problem. fixed-link is just a bad name.
> See how it is defined:
> ---
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device.
> ---
> To me this means any non-MDIO PHY connection, but
> unfortunately the name "fixed-link" suggests a bit more
> than advertised. :(

Yes, maybe the new binding could be updated to load semantically the presence
or absence of certain parameters such as link.
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?