From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: From: Kevin Hilman To: Martin Blumenstingl Cc: Ben Dooks , mark.rutland@arm.com, devicetree@vger.kernel.org, gregkh@linuxfoundation.org, johnyoun@synopsys.com, will.deacon@arm.com, mturquette@baylibre.com, linux-usb@vger.kernel.org, sboyd@codeaurora.org, kishon@ti.com, robh+dt@kernel.org, catalin.marinas@arm.com, carlo@caione.org, linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, jbrunet@baylibre.com Subject: Re: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB References: <20160904213152.25837-1-martin.blumenstingl@googlemail.com> <20160904213152.25837-5-martin.blumenstingl@googlemail.com> Date: Fri, 09 Sep 2016 10:04:19 -0700 In-Reply-To: (Martin Blumenstingl's message of "Fri, 9 Sep 2016 18:14:03 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain List-ID: Martin Blumenstingl writes: > On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman wrote: >> However, the problem with all of the solutions proposed (runtime PM ones >> included) is that we're forcing a board-specific design issue (2 devices >> sharing a reset line) into a driver that should not have any >> board-specific assumptions in it. >> >> For example, if this driver is used on another platform where different >> PHYs have different reset lines, then one of them (the unlucky one who >> is not probed first) will never get reset. So any form of per-device >> ref-counting is not a portable solution. > > maybe we should also consider Ben's solution: he played with the USB > PHY on his Meson8b board. His approach was to have only one USB PHY > driver instance which exposes two PHYs. > The downside of this: the driver would have to know the offset of the > PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle > the reset using runtime PM without any hacks. > I checked the USB PHY reference driver: it seems that there will be a > new USB PHY with the GXL/GXM SoCs. > So maybe we could live with the assumption that the PHYs are at > consecutive addresses. But isn't that also forcing us to make board-specific assumptions inside the driver. Kevin