Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1058671ybh; Mon, 13 Jul 2020 08:19:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzljiBA1TyBLegrSHyRfi6rf9ZXFyCliv6r04KJlimVCRDzeZQ6lmdrlX9G1yxKi2NQCYhN X-Received: by 2002:a17:906:d92e:: with SMTP id rn14mr295512ejb.314.1594653598448; Mon, 13 Jul 2020 08:19:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594653598; cv=none; d=google.com; s=arc-20160816; b=CR5asYPWvFuzDKo2qwWiFuEnONhVIOO5QUOFZz7u02xlQsyvGb4ugi6oIqQypNd3Ot m0b6XQT7+/mxeyvKVaf1eO7Le0M9Rymrplly3DZVioxLgOHIIzKxL3lfeE32S+t8KzBd 0ddC2QO7bwsbzwW3Sd/km3xcdEjSbGZsql3UTm/lK4/NqSyHRP1KiQc7I5P/lQbe1WFP HtnLWn3xZrDUmpCt1YvXBlrv0uZsI+PjLPM+yJkoyUEATO7fJfI4EzVyTFTH7YUb5IsA FhyMfEoiBR4C4YXlmVQrnwKxLQC5T8ESFDHZFP5KkqHgiwsqujYN4W36NKlU71RPa5mR P0hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=OxqZMq21uNffHwpg/knft1f3mMrPBXkjeaZqj3TOCVA=; b=xVpxg3t/zDFTDAHmFZd3XM5VqMk5rwpfzknB32pjVUj5gZtxOK1lXtCAGhO/Stiv4A B6W9xuNDOy8DoVl2Ceihma9qwcW9g+8KZi/VPAoFXfGb+fk2ERDo1/y0ukFbSj86KXkF UT4Q++datfrjlKJs8rzTCr/+K4A41EZ03GPssxcKbjDqfjIjtYaFzaxdUXZcxIac0zSo ZW8n07w+INxStLsdT5YaBf5nR70lViaU36YA6iM9J4ndtOhqy2GPW3i7NLJ3SNQSzZb5 Iwi5RVA32Pi+gcCG7GVgAqbyU62GEHEi24akprKWw1YhIsG9fXF5rZjQhOSB33XdNiwF MA0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm20si11914318ejc.159.2020.07.13.08.19.35; Mon, 13 Jul 2020 08:19:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729917AbgGMPRY (ORCPT + 99 others); Mon, 13 Jul 2020 11:17:24 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:60970 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729027AbgGMPRY (ORCPT ); Mon, 13 Jul 2020 11:17:24 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1jv0Cl-004si1-56; Mon, 13 Jul 2020 17:17:19 +0200 Date: Mon, 13 Jul 2020 17:17:19 +0200 From: Andrew Lunn To: Oleksij Rempel Cc: Florian Fainelli , Heiner Kallweit , "David S. Miller" , kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Philippe Schenker Subject: Re: [PATCH net-next v1 5/5] net: phy: micrel: ksz886x/ksz8081: add cabletest support Message-ID: <20200713151719.GE1078057@lunn.ch> References: <20200710120851.28984-1-o.rempel@pengutronix.de> <20200710120851.28984-6-o.rempel@pengutronix.de> <20200711182912.GP1014141@lunn.ch> <20200713041129.gyoldkmsti4vl4m2@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200713041129.gyoldkmsti4vl4m2@pengutronix.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Hi Oleksij > > > > Do the PHY register read/writes pass through the DSA driver for the > > 8873? I was wondering if the switch could intercept reads/writes on > > port1 for KSZ8081_LMD and return EOPNOTSUPP? That would be a more > > robust solution than DT properties, which are going to get forgotten. > > Yes, it was my first idea as well. But this switch allows direct MDIO > access to the PHYs and this PHY driver could be used without DSA driver. > Not sure if we should support both variants? > > Beside, the Port 1 need at least one more quirk. The pause souport is > announced but is not working. Should we some how clear Puase bit in the PHY and > tell PHY framework to not use it? What is the best way to do it? It all seems rather odd, the way one PHY is messed up, but the other works. Does this PHY exist as a standalone device, not integrated into the switch? Do the same erratas apply to such a standalone device? If the issues are just limited to integrated PHYs, there is maybe something you can do via DSA: in slave.c: static int dsa_slave_phy_setup(struct net_device *slave_dev) { ... if (ds->ops->get_phy_flags) phy_flags = ds->ops->get_phy_flags(ds, dp->index); ret = phylink_of_phy_connect(dp->pl, port_dn, phy_flags); It is either B53 or SF2 which uses this, i forget which. flags get or'ed into phydev->dev_flags. These are device specific flags. So you could define a bit to represent this errata. And then in the PHY driver do whatever needs to be done when you see the flag set for a specific PHY. If Pause is broken, then yes, it would be good to remove the Pause from the available features, and return an error if requested to use it. Andrew