From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Subject: Re: [PATCH v3 06/10] dt-bindings: phy: mvebu-utmi: add UTMI PHY bindings Date: Wed, 23 Jan 2019 14:51:01 +0100 Message-ID: <20190123145101.1fabcad3@windsurf> References: <20190121112336.23489-1-miquel.raynal@bootlin.com> <20190121112336.23489-7-miquel.raynal@bootlin.com> <20190122183833.40077d7a@windsurf> <20190122201635.4a6c28d0@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190122201635.4a6c28d0@xps13> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Miquel Raynal Cc: Mark Rutland , Andrew Lunn , Jason Cooper , Mathias Nyman , devicetree@vger.kernel.org, Antoine Tenart , Greg Kroah-Hartman , Gregory Clement , linux-usb@vger.kernel.org, Kishon Vijay Abraham I , Nadav Haklai , Rob Herring , Alan Stern , Maxime Chevallier , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth List-Id: devicetree@vger.kernel.org Hello Miquel, On Tue, 22 Jan 2019 20:16:35 +0100, Miquel Raynal wrote: > > Do we really need different compatible strings for those ? I assume the > > IP block is exactly the same for the two PHYs, right ? If so, we should > > use the same compatible string. > > For what I understand, the PHYs are different. At least this is how > they are described in the specification. I can list at least two > differences visible in the register set: > * one has OTG registers, the other does not. > * one has charger detection capabilities (and registers), the other > does not. OK, then indeed it makes sense to have two different compatible strings. > > Those registers are contiguous to the register range of the PHY itself. > > What was the criteria used to decide that we need two separate DT nodes > > for these ? > > Because this area contains a bunch of registers, most of them are > there to manage the PHY, but others are related to the USB controller > (ie. a software reset). I know the current USB controller driver does > not access this area but what if one day we decide to do it? OK, if indeed this register area contains register used both for the PHY and for something else, your DT representation makes sense. Thanks for those clarifications! Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com