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 DA816C63697 for ; Thu, 19 Nov 2020 15:27:31 +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 5302B246AA for ; Thu, 19 Nov 2020 15:27:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1rd1gYVk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5302B246AA 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:References:In-Reply-To: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:List-Owner; bh=rZ76CnmbQnzWjcI+xIa4rFuu1DTZOuE4fSSU09N8rJo=; b=1rd1gYVkZB4ZLIlQvVXwvETfk qnBeju/1oUV6xAmtlr/Khz680n/nskROoLXIw47i2CL7MAGqCfi2NvZVHaZMawu+QJkmoGzz93RAD L4G4EslTzRCzcVan36GgzRgRxG+leNmAXRZtdpj3BYVcoWJi2BKE9zGQfq8uLmQjGCSwCN4yANtnj XF309iLcAS9W4W+OwJXUlPOiNqhMz/3Cq/2LV9/l/TQGR1vTb+EJAHBPX4kDEjAdBcz1UWG7xZxRe P75qm1vFuIQjxVw8AR1j7IQmJpqWBDf/iL4mfAfGVb7/K6Oi2BETS+b1+jm/GUZVFUmzTQUHF+ssO PyoNhnQQg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kflod-0004LK-DY; Thu, 19 Nov 2020 15:25:43 +0000 Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kflnz-00046x-H0 for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 15:25:07 +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 relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1AB6E6000B; Thu, 19 Nov 2020 15:24:54 +0000 (UTC) Date: Thu, 19 Nov 2020 16:24:51 +0100 From: Maxime Chevallier To: Russell King - ARM Linux admin Subject: Re: net: phy: Dealing with 88e1543 dual-port mode Message-ID: <20201119162451.4c8d220d@bootlin.com> In-Reply-To: <20201119145500.GL1551@shell.armlinux.org.uk> References: <20201119152246.085514e1@bootlin.com> <20201119145500.GL1551@shell.armlinux.org.uk> 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_102503_896747_BA2A0B58 X-CRM114-Status: GOOD ( 32.23 ) 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: Andrew Lunn , Florian Fainelli , netdev@vger.kernel.org, Antoine Tenart , Vivien Didelot , Thomas Petazzoni , "David S. Miller" , linux-arm-kernel@lists.infradead.org, Heiner Kallweit 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 Russell, On Thu, 19 Nov 2020 14:55:00 +0000 Russell King - ARM Linux admin wrote: >On Thu, Nov 19, 2020 at 03:22:46PM +0100, Maxime Chevallier wrote: >> 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 >> +---------------------------------+ > >Yes, this is somewhat like the 88x3310 - the 88x3310 PHY is actually a >collection of different PHY blocks integrated together, with a chunk of >firmware controlling the whole thing, enabling the appropriate PHY >blocks and routing the data paths amongst them as required. > >With the 88x3310, we don't care very much about the MAC-facing blocks >(PHYXS in Clause 45 terminology). We certainly do not check the PHYXS >for link before reporting that the PHY as a whole has link - this is >actually very important, since with the 88x3310, we have to report to >the MAC that the link is up so the MAC can configure its PHY facing >interface correctly before that part of the link will come up. > >Also, if we look at 88e1512 when used in SGMII to copper mode, this >PHY re-uses its fiber side for the MAC facing SGMII interface, so can >be regarded similar to your above diagram. > >So, a question for you: does the above setup for ports 0 and 2 require >any software configuration of the PHY, or is that all achieved by >hardware strapping the PHY for the appropriate mode? > >If it's all done by hardware strapping with no software configuration >requirement for ports 0 and 2, I would suggest that we ignore the >complexities here, and just represent ports 1 and 3 as normal, as a >SGMII-to-{copper,fibre}. I gave it a look, and indeed ports 0 and 2 don't need any particular software configuration, all the config is done on ports 1 and 3. So, you're right this simplifies a lot the situation :) There's one thing though, ports 1 and 3 can be used as SGMII-to-Copper, SGMII-to-Fibre (in that case, ports 0 and 2 are also available to use), or as SGMII-to-{Copper + Fibre} with autodetection, in that case ports 0/2 act as the MAC facing side. In the latter case, we need to configure a few registers on port 1/3 to configure the internal circuitry. (but we do leave ports 0/2 untouched). I don't think we have a way to distinguish from the DT if we are in SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is the same, we don't have any information in DT about wether or not the PHY is wired to a Copper RJ45 port. Maybe we should have a way to indicate if a PHY is wired to a Copper port in DT ? >If we were to let phylib to drive ports 0 and 2 as well, we're going >to introduce a whole raft of entirely new problems. phylib is only >really designed for the last-step media facing PHY. > >> 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). > >Aren't each of the four ports at a different MDIO address, which means >each has to be described separately? Yes indeed >> 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 >> > -- Maxime Chevallier, Bootlin Embedded Linux and kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel