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:   Ioana Ciornei <ioana.ciornei@nxp.com>
To:     Vladimir Oltean <olteanv@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>
CC:     netdev <netdev@vger.kernel.org>,
        Russell King <rmk+kernel@armlinux.org.uk>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] net: dsa: Deal with non-existing PHY/fixed-link
Thread-Topic: [PATCH net-next] net: dsa: Deal with non-existing PHY/fixed-link
Thread-Index: AQHVH8MsxSzXIT7T/0mW4aEu7RtYPg==
Date:   Mon, 10 Jun 2019 20:49:59 +0000
Message-ID: <VI1PR0402MB2800ED1A422B900F63561F9CE0130@VI1PR0402MB2800.eurprd04.prod.outlook.com>
References: <20190610193150.22231-1-f.fainelli@gmail.com>
 <CA+h21hrcymxF7zk4yHFGhjxbLERTCU6WkfzLGQVoZ5Yxoo4xxw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.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: b0dc24dd-449b-432c-2d96-08d6ede533e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 20:49:59.1741
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ioana.ciornei@nxp.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB2704
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 6/10/19 10:53 PM, Vladimir Oltean wrote:=0A=
> On Mon, 10 Jun 2019 at 22:31, Florian Fainelli <f.fainelli@gmail.com> wro=
te:=0A=
>>=0A=
>> We need to specifically deal with phylink_of_phy_connect() returning=0A=
>> -ENODEV, because this can happen when a CPU/DSA port does connect=0A=
>> neither to a PHY, nor has a fixed-link property. This is a valid use=0A=
>> case that is permitted by the binding and indicates to the switch:=0A=
>> auto-configure port with maximum capabilities.=0A=
>>=0A=
>> Fixes: 0e27921816ad ("net: dsa: Use PHYLINK for the CPU/DSA ports")=0A=
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>=0A=
>> ---=0A=
>>   net/dsa/port.c | 2 +-=0A=
>>   1 file changed, 1 insertion(+), 1 deletion(-)=0A=
>>=0A=
>> diff --git a/net/dsa/port.c b/net/dsa/port.c=0A=
>> index d74bc9df1359..dde3085ff065 100644=0A=
>> --- a/net/dsa/port.c=0A=
>> +++ b/net/dsa/port.c=0A=
>> @@ -622,7 +622,7 @@ static int dsa_port_phylink_register(struct dsa_port=
 *dp)=0A=
>>          }=0A=
>>=0A=
>>          err =3D phylink_of_phy_connect(dp->pl, port_dn, 0);=0A=
>> -       if (err) {=0A=
>> +       if (err && err !=3D -ENODEV) {=0A=
>>                  pr_err("could not attach to PHY: %d\n", err);=0A=
>>                  goto err_phy_connect;=0A=
>>          }=0A=
>> --=0A=
>> 2.17.1=0A=
>>=0A=
> =0A=
> Hi Florian,=0A=
> =0A=
> Can you give an example of when this is a valid use case, and why=0A=
> fixed-link is not appropriate?=0A=
> =0A=
> Regards,=0A=
> -Vladimir=0A=
> =0A=
=0A=
Hi,=0A=
=0A=
This reminds me of a previous discussion on what to do when the DSA CPU =0A=
port does not have a device_tree node at all: =0A=
https://www.spinics.net/lists/netdev/msg573554.html.=0A=
=0A=
This was the case of the dsa-loop driver that probes as a platform =0A=
device. I'm still not clear how the PHYLINK callbacks are supposed to =0A=
work in that case though.=0A=
=0A=
--=0A=
Ioana=0A=
=0A=
=0A=