Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2762236ybt; Mon, 22 Jun 2020 06:28:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCwCDEMF9RJl0Eq49NYUtQTytND0XgJm4pFNaWFzhAkSfJA0dNwFnFfIAoGJPfpGRo6g0c X-Received: by 2002:a50:ec8f:: with SMTP id e15mr7514227edr.70.1592832517108; Mon, 22 Jun 2020 06:28:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592832517; cv=none; d=google.com; s=arc-20160816; b=FKnS2aOQr9nMjBCa3SdJV8Rj15Naroj9L0BN10tXT0LXkf4l3Z7iGqwcKQruFArbGt PiV9MR1jo9VUhEaEaYYXOA0nVvq+hif3tZvT6emvCzK2CQbJefK7175FhTkaRVJx73dt Mmw+AMdQzIRCWmkbfQIEM9OAfD+NhJRwb/xWlb2UanifECD5eMKUHPoN8EsQ3NYYj3t+ Rm38NtuDx/iPfWFV7pYq4cjbTr9aj3KtuPcsQseFj/QaB3hroaaXZMgAB+kj9xEMd8Ij iOKPScjIuPOnDa4KpzHX63tpmX9pG0XRay8EFWf2CyhXcvCXpMReQielV3j5xrkvmc/g wl6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:cc:from:to:subject :references:in-reply-to:content-transfer-encoding:mime-version; bh=11gIYnt2mKgWDkT0F9WSfvr79Iyu7kB6wEfF592fCZM=; b=iaTX9S76S4osg/ebr9NpjLzwXEM5+4sghPfz/d4ZJh4m7HQT++U+aItGNUI+KPiYyg u0LkKpOQRtF+EMZEobccaGqFbyj4ejXltXazKxH/MAqH7KQ9qmJ23A6hs1fE8wRjQ+ly 3vhaHczX916r5PuFGkOlBlZnZDMKLGEUX4JJuG9nd11kdzl+g7IPiFlFiSEo7QpmCoLa PvM+Oda2PTwfHYN24wubbbYP/xIvf4xOjQyyoZyCAOxCQ2L0FL0NzxTYuaLSG4fq0ko3 P+QMcghVrtlhn81bPInKwtQvyVWfMq1KaIbCER+tPEiUmhlNBKUmtob3sbAAPCIR8wmP QK7A== 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 r24si4757817edp.282.2020.06.22.06.28.13; Mon, 22 Jun 2020 06:28:37 -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 S1728945AbgFVN0N convert rfc822-to-8bit (ORCPT + 99 others); Mon, 22 Jun 2020 09:26:13 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:59549 "EHLO relay8-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727963AbgFVN0N (ORCPT ); Mon, 22 Jun 2020 09:26:13 -0400 X-Originating-IP: 90.76.143.236 Received: from localhost (lfbn-tou-1-1075-236.w90-76.abo.wanadoo.fr [90.76.143.236]) (Authenticated sender: antoine.tenart@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 6D3141BF208; Mon, 22 Jun 2020 13:26:07 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <20200620154008.GO304147@lunn.ch> References: <20200619122300.2510533-1-antoine.tenart@bootlin.com> <20200619122300.2510533-7-antoine.tenart@bootlin.com> <20200620154008.GO304147@lunn.ch> Subject: Re: [PATCH net-next v3 6/8] net: phy: mscc: timestamping and PHC support To: Andrew Lunn From: Antoine Tenart Cc: davem@davemloft.net, f.fainelli@gmail.com, hkallweit1@gmail.com, richardcochran@gmail.com, alexandre.belloni@bootlin.com, UNGLinuxDriver@microchip.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, allan.nielsen@microchip.com, foss@0leil.net Message-ID: <159283236709.1456598.3715966711472439674@kwain> Date: Mon, 22 Jun 2020 15:26:07 +0200 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, Quoting Andrew Lunn (2020-06-20 17:40:08) > On Fri, Jun 19, 2020 at 02:22:58PM +0200, Antoine Tenart wrote: > > To get and set the PHC time, a GPIO has to be used and changes are only > > retrieved or committed when on a rising edge. The same GPIO is shared by > > all PHYs, so the granularity of the lock protecting it has to be > > different from the ones protecting the 1588 registers (the VSC8584 PHY > > has 2 1588 blocks, and a single load/save pin). > > I guess you thought about this GPIO quite a bit. > > It appears you have the mutex in the shared structure, but each PHY > has its own gpio_desc, even though it should be for the same GPIO? Yes, that's right. I had an early solution were I was sharing the GPIO in the shared structure, allowing to have a single gpio_desc. (dt would still needs to have one GPIO per PHY). That turned out to be a lot more complex that the current solution, having to unregister and free the GPIO desc manually when the driver of the last PHY was unregistered. I had to add lots of logic (and not the nicely looking one) to the shared PHY helpers in the core. > The binding requires each PHY has the GPIO, even though it is the same > GPIO. And there does not appear to be any checking that each PHY > really does have the same GPIO. Right. I don't see a clean and nice way to do this. Do you have an idea? On another hand, this would only lead to not being able to set/get (a correct) time from the PHC. > Ideally there would be a section in DT for the package, and this GPIO > would be there. But i don't see an good way to do this. Yes, I agree. That wasn't the design chosen when PHY packages were added. This PHY already has a shared description, duplicated for each PHY of the same package (for the interrupt line). If we were to change this one day, we probably would have to break dt compatibility anyway as there's already a property that is shared. > This does not feel right to me, but i've no good idea how it can be > made better :-( I think this kind of rework is out of this series scope; but I would be happy to discuss a better solution for someday. Thanks! Antoine -- Antoine Ténart, Bootlin Embedded Linux and Kernel engineering https://bootlin.com