From: Madalin-Cristian Bucur <madalin.bucur@freescale.com>
To: Stas Sergeev <stsp@list.ru>, "f.fainelli@gmail.com" <f.fainelli@gmail.com>,
        David Miller <davem@davemloft.net>
CC: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Liberman Igal <Igal.Liberman@freescale.com>
Subject: RE: [v2] net: phy: fixed: propagate fixed link values to struct
Thread-Topic: [v2] net: phy: fixed: propagate fixed link values to struct
Thread-Index: AQHQ4A/yGdmcH5E58USKyGCzNqMnv54ebfuAgAAFNdA=
Date: Wed, 26 Aug 2015 16:12:43 +0000
Message-ID: <BL2PR03MB545D559B9B04BFED6DE4266E6600@BL2PR03MB545.namprd03.prod.outlook.com>
References: <1440601127-7663-1-git-send-email-madalin.bucur@freescale.com>
 <55DDE079.7070401@list.ru>
In-Reply-To: <55DDE079.7070401@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: 26 Aug 2015 16:12:43.5903
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB497
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 t7QGCr66026287
Content-Length: 1363
Lines: 29

> -----Original Message-----
> From: Stas Sergeev [mailto:stsp@list.ru]
> Sent: Wednesday, August 26, 2015 6:51 PM
> To: Bucur Madalin-Cristian-B32716 <madalin.bucur@freescale.com>;
> f.fainelli@gmail.com
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Liberman Igal-
> B31950 <Igal.Liberman@freescale.com>
> Subject: Re: [v2] net: phy: fixed: propagate fixed link values to struct
> 
> 26.08.2015 17:58, Madalin Bucur пишет:
> > The fixed link values parsed from the device tree are stored in
> > the struct fixed_phy member status. The struct phy_device members
> > speed, duplex were not updated.
> 
> ACK, but IMHO it will make more sense if you include that
> into your upcoming patch set rather than sending separately,
> as otherwise there is simply no in-kernel users of that new
> functionality (all the current users likely do not access
> these fields as early as you want to, so they don't care).
> In any case, the patch looks good to me and the policy is
> up to others.

Given that it's more of a fix than a feature, I think it can be picked up separate
from a certain driver that accesses those fields early but I guess Florian, David
will decide this.

Thanks,
Madalin
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?