From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60660C63697 for ; Thu, 19 Nov 2020 14:24:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D4063238E6 for ; Thu, 19 Nov 2020 14:24:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="0NXHLOBc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4063238E6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Subject:To:From:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=lIbAhO3jQ92ABrgrG0PX2SUr7eeYEx3thzU8V3NE64E=; b=0NXHLOBcOfBQI6yStEuU8JgkmT K64G4q7s0oi0kY+KTAAQXqjhnHmJwWlX2AUzignG8nRDMJ2iahrYD8EJeJDHIOhN/WgatEyc0vhQS w875TZzzoURsfHotTPi8tza8qysBa5MV0ERyT66C3mah09RwAXfR0ZjaJgGibnfg4x+hu7TZMD4qc 6uSWdbnUzJt38L1VTaA5sSW7zr3O3PAd/kzTQ3pYWz8rV58gp3FnfWc6bDPIy6D3dSS2gruH8uZl7 GFGzXETBWwT9cx/AAyzk2B4c6IpT+CtlPAs3OvLlvy9TMbgakMU50DrAdZt8yKQ9AiRJ4J28SCt/B 2vug7mUQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfkq3-0004iQ-L3; Thu, 19 Nov 2020 14:23:07 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfkpu-0004dE-Ao for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 14:23:00 +0000 X-Originating-IP: 90.55.104.168 Received: from bootlin.com (atoulouse-258-1-33-168.w90-55.abo.wanadoo.fr [90.55.104.168]) (Authenticated sender: maxime.chevallier@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 65F6D20018; Thu, 19 Nov 2020 14:22:48 +0000 (UTC) Date: Thu, 19 Nov 2020 15:22:46 +0100 From: Maxime Chevallier To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Heiner Kallweit , Russell King - ARM Linux , "David S. Miller" , Antoine Tenart Subject: net: phy: Dealing with 88e1543 dual-port mode Message-ID: <20201119152246.085514e1@bootlin.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_092258_690496_BA5E8A47 X-CRM114-Status: GOOD ( 15.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Petazzoni Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello everyone, I'm reaching out to discuss an issue I'm currently having, while working on a Marvell 88E1543 PHY. This PHY is very similar to the 88E1545 we already support upstream, but with an added "dual-port mode" feature that I'm currently using in a project, and that might be interesting to have upstream. As a quick remainder, the 88E154x family are 4-ports PHYs that support Fiber (SFP) or RJ45 Copper interfaces on the media side, and QSGMII/SGMII on the host side. A datasheet for this PHY family can be found here [1] but unfortunately, this public datasheet doesn't explain the mode I'm going to discuss... The specificity of the 88E1543 is that is can be configured as a 2-port PHY, each port having the ability to have both a Copper RJ45 interface and a Fiber interface with automatic media detection, very much like the 88x3310 that we support, and that is used on the MacchiatoBin. This auto-media detection is the specific mode i'm interested in. The way this works is that the PHY is internally configured by chaining 2 internal PHYs back to back. One PHY deals with the Host interface and is configured as an SGMII to QSGMII converter (the QSGMII is only used from within the PHY), and the other PHY acts as the Media-side PHY, configured in QSGMII to auto-media (RJ45 or Fiber (SFP)) : +- 88e1543 -----------------------+ +-----+ | +--------+ +--------+ | /-- Copper (RJ45) | |--SGMII----| Port 0 |--QSGMII--| Port 1 |----< | | | +--------+ +--------+ | \--- Fiber | MAC | | | | | | +--------+ +--------+ | /-- Copper (RJ45) | |--SGMII----| Port 2 |--QSGMII--| Port 3 |----< +-----+ | +--------+ +--------+ | \-- Fiber +---------------------------------+ I have two main concerns about how to deal with that (if we are interested in having such a support upstream at all). The first one, is how to represent that in the DT. One approach could be to really represents what's going on, by representing the 2 PHYs chained together. In this case, only the MAC-facing PHY will report the link state, so we are basically representing the internal wiring of the PHY, can we consider that as a description of the hardware ? Besides that, I don't think that today, we are able to represent link composed of multiple PHYs daisy-chained together, but this is something that we might want to support one day, since it could benefit other types of use-cases. Another approach could be to pretend the 88E1543 is a 2-port SGMII to Auto-media PHY. This is also a bit tricky, since we need a way to detect that we want the whole 4-ports PHY to act as a 2-port PHY. (or 3-port, if we only want to use one pair of ports in that mode, and the other ports as SGMII - Copper or SGMII - Fiber PHYs). The second concern I have is that all of this is made even harder by the fact that this 88E1543 PHY seems indistinguishable from the 88E1545 by reading the PHY ID, they both report 0x01410eaX :/ I guess we would also need some DT indication that we are in fact dealing with a 88E1543. So I'd like you opinions on how we might want to deal with such scenarios, and if we do want to bother supporting that at all :( Thanks in advance, Maxime [1] : https://www.marvell.com/content/dam/marvell/en/public-collateral/transceivers/marvell-phys-transceivers-alaska-88e154x-datasheet.pdf _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel