Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752487AbdF0JlW (ORCPT ); Tue, 27 Jun 2017 05:41:22 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:42788 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbdF0JlO (ORCPT ); Tue, 27 Jun 2017 05:41:14 -0400 Date: Tue, 27 Jun 2017 11:41:11 +0200 From: Maxime Ripard To: Andre Przywara Cc: Corentin Labbe , Chen-Yu Tsai , Rob Herring , Mark Rutland , Russell King , Catalin Marinas , Will Deacon , Giuseppe Cavallaro , alexandre.torgue@st.com, devicetree , netdev , linux-kernel , linux-sunxi , linux-arm-kernel , Icenowy Zheng , david.wu@rock-chips.com, Florian Fainelli , Andrew Lunn , Heiko =?iso-8859-1?Q?St=FCbner?= Subject: Re: [PATCH v6 05/21] net-next: stmmac: Add dwmac-sun8i Message-ID: <20170627094111.supxmzf2k3n3ewec@flea.lan> References: <20170531071852.12422-1-clabbe.montjoie@gmail.com> <20170531071852.12422-6-clabbe.montjoie@gmail.com> <8e3d73a7-e9ff-d3e2-4bce-bcc79cdf86db@arm.com> <20170627080529.GA2468@Red> <20170627082103.GB2468@Red> <530f7b3e-247d-2e4d-8174-ce6195bacf5b@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xsltood7yik5kf4h" Content-Disposition: inline In-Reply-To: <530f7b3e-247d-2e4d-8174-ce6195bacf5b@arm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4900 Lines: 130 --xsltood7yik5kf4h Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 27, 2017 at 10:02:45AM +0100, Andre Przywara wrote: > Hi, >=20 > (CC:ing some people from that Rockchip dmwac series) >=20 > On 27/06/17 09:21, Corentin Labbe wrote: > > On Tue, Jun 27, 2017 at 04:11:21PM +0800, Chen-Yu Tsai wrote: > >> On Tue, Jun 27, 2017 at 4:05 PM, Corentin Labbe > >> wrote: > >>> On Mon, Jun 26, 2017 at 01:18:23AM +0100, Andr=E9 Przywara wrote: > >>>> On 31/05/17 08:18, Corentin Labbe wrote: > >>>>> The dwmac-sun8i is a heavy hacked version of stmmac hardware by > >>>>> allwinner. > >>>>> In fact the only common part is the descriptor management and the f= irst > >>>>> register function. > >>>> > >>>> Hi, > >>>> > >>>> I know I am a bit late with this, but while adapting the U-Boot driv= er > >>>> to the new binding I was wondering about the internal PHY detection: > >>>> > >>>> > >>>> So here you seem to deduce the usage of the internal PHY by the PHY > >>>> interface specified in the DT (MII =3D internal, RGMII =3D external). > >>>> I think I raised this question before, but isn't it perfectly legal = for > >>>> a board to use MII with an external PHY even on those SoCs that feat= ure > >>>> an internal PHY? > >>>> On the first glance that does not make too much sense, but apart from > >>>> not being the correct binding to describe all of the SoCs features I= see > >>>> two scenarios: > >>>> 1) A board vendor might choose to not use the internal PHY because it > >>>> has bugs, lacks features (configurability) or has other issues. For > >>>> instance I have heard reports that the internal PHY makes the SoC go > >>>> rather hot, possibly limiting the CPU frequency. By using an external > >>>> MII PHY (which are still cheaper than RGMII PHYs) this can be avoide= d. > >>>> 2) A PHY does not necessarily need to be directly connected to > >>>> magnetics. Indeed quite some boards use (RG)MII to connect to a swit= ch > >>>> IC or some other network circuitry, for instance fibre connectors. > >>>> > >>>> So I was wondering if we would need an explicit: > >>>> allwinner,use-internal-phy; > >>>> boolean DT property to signal the usage of the internal PHY? > >>>> Alternatively we could go with the negative version: > >>>> allwinner,disable-internal-phy; > >>>> > >>>> Or what about introducing a new "allwinner,internal-mii-phy" compati= ble > >>>> string for the *PHY* node and use that? > >>>> > >>>> I just want to avoid that we introduce a binding that causes us > >>>> headaches later. I think we can still fix this with a followup patch > >>>> before the driver and its binding hit a release kernel. > >>>> > >>>> Cheers, > >>>> Andre. > >>>> > >>> > >>> I just see some patch, where "phy-mode =3D internal" is valid. > >>> I will try to find a way to use it > >> > >> Can you provide a link? > >=20 > > https://lkml.org/lkml/2017/6/23/479 > >=20 > >> > >> I'm not a fan of using phy-mode for this. There's no guarantee what > >> mode the internal PHY uses. That's what phy-mode is for. >=20 > I can understand Chen-Yu's concerns, but ... >=20 > > For each soc the internal PHY mode is know and setted in emac_variant/i= nternal_phy > > So its not a problem. >=20 > that is true as well, at least for now. > > So while I agree that having a separate property to indicate the usage > of the internal PHY would be nice, I am bit tempted to use this easier > approach and piggy back on the existing phy-mode property. We're trying to fix an issue that works for now too. If we want to consider future weird cases, then we must consider all of them. And the phy mode changing is definitely not really far fetched. I agree with Chen-Yu, and I really feel like the compatible solution you suggested would cover both your concerns, and ours. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --xsltood7yik5kf4h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZUig3AAoJEBx+YmzsjxAgcSwP/2lCrOOSY6xhAjJ+TNm+a9KW bgTl1Czqt03Xv5/tapxDiuAHdgvy6gD4tUzZjVtbjgI/d32WDQhjqCwRvEkOUmdA +M3drVN1ZywPO+dmhr6lpmDUHB+5HOizeWVWBV8pFjIjamM7QthmWXQI2uw3ztSQ FyZ/3SZ8YL12OW5emvXiugdtQC8eWAHtbtE2EN9HXHVaUQZ14lHSoqFnFrOzLB6t yCJj+/7wecdZJSIGM+piDaiIOYF6bpytC8BO0/SnDQ6GZ9JuVMK8YF5/BK81A9fy CyXdo8/XFZGuc724DqrofXAnkXYloShqvBiuxjmYzlGc69viRgh9BkfePAM9SiL8 c0wVO5nUKEeHia+H7uF+U+Wu8y5C8byECoXmTPKtGGcIASzPydYsMT/O7Bcxj9Ia AaTXxT4Qzd3xz3jAi/LnAmhQRSo6/V291DGbB5FtZ7F/EkUe68+P+mwFPo11Cx/z H1U45fDKmnMdlSTld2WaBOTY90P1ap8doXmNwN8Do9xdob/Vnw9cB/+F4VD5us5A PWHBQBQX3vCe+wM1A0UF4GRg8Fah/ev5MCbhBJqYk7sfqpWAaCVqrRTRr6ukwwhi 4g6OcKkOgAMt2q0f3a0B9tFnXq5+PIMX7BGK8OgfbcWQx74wo7d2n8JsDZjdzo2u u06GMpJ/fkBn778f4ZyX =O1J0 -----END PGP SIGNATURE----- --xsltood7yik5kf4h--