Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> writes: > On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
