Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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 v4 2/5] net: macb: add support for sgmii MAC-PHY interface
Thread-Topic: [PATCH v4 2/5] net: macb: add support for sgmii MAC-PHY
 interface
Thread-Index: AQHVKaVHMt019Pka20mPugoFl8ah06apBQMAgAFRdiCAADaTgIAABQ5Q
Date:   Mon, 24 Jun 2019 10:14:41 +0000
Message-ID: <CO2PR07MB24699250A3773DE76B6D2E9EC1E00@CO2PR07MB2469.namprd07.prod.outlook.com>
References: <1561281419-6030-1-git-send-email-pthombar@cadence.com>
 <1561281781-13479-1-git-send-email-pthombar@cadence.com>
 <20190623101224.nzwodgfo6vvv65cx@shell.armlinux.org.uk>
 <CO2PR07MB246931C79F736F39D0523D3BC1E00@CO2PR07MB2469.namprd07.prod.outlook.com>
 <20190624093533.4vhvjmqqrucq2ixf@shell.armlinux.org.uk>
In-Reply-To: <20190624093533.4vhvjmqqrucq2ixf@shell.armlinux.org.uk>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cadence.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 93f675ba-10e0-4b8d-731b-08d6f88cc5fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 10:14:41.9197
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d36035c5-6ce6-4662-a3dc-e762e61ae4c9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pthombar@global.cadence.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB2520
X-Proofpoint-SPF-Result: pass
X-Proofpoint-SPF-Record: v=spf1 include:spf.smktg.jp include:_spf.salesforce.com
 include:mktomail.com include:spf-0014ca01.pphosted.com
 include:spf.protection.outlook.com include:auth.msgapp.com
 include:spf.mandrillapp.com ~all
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-24_08:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_check_notspam policy=outbound_check score=0
 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0
 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1810050000 definitions=main-1906240086
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> >I still don't think this makes much sense, splitting the interface
>> > configuration between here and below.
>> Do you mean splitting mac_config in two *_configure functions ?
>> This was done as per Andrew's suggestion to make code mode readable
>> and easy to manage by splitting MAC configuration for different interfac=
es.
>No, I mean here you disable SGMII if we're switching away from SGMII
>mode.... (note, this means there is more to come for this sentence)
Sorry, I misunderstood your original question. I think disabling old interf=
ace
and enabling new one can be done in single place. I will do this change.

>> >This will only be executed when we are not using inband mode, which
>> >basically means it's not possible to switch to SGMII in-band mode.
>> SGMII is used in default PHY mode. And above code is to program MAC to
>> select PCS and SGMII interface.
>... and here you enable it for SGMII mode, but only for non-inband
>modes.
>
>Why not:
>	if (change_interface)  {
>		if (state->interface =3D=3D PHY_INTERFACE_MODE_SGMII) {
>			// Enable SGMII mode and PCS
>			gem_writel(bp, NCFGR, ncfgr | GEM_BIT(SGMIIEN) |
>				   GEM_BIT(PCSSEL));
>		} else {
>			// Disable SGMII mode and PCS
>			gem_writel(bp, NCFGR, ncfgr & ~(GEM_BIT(SGMIIEN)
>				   GEM_BIT(PCSSEL)));
>			// Reset PCS
>			gem_writel(bp, PCS_CTRL, gem_readl(bp, PCS_CTRL)
>				   GEM_BIT(PCS_CTRL_RST));
>		}
>	}
>	if (!phylink_autoneg_inband(mode) &&
>	    (bp->speed !=3D state->speed || bp->duplex !=3D state->duplex)) {
>?
Ok

>> >> +
>> >> +		if (!interface_supported) {
>> >> +			netdev_err(dev, "Phy mode %s not supported",
>> >> +				   phy_modes(phy_mode));
>> >> +			goto err_out_free_netdev;
>> >> +		}
>> >> +
>> >>  		bp->phy_interface =3D phy_mode;
>> >> +	} else {
>> >> +		bp->phy_interface =3D phy_mode;
>> >> +	}
>> >If bp->phy_interface is PHY_INTERFACE_MODE_SGMII here, and
>> > mac_config()
>> >is called with state->interface =3D PHY_INTERFACE_MODE_SGMII, then
>> >mac_config() won't configure the MAC for the interface type - is that
>> >intentional?
>> In mac_config configure MAC for non in-band mode, there is also check fo=
r
>> speed, duplex
>> changes. bp->speed and bp->duplex are initialized to SPEED_UNKNOWN
>> and DUPLEX_UNKNOWN
>> values so it is expected that for non in band mode state contains valid =
speed
>> and duplex mode
>> which are different from *_UNKNOWN values.

>Sorry, this reply doesn't answer my question.  I'm not asking about
>bp->speed and bp->duplex.  I'm asking:
>1) why you are initialising bp->phy_interface here
>2) you to consider the impact that has on the mac_config() implementation
>  you are proposing
> because I think it's buggy.
bp->phy_interface is to store phy mode value from device tree. This is used=
 later=20
to know what phy interface user has selected for PHY-MAC. Same is used
to configure MAC correctly and based on your suggestion code is
added to handle PHY dynamically changing phy interface, in which=20
case bp->phy_interface is also updated. Though it may not be what user want=
,=20
if phy interface is totally decided by PHY and is anyway going to be differ=
ent from what user
has selected in DT, initializing it here doesn't make sense.
But in case of PHY not changing phy_interface dynamically bp->phy_interface=
 need to be
initialized with value from DT.

Regards,
Parshuram Thombare